Merge pull request #101170 from MashaMSFT/20200114_crosssubrepl

Added cross-sub geo-replication (AzB 1645790)

Author: megvanhuygen

articles/sql-database/media/sql-database-active-geo-replication/geo-replication-relationship.png

@@ -119,6 +119,79 @@ If you decide to create the secondary with lower compute size, the log IO percen
 
 For more information on the SQL Database compute sizes, see [What are SQL Database Service Tiers](sql-database-purchase-models.md).
 
+## Cross-subscription geo-replication
+
+To setup active geo-replication between two databases belonging to different subscriptions (whether under the same tenant or not), you must follow the special procedure described in this section.  The procedure is based on SQL commands and requires: 
+
+- Creating a privileged login on both servers
+- Adding the IP address to the allow list of the client performing the change on both servers (such as the IP address of the host running SQL Server Management Studio). 
+
+The client performing the changes needs network access to the primary server. Although the same IP address of the client must be added to the allow list on the secondary server, network connectivity to the secondary server is not strictly required. 
+
+### On the master of the primary server
+
+1. Add the IP address to the allow list of the client performing the changes (for more information see, [Configure firewall](sql-database-firewall-configure.md)). 
+1. Create a login dedicated to setup active geo-replication (and adjust the credentials as needed):
+
+   ```sql
+   create login geodrsetup with password = 'ComplexPassword01'
+   ```
+
+1. Create a corresponding user and assign it to the dbmanager role: 
+
+   ```sql
+   create user geodrsetup for login gedrsetup
+   alter role geodrsetup dbmanager add member geodrsetup
+   ```
+
+1. Take note of the SID of the new login using this query: 
+
+   ```sql
+   select sid from sys.sql_logins where name = 'geodrsetup'
+   ```
+
+### On the source database on the primary server
+
+1. Create a user for the same login:
+
+   ```sql
+   create user geodrsetup for login geodrsetup
+   ```
+
+1. Add the user to the db_owner role:
+
+   ```sql
+   alter role db_owner add member geodrsetup
+   ```
+
+### On the master of the secondary server 
+
+1. Add the IP address to the allow list of the client performing the changes. It must the same exact IP address of the primary server. 
+1. Create the same login as on the primary server, using the same username password, and SID: 
+
+   ```sql
+   create login geodrsetup with password = 'ComplexPassword01', sid=0x010600000000006400000000000000001C98F52B95D9C84BBBA8578FACE37C3E
+   ```
+
+1. Create a corresponding user and assign it to the dbmanager role:
+
+   ```sql
+   create user geodrsetup for login geodrsetup;
+   alter role dbmanager add member geodrsetup
+   ```
+
+### On the master of the primary server
+
+1. Login to the master of the primary server using the new login. 
+1. Create a secondary replica of the source database on the secondary server (adjust database name and servername as needed):
+
+   ```sql
+   alter database dbrep add secondary on server <servername>
+   ```
+
+After the initial setup, the users, logins, and firewall rules created can be removed. 
+
+
 ## Keeping credentials and firewall rules in sync
 
 We recommend using [database-level IP firewall rules](sql-database-firewall-configure.md) for geo-replicated databases so these rules can be replicated with the database to ensure all secondary databases have the same IP firewall rules as the primary. This approach eliminates the need for customers to manually configure and maintain firewall rules on servers hosting both the primary and secondary databases. Similarly, using [contained database users](sql-database-manage-logins.md) for data access ensures both primary and secondary databases always have the same user credentials so during a failover, there is no disruptions due to mismatches with logins and passwords. With the addition of [Azure Active Directory](../active-directory/fundamentals/active-directory-whatis.md), customers can manage user access to both primary and secondary databases and eliminating the need for managing credentials in databases altogether.

articles/sql-database/sql-database-active-geo-replication.md

@@ -50,7 +50,8 @@ All three flavors of Azure SQL Database offer some ability to dynamically scale
 - A [Managed Instance](sql-database-managed-instance.md) uses [vCores](sql-database-managed-instance.md#vcore-based-purchasing-model) mode and enables you to define maximum CPU cores and maximum of storage allocated to your instance. All databases within the instance will share the resources allocated to the instance.
 - [Elastic pools](sql-database-elastic-pool-scale.md) enable you to define maximum resource limit per group of databases in the pool.
 
-Initiating scale up or scale down action in any of the flavors would restart database engine process and move it to a different virtual machine if needed. Moving database engine process to a new virtual machine is **online process** where you can continue using your existing Azure SQL Database service while the process is in progress. Once the target database engine is fully initialized and ready to process the queries, the connections will be [switched from source to target database engine](sql-database-single-database-scale.md#impact-of-changing-service-tier-or-rescaling-compute-size).
+Initiating scale up or scale down action in any of the flavors would restart database engine process and move it to a different virtual machine if needed. Moving database engine process to a new virtual machine is **online process** where you can continue using your existing Azure SQL Database service while the process is in progress. Once the target database engine is fully initialized and ready to process the queries, the connections will be [switched from source to target database engine](sql-database-single-database-scale.md#impact). 
+
 
 > [!NOTE]
 > You can expect a short connection break when the scale up/scale down process is finished. If you have implemented [Retry logic for standard transient errors](sql-database-connectivity-issues.md#retry-logic-for-transient-errors), you will not notice the failover.

articles/sql-database/sql-database-scale-resources.md

@@ -16,8 +16,6 @@ ms.date: 04/26/2019
 
 This article describes how to scale the compute and storage resources available for an Azure SQL Database in the provisioned compute tier. Alternatively, the [serverless compute tier](sql-database-serverless.md) provides compute auto-scaling and bills per second for compute used.
 
-## Change compute size (vCores or DTUs)
-
 After initially picking the number of vCores or DTUs, you can scale a single database up or down dynamically based on actual experience using the [Azure portal](sql-database-single-databases-manage.md#manage-an-existing-sql-database-server), [Transact-SQL](https://docs.microsoft.com/sql/t-sql/statements/alter-database-transact-sql?view=azuresqldb-current#examples-1), [PowerShell](/powershell/module/az.sql/set-azsqldatabase), the [Azure CLI](/cli/azure/sql/db#az-sql-db-update), or the [REST API](https://docs.microsoft.com/rest/api/sql/databases/update).
 
 The following video shows dynamically changing the service tier and compute size to increase available DTUs for a single database.
@@ -27,7 +25,7 @@ The following video shows dynamically changing the service tier and compute size
 > [!IMPORTANT]
 > Under some circumstances, you may need to shrink a database to reclaim unused space. For more information, see [Manage file space in Azure SQL Database](sql-database-file-space-management.md).
 
-### Impact of changing service tier or rescaling compute size
+## Impact
 
 Changing the service tier or compute size of mainly involves the service performing the following steps:
 
@@ -42,7 +40,7 @@ Changing the service tier or compute size of mainly involves the service perform
 > [!IMPORTANT]
 > No data is lost during any step in the workflow. Make sure that you have implemented some [retry logic](sql-database-connectivity-issues.md) in the applications and components that are using Azure SQL Database while the service tier is changed.
 
-### Latency of changing service tier or rescaling compute size
+## Latency 
 
 The estimated latency to change the service tier or rescale the compute size of a single database or elastic pool is parameterized as follows:
 
@@ -55,7 +53,7 @@ The estimated latency to change the service tier or rescale the compute size of
 > [!TIP]
 > To monitor in-progress operations, see: [Manage operations using the SQL REST API](https://docs.microsoft.com/rest/api/sql/operations/list), [Manage operations using CLI](/cli/azure/sql/db/op), [Monitor operations using T-SQL](/sql/relational-databases/system-dynamic-management-views/sys-dm-operation-status-azure-sql-database) and these two PowerShell commands: [Get-AzSqlDatabaseActivity](/powershell/module/az.sql/get-azsqldatabaseactivity) and [Stop-AzSqlDatabaseActivity](/powershell/module/az.sql/stop-azsqldatabaseactivity).
 
-### Cancelling service tier changes or compute rescaling operations
+## Cancelling changes
 
 A service tier change or compute rescaling operation can be canceled.
 
@@ -84,7 +82,7 @@ else {
 }
 ```
 
-### Additional considerations when changing service tier or rescaling compute size
+## Additional considerations
 
 - If you are upgrading to a higher service tier or compute size, the database max size does not increase unless you explicitly specify a larger size (maxsize).
 - To downgrade a database, the database used space must be smaller than the maximum allowed size of the target service tier and compute size.
@@ -94,7 +92,7 @@ else {
 - The restore service offerings are different for the various service tiers. If you are downgrading to the **Basic** tier, there is a lower backup retention period. See [Azure SQL Database Backups](sql-database-automated-backups.md).
 - The new properties for the database are not applied until the changes are complete.
 
-### Billing during compute rescaling
+## Billing 
 
 You are billed for each hour a database exists using the highest service tier + compute size that applied during that hour, regardless of usage or whether the database was active for less than an hour. For example, if you create a single database and delete it five minutes later your bill reflects a charge for one database hour.
 
@@ -120,6 +118,10 @@ You are billed for each hour a database exists using the highest service tier +
 > [!IMPORTANT]
 > Under some circumstances, you may need to shrink a database to reclaim unused space. For more information, see [Manage file space in Azure SQL Database](sql-database-file-space-management.md).
 
+### Geo-replicated database
+
+To change the database size of a replicated secondary database, change the size of the primary database. This change will then be replicated and implemented on the secondary database as well. 
+
 ## P11 and P15 constraints when max size greater than 1 TB
 
 More than 1 TB of storage in the Premium tier is currently available in all regions except: China East, China North, Germany Central, Germany Northeast, West Central US, US DoD regions, and US Government Central. In these regions, the storage max in the Premium tier is limited to 1 TB. The following considerations and limitations apply to P11 and P15 databases with a maximum size greater than 1 TB: