I have a database for which I created a database project using visual studios.
I have created an Azure Repo and built it using Azure Build Pipelines.
I want to create a release pipeline for the same and deployment group to connect to the server.
My concern is I have multiple databases on the database server and I don't want them to get affected due to the deployment.
As far as I know the changes should affect only the concern database and not other databases.
Am I right or the TSQL scripts created will affect other databases too ?
If you deploy a single database it only your sql script/dacpac affect only this one database. However, if they are on the same server, your deployment may have some impact on other databases as resource utlization may increase during deployment.
Related
I am new to Azure and I have a few doubts I'm having trouble with.
I purchased a DB for which I pay just a few bucks a month for testing purposes. I was able to replicate and connect to the DB just fine.
My problem comes in two scenarios
I cannot find a way, at the SQL Server Management Studio, to back up the DB to my VPS (also at Azure).
Is there a way to create a script to duplicate the database tables and indexes structure in order to copy that database to another machine?
A data-tier application (DAC) is a logical database management entity that describes all SQL Server objects connected with a user's database, such as tables, views, and instance objects, including logins. A DAC package, also known as a DACPAC, is a self-contained unit of SQL Server database deployment that allows data-tier developers and database administrators to package SQL Server objects into a portable artefact called a DAC package.
A BACPAC is a similar artefact that contains both the database schema and the data contained in it.
Using sqlpackage.exe may be run from the command line. There
appear to be two options:
To include data in the extraction, use the ExtractAllTableData option
to extract a DACPAC and then publish it to Azure.
After exporting a BACPAC, import it into Azure.
To more about the operations could be performed using BAPAC and DACPAC, here the MSFT Document.
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.
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.
I need a direction on Database Project deployments in VS 2015.
We have database project in our application, which we deployed in Production database server. later, we don't have access to production database server due to security reasons.
We need to give the customer the database changes as a script, which they will execute against production server. since we don't have access to production database server and we can't compare and generate the incremental script.
What are the possible ways to handle the above problem? what things need to be done?
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/