I am trying to copy my existing AzureSQL (singleton) database from PRODUCTION subscription into a NON-PRODUCTION database in a different subscription. I need to repeat this process every night so that our production support environment (non-prod) has the latest copy from production from the night before. Since overwriting database is not possible in AzureSQL, I would like to copy "DBProd" from PROD server as "DBProd2" on to my Non-Prod server (in a different subscription), then delete the existing "DBProd" from the destination server and rename "DBProd2" to "DBProd".
I have searched through this site to find answers and the closest I found was this link below...
Cross Subscription Copying of Databases on Windows Azure SQL Database
In that link user #PaulH submitted the below answer...
"This works for me across subscriptions without having matching SQL Server accounts. I am a member of the server active directory admin group on both source and target servers, and connecting using AD authentication with MFA. – paulH Mar 25 at 11:22"
However, I could not figure out the details of how it was achieved. My preference is to use power shell script to get this done. If any of you had done this before, I would appreciate a snippet of sample code, or any pointers to achieve this.
My other option is to go the BACPAC route (export and import), but I would only want to resort to that if copying of DB across subscriptions is not possible.
Thanks in advnace!
Helios
Went through the link...
Cross Subscription Copying of Databases on Windows Azure SQL Database
The Move-AzureRmResource cmdlet may be all you need. Below how it works.
Let's say you create a new Azure SQL Server on a different resource group.
New-AzureSqlDatabaseServer -Location "East US" -AdministratorLogin "AdminLogin" -AdministratorLoginPassword "AdminPassword"
Copy the source database to the newly created Azure SQL Server.
Start-AzureSqlDatabaseCopy -ServerName "SourceServer" -DatabaseName "Orders" -PartnerServer "NewlyCreatedServer" -PartnerDatabase "OrdersCopy"
Move the resource group of the Newly created Azure SQL Server to another subscription.
Move-AzureRmResource -DestinationResourceGroupName [-DestinationSubscriptionId ] -ResourceId [-Force] [-ApiVersion ] [-Pre] [-DefaultProfile ] [-InformationAction ] [-InformationVariable ] [-WhatIf] [-Confirm] []
For more information, please read this DBAStackExchange thread.
Related
I have a simple query that takes old data from a table and inserts the data into another table for archiving.
DELETE FROM Events
OUTPUT DELETED.*
INTO ArchiveEvents
WHERE GETDATE()-90 > Events.event_time
I want this query to run daily.
As i currently understand, there is no SQL Server Agent when using Azure SQL-db. Thus SQL Server agent does not seem like the solution here.
What is the easiest/best solution to this using Azure SQL-db?
There are multiple ways to run automated scripts on Azure SQL Database as below:
Using Automation Account Runbooks.
Using Elastic Database Jobs in Azure
Using Azure Data factory.
As you are running just one script, I would suggest you to take a look into Automation Account Runbooks. As an example below, a PowerShell Runbook to execute the statement.
$database = #{
'ServerInstance' = 'servername.database.windows.net'
'Database' = 'databasename'
'Username' = 'uname'
'Password' = 'password'
'Query' = 'DELETE FROM Events OUTPUT DELETED.* INTO archieveevents'
}
Invoke -Sqlcmd #database
Then, it can be scheduled as needed:
You asked in part for a comparison of Elastic Jobs to Runbooks.
Elastic Jobs will also run a pre-determined SQL script against a
target set of servers/databases.
-Elastic jobs were built
internally for Azure SQL by Azure SQL engineers, so the technology is
supported at the same level of Azure SQL.
Elastic jobs can be defined and managed entirely through PowerShell scripts. However, they also support setup/configuration through TSQL.
Elastic Jobs are handy if you want to target many databases, as you set up the job one time, and set the targets and it will run everywhere at once. If you have many databases on a given server that would be good targets, you only need to specify the target
server, and all of the databases on the server are automatically targeted.
If you are adding/removing databases from a given server, and want to have the job dynamically adjust to this change, elastic jobs
is designed to do this seamlessly. You just have to configure
the job to the server, and every time it is run it will target
all (non excluded) databases on the server.
For reference, I am a Microsoft Employee who works in this space.
I have written a walkthrough and fuller explanation of elastic jobs in a blog series. Here is a link to the entry point of the series:https://techcommunity.microsoft.com/t5/azure-sql/elastic-jobs-in-azure-sql-database-what-and-why/ba-p/1177902
You can use Azure data factory, create a pipeline to execute SQL query and trigger it run every day. Azure data factory is used to move and transform data from Azure SQL or other storage.
When importing a SQL Server database from another machine using a .BAK file through the restore option, the process appears to be successful and completes with the database now in the list within SQL Server Management Studio. But one thing I need clarified please.
When the Restore dialogue is importing the database a row of fields are displayed including "Name", "component", "Type" etc. But the last field is the username. Is this field simply showing the owner of the database where it originated from or is this value used with relevance in the imported database?
I looked in database_name >> Security > Users in SSMS but the user shown in the restore process is not listed
Looking for the best practice on refreshing a QA/Test Azure SQL Database from a Production Azure SQL Database
The production database is on a different server and resource group. So just wondering the best method for getting the production data into the qa/testing database. What tools are available for a task like this?
The most common format of SQL Azure Database's is bacpac, and believe me when I tell you that it is AWESOME.
Exporting
The easiest way to do this is using the Azure Portal or with SSMS.
This will however copy the entire database schema and all data. If you need something more specific, like excluding a table, look no further than sqlpackage.exe.
.\sqlpackage.exe /Action:Export /ssn:SERVER /sdn:ADB /tf:"C:\PATH\TO\FILE.bacpac" /of /p:TableData=TABLE /p:TableData=TABLE /p:TableData=TABLE
Importing
To create a database from the .bacpac you created above, all three of the aforementioned methods also support importing.
Recommendations
I would apply the KISS principle here and just use the portal/SSMS on both ends. Dropping the specific tables you no longer want/need.
You just need to copy the production database using the portal or PowerShell
New-AzureRmSqlDatabaseCopy -ResourceGroupName "myResourceGroup" `
-ServerName $sourceserver `
-DatabaseName "MySampleDatabase" `
-CopyResourceGroupName "myResourceGroup" `
-CopyServerName $targetserver `
-CopyDatabaseName "CopyOfMySampleDatabase"
You can also automate refreshing the development database by recreating it using Azure Automation and the following T-SQL statement.
CREATE DATABASE db_copy
AS COPY OF ozabzw7545.db_original ( SERVICE_OBJECTIVE = 'P2' );
I know I can clone DB into a new one with
CREATE DATABASE Database1_copy AS COPY OF Database1;
(https://learn.microsoft.com/en-us/azure/sql-database/sql-database-copy-transact-sql)
and this goes flawesly, except in Azure, where db properties are managed by Azure portal, so I am try to find a way to copy most of the schema/resources/data into an EXISTING DB
would be great for:
CLONE DATABASE Database_test AS COPY OF Database_production
[even first approach has been to "clone" the entire db, indeed few tables on destination db should be kept, so better approach would be to CLONE EVERYTHING EXCEPT ('table1','table2'). Actually plan to achieving this by scripting the few tables needed on destination db and overwriting them after import, but bet solution would be the other]
You can do this in several ways:
Through the Azure Portal
Open your database in the Azure Portal(https://portal.azure.com)
In the overview blade of your database select the "copy" option
Fill in the parameters, in which server would you like the copy
Using a sql server client and connecting to the server
Open your SQL Server blade in Azure
Select the "Firewall" option
Click on "Add client IP"
Connect to your database with your connection string and your favorite client, could be SSMS
Execute your sql query to clone the database in the same server
-- Copy a SQL database to the same server
-- Execute on the master database.
-- Start copying.
CREATE DATABASE Database1_copy AS COPY OF Database1;
https://learn.microsoft.com/en-us/azure/sql-database/sql-database-copy-transact-sql
The above SQL statement works perfectly fine as expected in Azure SQL Database.
Important Notes:
Log on to the master database (System Databases) using the
server-level principal login or the login that created the
database you want to copy.
Logins that are not the server-level principal must be members of
the dbmanager role in order to copy databases.
Use updated version of the SQL Server Management Studio
SQL Azure database supports copying whole database asynchronously with a single command as below:
I have been using to copy database within same server using
CREATE DATABASE [targetdb] AS COPY OF [sourcedb]
But when I try to copy database to a different SQL Azure server:
CREATE DATABASE [targetdb] AS COPY OF [source_sql_azure_server].[sourcedb]
But I get below error:
Cannot open server "source_sql_azure_server" requested by the login. The login failed.
How do I copy?
Although this question is very old, it's the one I came across when trying to find out if I could easily copy an Azure SQL database from one server to another.
It turns out that it's now as simple as navigating to the source database from http://portal.azure.com then clicking copy and choosing the new destination server.
The whole process is explained in more detail in this article:
https://azure.microsoft.com/en-us/documentation/articles/sql-database-copy/
To execute DB copy between 2 different servers you must be connected to the master database of the destination SQL Azure server and have correct permissions.
The exact same login/password must exist on the source server and destination server and the login must have db_owner permissions on the source server and dbmanager on the destination server.
Read more about it here: http://msdn.microsoft.com/en-us/library/ff951624.aspx
I guess there is also another way to achieve another copy in a different region. You can simply do an Asynchronous Replication to a different server and region and make that the primary.
This should solve your 5 year old problem! :)
$dblist = #("db1","db2","db3")
$sourceserver = "azureDBserversource"
$targetserver = "azureDBserverTarget"
$sourceRG = "mySourceRG"
$targetRG = "myTargetRG"
foreach ($db in $dblist) {
New-AzSqlDatabaseCopy -ResourceGroupName $sourceRG `
-ServerName $sourceserver `
-DatabaseName $db `
-CopyResourceGroupName $targetRG `
-CopyServerName $targetserver `
-CopyDatabaseName $db
}