Microsoft Technology Licensing, LLC

Sameer Arun Verkhedkar

Sandeep Lingam

Girish Mittur Venkataramanappa

Steven John Lindell

Zhengguo Sun

Varun Kunjbihari Tibrewal

Colin Neville

Alexander Evgenievich Nosov

Deepak Bansal

Tomas Talius

Praveen Balasubramanian

Sudheer Vaddi

Daniel L Lemmond

Istvan Cseri

Cesar Alejandro Galindo-Legaria

Shankar Pal

Praveen Seshadri

Erik Ismert

Eric N Hanson

Oliver Nicholas Seeliger

Gideon Schaller

Shawn Bice

Richard Shawn Bice

Ganapathy Subramaniam Krishnamoorthy

Denis Y Altudov

Evgueni Zabokritski

Tony Petrossian

Denis Churin

Matt Hollingsworth

Samer Boshra

Lubor Kollar

Ken Van Hyning

Charlie D Carson

Robert Hutchinson

Omri Bahat

Described herein is a system and method of connectivity migration of an executing virtual application and/or guest operating system. State associated with a first instance of an application and/or a guest operating system executing on a first virtual machine is captured. Information regarding connectivity state associated with a plurality of running connections between the first virtual machine and client device(s) is also captured (e.g., layers 2, 3 and 4). The captured state information can be provided to a second virtual machine which utilizes the captured station information to establish state for a second instance of the application, a second instance of the guest operating system, and/or connectivity of the plurality of running connections between the second virtual machine and client device(s). The state of the second instance of the application can be synchronized with the state of the second instance of the guest operating system.

Connectivity migration in a virtual execution system

Described herein is a system and method of connectivity migration of an executing virtual application and/or guest operating system. State associated with a first instance of an application and/or a guest operating system executing on a first virtual machine is captured. Information regarding connectivity state associated with a plurality of running connections between the first virtual machine and client device(s) is also captured (e.g., layersand). The captured state information can be provided to a second virtual machine which utilizes the captured station information to establish state for a second instance of the application, a second instance of the guest operating system, and/or connectivity of the plurality of running connections between the second virtual machine and client device(s). The state of the second instance of the application can be synchronized with the state of the second instance of the guest operating system.

A Distributed Availability Group (DAG) spans two AGs, each spanning one or more replica nodes and functioning as primary or secondary AG. A primary AG is replicated to the secondary AG synchronously or asynchronously. A failover in the DAG results in the AGs swapping their roles. Multiple DAGs can be linked together as a chain, which provides many useful features including disaster recovery across geographical regions, massive read scale (numerous readable secondary nodes), online migration of databases (across different operating systems and computing environments). The systems using DAGs can replicate databases across multiple independent high availability (HA) failover clusters using complex replication topologies and allow for manual failover and failback. The systems allow chaining of multiple AGs to provision a treelike structure of replicas and numerous secondary replicas without impacting performance. The systems automatically seed new database replicas to facilitate building a complex topology of DAGs.

Distributed availability groups of databases for data centers including seeding, synchronous replications, and failover

Application service configuration of a timeframe for performing dataloss failover (failover that does not attempt full data replication to the secondary data store) from a primary data store to the secondary data store. A data-tier service, such as perhaps a database as a service (or DBaaS), could receive that configuration from the application service and automatically perform the dataloss failover as configured by the application service. This relieves the application service from having to manage the failover workflow while still allowing the application service to appropriately balance the timing of dataloss failover, which will depend on a very application-specific optimal balance between the negative effects of operational latency versus dataloss.

Application service-level configuration of dataloss failover

Distributed availability groups of databases for data centers for providing massive read scale

Distributed availability groups of databases for data centers including different commit policies

A Distributed Availability Group (DAG) spans two AGs, each spanning one or more replica nodes and functioning as primary or secondary AG. A primary AG is replicated to the secondary AG synchronously or asynchronously. A failover in the DAG results in the AGs swapping their roles. Multiple DAGs can be linked together as a chain, which provides many useful features including disaster recovery across geographical regions, massive read scale (numerous readable secondary nodes), online migration of databases (across different operating systems and computing environments). The systems using DAGs can replicate databases across multiple independent high availability (HA) failover clusters using complex replication topologies and allow for manual failover and failback. The systems allow chaining of multiple AGs to provision a treelike structure of replicas and numerous secondary replicas without impacting performance. The systems automatically seed new database replicas that to facilitate building a complex topology of DAGs.

Distributed availability groups of databases for data centers

Distributed availability groups of databases for data centers including failover to regions in different time zones

Semi-automatic failover includes automatic failover by a service provider as well as self-serviced failover by a service consumer. A signal can be afforded by a service provider based on analysis of an incident that affects the service provider. Initiation of self-serviced failover by a service consumer can be predicated on the signal. In one instance, the signal provides information that aids a decision of whether or not to failover. In another instance, the signal can grant or deny permission to perform a self-serviced failover.

Semi-automatic failover

Data-tier application components (DACs) and methods for managing database applications are disclosed. According to one particular embodiment, a DAC includes a single unit of management that packages metadata related to a database object. The metadata related to the database object includes an identifier of the database object, a database runtime resource identifier of a database runtime resource operable to manipulate the database object, and a policy related to execution of the database runtime resource.

Data-tier application component

A system and method for creation, modification and/or use of plan guide(s) is provided. Plan guide(s) can be employed to optimize the performance of query(ies) when it is not possible and/or desirable to change the text of the query directly. Plan guides can be useful, for example, when a small subset of queries in a database application deployed from a third-party vendor is not performing as expected. Plan guides influence optimization of queries by attaching query hints to them. In accordance with an aspect of the subject invention, a query plan execution system is provided. The system includes an execution component, a query optimizer, and, a plan cache. Plan guides and other associated metadata are stored in a plan guide metadata store.

Query plan selection control using run-time association mechanism

Storing and querying XML data in a primary table or document utilizes an index of XML data and includes creating a primary table structure, creating a primary XML index commensurate with the primary table structure, populating the primary table and the primary XML index, and running a query on the XML data in a primary table by utilizing the XML index. The XML index can be implemented as a node table. The node table may have a B-tree structure and be populated by shredding the XML values in the primary table. The XML data may be stored as binary large objects in an XML column of the primary table. Secondary XML indexes may be created to assist in the search and retrieval of XML data stored in the primary table. Both the primary XML index and the secondary XML index tables may be created using data definition language statements.

Indexing XML datatype content system and method

Growing community of inventors

Issaquah, WA, United States of America

Sameer Arun Verkhedkar