I maintain a SQL Server 2017 database server with production (PROD) and reporting (REPORT) databases. The databases have similar structure, but the time span of the production database is 3 years and the archive database contains all data since the beginning of the system delivery.
We want to set up replication from PROD to REPORT so that any new changes to PROD get replicated to REPORT. However, when my colleague set up replication, the REPORT db gets truncated and rebuilt so that it becomes a copy of PROD. Are there any configuration that we are missing to maintain REPORT so that it contains all data including the updates?
Related
I have a script that download an SQL Server backup from SAAS product every night.
I can't change the original database and I created 2 views on the database.
Is there a way to keep the views that I created while restoring a new version of the DB?
I'm setting up an Azure SQL DB for our Web App. We have enabled Point In Time Retention (PITR) and Long Term Retention (LTR). Our process is to keep backups for 1 year.
Periodically, we need to upgrade the DB by applying SQL scripts. Sometimes there is a problem with the upgrade scripts and the upgrade fails. We need to rollback the database to the previous version.
To rollback the DB I tried the restore feature. However, the restore feature seems to only create new DBs; therein lies the problem. Restoring to a new DB and removing the old one works great, but we lose all our backup history. It appears backups are tied to the DB (probably to the ResourceId).
So, how can I use Azure SQL DB and periodically restore a DB and still maintain all the back up history?
Unfortunately, restoring from a backup in Azure SQL Database always creates a new database. The secret here may be to rename the newly restored database with the name of the original database. You will even see that the restored database once renamed it then shows all the security recommendations, automatic tuning recommendations of the original database.
So delete existing database, restored the database, and rename it as the original database.
You can reference this document Recover an Azure SQL database using automated database backups , it gives the answer that all the recover are creating new database.
By default, SQL Database backups are stored in geo-replicated blob storage (RA-GRS). The following options are available for database recovery using automated database backups:
Create a new database on the same SQL Database server recovered to a specified point in time within the retention period.
Create a database on the same SQL Database server recovered to the
deletion time for a deleted database.
Create a new database on any SQL Database server in the same region
recovered to the point of the most recent backups.
Create a new database on any SQL Database server in any other region
recovered to the point of the most recent replicated backups.
If you configured backup long-term retention, you can also create a new database from any LTR backup on any SQL Database server.
improtant:
You cannot overwrite an existing database during restore.
"So, how can I use Azure SQL DB and periodically restore a DB and still maintain all the back up history?"
You can use Database replacement:
If the restored database is intended as a replacement for the original database, you should specify the original database's compute size and service tier. You can then rename the original database and give the restored database the original name using the ALTER DATABASE command in T-SQL.
Hope this helps.
I am having a few reports from multiple data tables (same database). Yesterday I tried to replace my same name database with the latest data. So I renamed existing Database and restored the latest database from the Production server to Development server.
Set the actual name as Development server was using previously. Then I have re-executed SSAS Cubes and dimensions (confirmed execution connection on the same server). But when I tried to refresh the SSRS reports on the screen all the data cell/values are showing '0' or NULL in all the fields.
Is there something that I have missed to get the latest data into the reports? Or is my way of doing this not the actual way to update latest data onto reports?
We have two databases, one at our client's site and another (Main) in our data centre.
Both databases have the same schema, we want to sync the databases periodically (twice a day) so that both should have the same data.
We are you using SQL Server 2008 R2.
Please suggest a good methodology.
The number of rows modified is approx to 400 rows a day
You can create a Job that selects from the client's database tables and inserts in your database tables.
If both the databases are in different servers you can create a linked server at your server and connect it to the client server.
Then you can schedule the job to run whenever you want.
I want to copy production server database to Development server, I am using backup and restore to take production server db to Development server.
I have restored it successfully and added tables and SP in restored DB.
Again next day I have to restore same database, after restore my existing tables and SP will get deleted.
I can not use SP and extra tables on production server DB. I want to copy it to development server with a real time data and on development server I can do anything without impacting to production server db.
Can anyone suggest better way to doing this?
You are saying you want to merge changes.
Use a database diff tool (such as database compare in visual studio 2013 to generate a 'difference' script between your dev and prod database. For example you run this tool against dev and prod and it spits out a bunch of create procedure, view, table etc. scripts
Generate insert scripts for all dev - only tables
Restore prod over dev
Execute the scripts from step 1 and 2 in dev
There is often some human intervention required in any kind of merge. For example what if your prod tables have a column that is a different data type in dev, and your SP's are expecting this?
The other option is to build integrations that just load data from prod into dev, but this requires maintenance as changes occur in dev and prod
Yes, you should take a incremental backup rather than a full backup, since a full backup has already been restored to your Dev database. Then while you re-store it should get the newly created DB objects or data.