Following is the exact scenario in my application:
SQL Server database is hosted on-premise locally in US office for
development purpose.
Developers are distributed in 3 different regions (US, India and
Australia).
Developers from India and Australia faces a lot of delay while
trying to access the database from application.
In order to resolve the above issue, we identified a following approach -
Create a VM and install SQL Server there.
Restore database over there.
US developers would continue using the database deployed in their
environment.
India and Australia developers would use the SQL database instance
hosted in Azure VM.
In order to enable synchronization of data and schema between these two databases (Azure VM SQL, and On-prem SQL instance), we are planning to use Azure Data Sync.
I believe most of the things in above scenario are subject of research. But guidance of someone who has already worked on similar things would be very much helpful. Also, we are not using Azure SQL because that would require changes in database schema, as its very old and legacy database
Could you please suggest if the above approach is ideal or not? Note, this is only for the ease of development, and we are not moving our production database outside on-prem setup.
I would not attempt to use Azure Data Sync here, first because you are not otherwise using Azure SQL Database, and second because it's not intended to sync schema changes like this.
Instead pick a primary replica for data changes, and periodically ship and restore backups to refresh the secondary instance. For schema changes, use SQL Server Data Tools and your Source Code Repository (Azure DevOps) to manage the changes.
Related
I am reading some guides to see how to backup/restore a Microsoft Azure SQL Server database.
Searching Microsoft documentation, it seems that:
Azure SQL Database has automated backups, so Azure Data Studio doesn't perform Azure SQL Database backup and restore. For more information, see Learn about automatic SQL Database backups.
After further reading, I see we can indeed restore a DB by creating a replica of it at a previous time point, but this costs ~80 euros if I read it correctly, as it basically creates a second instance of the db. Also, It seems to be able to go back in time only some limited time.
Is there a cost-less (without incurring additional cost to the existing costs) way to create a "permanent" off line copy of the database and restore it to an Azure SQL Database?
The first part of this question is similar to Is there a way to download the azure sql database managed backups - though I am not asking if it's possible, and I do not care about any format of the backup, and do not want to download the Azure backups. I would be happy creating my own backup so I am pretty sure the answer to my question is that is possible even though that answer is probably impossible.
Is there a cost-less (without incurring additional cost to the
existing costs) way to create a "permanent" off line copy of the
database and restore it to an Azure SQL Database?
You would have to install an extension to use DACPAC and BACPAC features in Azure Data studio.
Name: SQL Server Dacpac
Id: microsoft.dacpac
Description: Manage data-tier applications
Version: 1.8.0
Publisher: Microsoft
Here is a simple way to export DB as Bacpac, you can similarly use the [Import Bacpac] Operation to restore.
I am Connected to Microsoft SQL Server, backing up a SQL DB. But you can do this connecting to on-premise SQL server too.
What's the actual objective?
You can restore an Azure SQL to a point in time. Go into the Azure portal and do it in there. (Azure Data Studio may not have a nice way for you to do this)
By offline do you mean an on-premises (non cloud) copy? again what is the objective? Is it disaster recovery? Your on premises copy is more likely to be lost than the Azure one.
You can also point in time restore to another Azure database. If your DB <2Gb then you can just retore to the basic edition which is 4.25 Euro a month. Or you can use the serverless option which is even cheaper
But you have to consider why you are doing this. Azure has a lot of redundancy already built in which makes these kinds of manual offline copies and processes unecessary.
Is there a proper way to move a SQL Server 2016 sharded database from self-hosted to Azure Database?
I have a SQL Server 2016 sharded database that is part of the platform (Sitecore 10) I'm working with. It has a Shard Map Manager database and two Shard databases. I want to migrate the databases from self-hosted to Azure Database.
When the database is in a SQL Server Instance, it has one login mapped to the Shard Map Manger user and both Shard users. Everything works great. Since Azure Database does not use logins the same way and the databases are partially contained, I created separate users in each database in Azure with the same name and password.
Next, I migrated the schema with Azure Data Migration Services and then the data. There are some stored procedures that Sitecore provides to setup permissions and I ran those.
Finally, I updated the ServerName and DatabaseName fields in the [__ShardManagement].[ShardsGlobal] table for the ShardMapManager DB and the [__ShardManagement].[ShardsLocal] table in both Shard databases to match the new server and database names.
When I updated the app to use the new database, it spewed errors into the log, ultimately tracking to a failed login for the user. There are 13 other databases for the app which were also migrated and work fine, only the sharded database does not work in the app. I ran a PowerShell script that tests the connection string for all of the databases. All of the connection strings were successful. Backing out only the connection strings for the sharded database fixes the errors proving that the connection to the sharded databases is the problem.
What did I do wrong and what should I do to fix it?
If the requirement is only to migrate the databases from local to Azure, the best possible way is to use SQL Server Management Studio (SSMS).
The advantage is that you can mention the new database name on Azure while migrating itself and hence no need to change later. But just make sure same named database shouldn't available already in Azure SQL Server.
You can follow the migration steps from my this answer.
Also, my suggestion is to go through the official documents Assessment rules for SQL Server to Azure SQL Database migration, Troubleshoot connecting to the SQL Server Database Engine. I'm sure you will find the useful insights there which could help to make migrated database work properly with the apps.
Here's my setup:
SQL Azure DB - This is the PaaS solution, not SQL Server running on an Azure VM.
Single Page App (Angular.js) hosted on Azure Web App.
My needs:
I'd like to find a packaged solution where we could allow user-configured reporting that could be saved by the user, for running later. Output would ideally be either CSV or PDF.
Initial thoughts:
Could we create a SQL Server installation on an Azure VM, and use SSRS with the SQL Azure DB as the data source?
Are there third party solutions that could meet these needs?
My research so far has shown one answer... migrate your data to SQL Server running on Azure VM, and use SSRS that way.
Any additional suggestions? I'm reluctant to do a data migration if I can avoid it.
Consider PowerBi, there are numerous examples on the web and here is an overview. What you basically get is an excel-like environment with a lot of smart and easy visualizations. I am not sure how well it works, but there is a possibility to ask questions about your data in natural language as well.
It should be pretty easy to connect your database to PowerBi, then your user can configure what kind of visualizations/report does he want to have.
I have about 20 reference tables in my application which is running in an Microsoft hosted SQL database on Azure. I think that this is currently called a SQL Azure database but I'm having difficulty coming up with Microsoft naming.
The data in my reference tables changes very rarely. Is there any way that I can identify these as tables that should be stored in memory. If not mistaken I think this feature is offered on SQL Server 2014 but I think that's not available as a hosted cloud database yet.
if you're referring to Azure SQL Database, this is still not supported today. you might want to explore using Azure Redis Cache instead to cache the datasets.
I am developing an application that will use SQL Azure for the production database. I will be developing locally against SQL Express on my machine. If I make changes to the schema, how do I migrate those changes to SQL Azure but still retain all of my production data? For the initial migration I used SQL Azure Migration Wizard, but that was before I had any data. Should I make a backup of the data, recreate the database with the new schema, and then restore the data?
I think that its a general schema versioning question. One possible solution is having migration scripts that you write and test during development and run on production during deployment phase. Entitiy Framework offers migrations as one of it features. My current prefered tool is FluentMigrator. I works for Azure Sql as well.
In order to migrate changes to SQL Server but still retain all of your production data, it is highly recommended that you version your database schema. This also applies to SQL Azure and all other RDBMSs.
This is very important when there are several developers working on a project but I believe it is also advantageous when you are working on a project by yourself.
RoundhousE is one of several simple tools you can use to achieve database versioning. It served us well for this purpose for the past 4 years: https://code.google.com/p/roundhouse/