I wanted to reduce the size of my log file in SQL SERVER 2005, which grown to 16 gigs, so I created a backup and used the dbcc shrinkfile command to shrink it. All that is set. Now what should I do with the backup file that is created - should I delete it? What impact will deletion have?
Deleting the file will mean you will not be able to do point-in-time restoration - you will only be able to restore to the last database backup you made.
If point-in-time restores are unimportant to you, you can safely delete the backup - otherwise store it somewhere safe (like a tape, or other removable storage).
If you're not using anything that requires a transaction log (e.g. database mirroring) you could also consider switching the database into "simple recovery mode" which avoids transaction log use anyway.
Related
The SQL is backup my database into many .trn files (in backup folder).
The problem is Azure Data Studio can't restore the database from .trn files. It only works with .bak file.
Is there a way to convert .trn to .bak (single file)?
You need a database backup file (typically bak extension) to go with a transaction log backup file (typically trn extension). A transaction log backup alone cannot be restored.
You can read as much in the documentation on transaction log backups:
Minimally, you must have created at least one full backup before you can create any log backups. After that, the transaction log can be backed up at any time unless the log is already being backed up.
And from Restore a Transaction Log Backup
Backups must be restored in the order in which they were created. Before you can restore a particular transaction log backup, you must first restore the following previous backups without rolling back uncommitted transactions, that is WITH NORECOVERY:
The full database backup and the last differential backup, if any, taken before the particular transaction log backup. Before the most recent full or differential database backup was created, the database must have been using the full recovery model or bulk-logged recovery model.
All transaction log backups taken after the full database backup or the differential backup (if you restore one) and before the particular transaction log backup. Log backups must be applied in the sequence in which they were created, without any gaps in the log chain.
If what you have is a database backup file and several transaction log backup files, and you really need just one backup file, you would have to restore it in a location that can accept the transaction log backup files (e.g. locally, or on your programming environment). Then from the restored database, take a database backup which you can then use as a single backup file.
In SQL Server Management Studio I can take database backups and save them as .bak files, which can also be restored in SQL Server Management Studio.
Is there any difference between doing this and setting up a script which backs up the .MDF and .LDF files - and if there was ever an issue, I could just re-attach the .MDF and .LDF files?
Thanks
It depends on your restore needs and backup space. It's certainly possible to to just reattach MDF and LDF files, but there are some limitations:
You have to detach the database first, make the backup (both files at the same time) and then reattach. This means downtime.
You cannot make incremental backups.
You cannot make differential backups.
You cannot do point-in-time restoration.
You basically have to make a full backup each time you copy the MDF and LDF files, which can really eat up space (thus, it can be better to do incremental or differential backups).
SQL Server has built-in mechanisms that can run without invoking external scripts to do regular backups. MDF and LDF backups require external scripts that have permission to access the data directory, the backup location and the server to attach/detach the database.
Basically, I'd say that unless you have a really good reason to not use the built-in backup functionality, I'd avoid doing manual backups of the MDF and LDF files.
Database backups are much more powerful than backing up the files.
First of all, if you backup the files while the database is in use, because it is changing constantly you may get something that works, or more likely you will get a corrupted file. A proper database backup coordinates ongoing changes with the backup process so that the backup file is perfectly consistent. A file backup may give you a file that has half of the changes in a transaction and not the other half, or,worse, half the changes in a particular page and not the other half.
Secondly, proper database backups let you recover the database to ANY point in time beginning at the oldest full backup, not just the point in time that the backup was made. (You will need the chain of all log backups made since the full backup to do this).
EDIT: note that as pointed out in the comments, the built-in functions don't necessarily provide point-in-time recovery--only if you use the type of backups that provide that functionality (though there are other reasons to use that type of backup even if you don't need point-in-time recovery).
The files generated by SQL Server backup only contains data not free, unused, space. The .mdf and .ndf files will contain (sometimes very large amounts of) empty, unused, space making these files larger than the backup files. And you have to detach the database from SQL Server to copy it out.
I'm using SQL Server 2012 in a local environment. In fact, it is running on my Windows 7 machine. My problem is as follows: I receive a daily backup of my SQL database. Right now, I'm just restoring the whole database on a daily basis by deleting the existing one. This restore task takes quite some time to complete. My understanding of the restore process is that it overwrites the previous database with the new backup.
Is there a way for SQL Server 2012 to just modify the existing database with any changes that have occured in the new backup? I mean, something like comparing the previous database with the updated one and making the necessary changes where needed.
Yes, instead of a full backup you ill need a differential backup. Restore it to move to a "point in time" state of original database.
Make a basic research about full/differential and log backups (too many info for a short answer)
I don't believe so. You can do things with database replication, but that's probably not appropriate.
If you did have something to just pull out changes it might not be faster than a restore anyway. Are you a C# or similar dev? If so, I'd be tempted to write a service which monitored the location of the backup and start the restore programatically when it arrives; might save some time.
If your question is "Can I merge changes from an external DB to my current DB without having to restore the whole DB?" then the answer is "Yes, but not easily." You can set up log shipping, but that's fairly complicated to do automatically. It's also fairly complicated to do manually, but for different reasons: there's no "Microsoft" way to do it. You have to figure out manual log shipping largely on your own.
You could consider copying the tables manually via a Linked Server. If you're only updating a small number of tables this might work just fine, and you could save yourself some trouble. A linked server on your workstation, a few MERGE statements saved to a .sql file, and you could update the important tabled in the DB as you need to.
You can avoid having to run the full backup on the remote server by using differential backups, but it's not particularly pleasant.
My assumption is that currently you're getting a full backup created with the COPY_ONLY option. This allows you to create an out-of-band backup copy that doesn't interfere with existing backups.
To do what you actually want, you'd have to do this: on the server you set up backup to do a full backup on day 1, and then do differential backups on days 2-X. Now, on your local system, you retain the full backup of the DB you created on day 1. You then have all differential backups since day 1. You restore the day 1 full DB, and then restore each subsequent differential in the correct order.
However, differential backups require the backup chain to be intact. You can't use COPY_ONLY with a differential backup. That means if you're also using backup to actually backup the database, you're going to either use these same backups for your data backups, or you'll need to have your data backups using COPY_ONLY, both of which seem philosophically wrong. Your dev database copies shouldn't be driving your prod backup procedures.
So, you can do it, but:
You still have to do a full DB restore.
You have considerably more work to do to restore the DB.
You might break your existing backup procedures of the original DB.
during the setup of the mirroring database in sql server 2012, i accidentally made 2 backup of the original database.
after restoring the database on the mirror server, the databases were not synchronized.
to solve the issue, i changed the recovery model from 'full' to 'simple' and back to 'full' again. and then backed up the database again. when restoring it on the mirror server the mirroring procedure.
my question is why does the synchronization fail if i take more than one full backup of the original database?
It's because of the log chain, mirroring is kind of like restoring transaction log backups to the other server but automatically, for it to work, you need an unbroken log chain from a full backup to the last t-log backup, so the log chain will look like this (with nice sequential LSNs):
Full-1->LogA->LogB->LogC->Full-2->LogD->LogE->LogF etc...
So in the example above, if you restored the Full-1 backup, you can restore log backups A,B,C but not D,E,F. You can only restore those if you restore Full-2.
In mirroring, you take a Full backup of the DB and then restore it, SQL server then looks at the Log Sequence Numbers (LSNs) and transfers transactions that aren't present in the restored mirror database, if you take another full backup, you break the chain of sequential LSNs.
In your case, it's like you restored Full-1 and then tried to apply Logs D,E,F to it, there is a gap in the sequence numbers. It should have worked for you if you had just re-restored the second accidental backup that you took to the mirror server and then started mirroring. By changing the recovery model, you completely reset the log chain and have to start again.
I have two MS SQL 2005 servers, one for production and one for test and both have a Recovery Model of Full. I restore a backup of the production database to the test server and then have users make changes.
I want to be able to:
Roll back all the changes made to the test SQL server
Apply all the transactions that have occurred on the production SQL server since the test server was originally restored so that the two servers have the same data
I do not want to do a full database restore from backup file as this takes far too long with our +200GB database especially when all the changed data is less than 1GB.
EDIT
Based on the suggestions below I have tried restoring a database with NoRecovery but you cannot create a snapshot of a database that is in that state.
I have also tried restoring it to Standby Read only mode which works and I can take a snapshot of the database then and still apply transaction logs to the original db but I cannot make the database writable again as long as there are snapshots against it.
Running:
restore database TestDB with recovery
Results in the following error:
Msg 5094, Level 16, State 2, Line 1 The operation cannot be performed on a database with database snapshots or active DBCC replicas
First off, once you've restored the backup and set the database to "recovered", that's it -- you will never be able to apply another transaction log backup to it.
However, there are database snapshots. I've never used them, but I believe you could use them for this purpose. I think you need to restore the database, leave it in "not restored" mode -- definitly not standby -- and then generate snapshots based on that. (Or was that mirroring? I read about this stuff years ago, but never had reason to use it.)
Then when you want to update the database, you drop the snapshot, restore the "next" set of transaction log backups, and create a fresh snapshot.
However, I don't think this would work very well. Above and beyond the management and maintenance overhead of doing this, if the testers/developers do a lot of modifications, your database snapshot could get very big, even bigger than the original database -- and that's hard drive space used in addition to the "original" database. For infrequently modified databases this could work, but for large OLTP systems, I have serious doubts.
So what you really want is a copy of Production to be made in Test. First, you must have a current backup of production somewhere??. Usually on a database this size full backups are made Sunday nights and then differential backups are made each night during the week.
Take the Sunday backup copy and restore it as a different database name on your server, say TestRestore. You should be able to kick this off at 5:00 pm and it should take about 10 hours. If it takes a lot longer see Optimizing Backup and Restore Performance in SQL Server.
When you get in in the morning restore the last differential backup from the previous night, this shouldn't take long at all.
Then kick the users off the Test database and rename Test to TestOld (someone will need something), then rename your TestRestore database to be the Test database. See How to rename a SQL Server Database.
The long range solution is to do log shipping from Production to TestRestore. The at a moments notice you can rename things and have a fresh Test database.
For the rollback, the easiest way is probably using a virtual machine and not saving changes when you close it.
For copying changes across from the production to the test, could you restore the differential backups or transaction log backups from production to the test db?
After having tried all of the suggestions offered here I have not found any means of accomplishing what I outlined in the question through SQL. If someone can find a way and post it or has another suggestion I would be happy to try something else but at this point there appears to be no way to accomplish this.
Storage vendors (as netapp) provide the ability to have writeable snapshots.
It gives you the ability to create a snapshot within seconds on the production, do your tests, and drop/recreate the snapshot.
It's a long term solution, but... It works
On Server1, a job exists that compresses the latest full backup
On Server2, there's a job that performs the following steps:
Copies the compressed file to a local drive
Decompresses the file to make the full backup available
Kills all sessions to the database that is about to be restored
Restores the database
Sets the recovery model to Simple
Grants db_owner privileges to the developers
Ref:http://weblogs.sqlteam.com/tarad/archive/2009/02/25/How-to-refresh-a-SQL-Server-database-automatically.aspx