I am very new to sql server, does anyone know what kind of recovery model for each system databases. I don't know if I should all make it to simple or full in my databases. Because if the database is in full so I need to create a log backup for that.
There's basically an option between simple and full. Which one to use depends on your requirement on what data can be lost in case of a disaster and to what point in time you can restore back to.
In simple recovery model you can only restore up to the latest backup and the only point in time you can restore into is the end time of the backup. If that is not enough, you need to use full. Then you can restore back to any point in time.
The third option is bulk logged, which is basically full with the exception that bulk load operations can be done with minimal logging and you can lose the changes done in the bulk load if the disaster happens before it ended.
Related
I have a database with an LDF file of around 14GB and an MDF file of 12GB.
No one has ever performed a Transaction log backup for this DB.
Though the team always just perform Full DB Backup every morning.
Resulting in the log file size is just growing and growing.
Now, If I take its transaction log backup and truncate log file.
Am I going to lose any data?
I am curious because taking log backup reduces log file size, I just want to make sure that their won't be any impact of my MDF file or Data that we have in DB.
And after taking t-log backup whats the good strategy?
Should we restore it to check if it works fine?
If I restore a t-log backup, is it mandatory to apply Full Backup restore first on that Testing server?
[SQL Server 2012]
The short answer is "you wouldn't lose any more than what you normally would otherwise". However, there are several circumstances that might affect your final decision.
The first question your team should ask itself is, of course, "if we never take log backups, why the database is in the full recovery mode"? For DEV databases, log backups are unnecessary in most cases, so switch it to SIMPLE recovery, issue a checkpoint and then you can truncate the log. Oh, and it shouldn't grow much after that, unless someone would run a large modification batch in a single transaction.
Just make sure you understand the difference between the truncation modes. Most probably, you will need to utilise both NOTRUNCATE and TRUNCATEONLY.
Whether you should start taking log backups regularly depends on your workflow and the importance of the data. The main benefits of the full recovery mode are:
In case of a disaster, you don't lose modifications made after the last full / diff backup, only after the last transaction log backup (which are usually short if taken regularly, and as such put less strain on a server). However, if your transaction log file survived the crash and you were able to perform a tail-log backup after the database became unusable, you lose nothing.
You can perform a point-in-time restore of your database, which sometimes is a crucial capability - for example, when you investigate a data corruption / loss, or for any other investigation of that kind. However, as I've said, development databases are rarely that precious.
So weigh these options, consider your specifics, and the answer will come. If it doesn't, I recommend turning your attention to dba.stackexchange.com, as the question in its current form isn't really about development.
your database recovery model is full that means sql don't over write into ldf data pages until you get log backup , and then over write them
after that your log don't get larger unless you have a huge transaction
so , you may declare some log backup job or change recovery model to simple
and of course the full recovery model is better but remember you should keep every single log backup that you take after last full backup
Can I use the "backup" transact sql command (sql-server 2008)
when my database is used (read/write) by other users.
Or I must switch to single_user mode before doing this?
Yes, it will let you do that. There are considerations though, regarding full and precise restoration of the data should a restore operation become necessary.
Best you read up on the whole thing so you can choose the best back-up method for your situation.
Yes, you can use the "backup" T-SQL command even the database is used (read/write) by other users.
For example, you are going to make a full database backup by T-SQL command:
BACKUP DATABASE Test TO DISK ='D:/Test.bak'
Suppose someone is working with the table at this moment. So, the transaction "A" started before the full backup began, made some changes after the checkpoint and committed before the backup completed.
In this case, the full backup includes all transaction log records starting from the latest active transaction. This implies that the full backup includes the whole transaction "A" with all changes that were made after the checkpoint to apply those changes during the database recovery process.
I have a sql database that I dump data into every 15 minutes using SSIS. The transaction log get's huge and I back it up and shrink it a few times a week. But I know I'm doing something wrong. What is the best practice for me to maintain it? Should it stay ~1GB and I should be backing it up hourly? Since it's a datawarehouse, should I be backing it up at all? Show I be doing something different in SSIS? The datawarehouse recovery model is Bulk Logged.
You should also look to make sure SSIS is setup correct to do minimally logged operations as you may not have it set correctly. Then once that is working correctly, evaluate if you really need bulk logged recovery model: http://msdn.microsoft.com/en-us/library/ms175987(v=sql.105).aspx is good link on subject. If you can quickly (your definition of quick) redo the data that is lost and don't want point in time recovery of non-bulk operations, move to simple recovery, IMHO.
You have a few options with logs and they are related to how you are backing up your database and how much data loss you can stand. If you are doing full backups nightly for example...change you database to simple mode. This truncates your log on commit (meaning once logged operations complete the log cleans itself up) ... there are a lot of articles on this topic ... Google it up and if you need more help post back.
I have one database which contains the most recent data, and I want to replicate the database content into some other servers. Due to non-technical reasons, I can not directly use replicate function or sync function to sync to other SQL Server instances.
Now, I have two solutions, and I want to learn the pros and cons for each solution. Thanks!
Solution 1: detach the source database which contains the most recent data, then copy to the destination servers which need the most recent data, and attach database at the destination servers;
Solution 2: make a full backup of source server for the whole database, then copy data to destination servers and take a full recovery at the destination server side.
thanks in advance,
George
The Detach / Attach option is often quicker than performing a backup as it doesn't have to create a new file. Therefore, the time from Server A to Server B is almost purely the file copy time.
The Backup / Restore option allows you to perform a full backup, restore that, then perform a differential backup which means your down time can be reduced between the two.
If it's data replication you're after, does that mean you want the database functional in both locations? In that case, you probably want the backup / restore option as that will leave the current database fully functional.
EDIT: Just to clarify a few points. By downtime I mean that if you're migrating a database from one server to another, you generally will be stopping people using it whilst it's in transit. Therefore, from the "stop" point on Server A up to the "start" point on Server B this could be considered downtime. Otherwise, any actions performed on the database on server A during transit will not be replicated onto server B.
In regards to the "create a new file". If you detach a database you can copy the MDF file immediately. It's already there ready to be copied. However, if you perform a backup, you have to wait for the .BAK file to be created and then move it to it's new location for a restore. Again this all comes down to is this a snapshot copy or a migration.
Backing up and restoring makes much more sense, even if you might eek out a few extra minutes from a detach attach option instead. You have to take the original database offline (disconnect everyone) prior to a detach, and then the db is unavailable until you reattach. You also have to keep track of all of the files, whereas with a backup all of the files are grouped. And with the most recent versions of SQL Server the backups are compressed.
And just to correct something: DB backups and differential backups do not truncate the log, and do not break the log chain.
In addition, the COPY_ONLY functionality only matters for the differential base, not for the LOG. All log backups can be applied in sequence from any backup assuming there was no break in the log chain. There is a slight difference with the archive point, but I can't see where that matters.
Solution 2 would be my choice... Primarily becuase it won't create any downtime on the source database. The only disadvatage i can see is that depending on the database recovery model, the transaction log will be truncated meaning if you wanted to restore any data from the transaction log you'd be stuffed, you'd have to use your backup file.
EDIT: Found a nice link; http://sql-server-performance.com/Community/forums/p/5838/35573.aspx
So our SQL Server 2000 is giving me the error, "The log file for database is full. Back up the transaction log for the database to free up some log space."
How do I go about fixing this without deleting the log like some other sites have mentioned?
Additional Info: Enable AutoGrowth is enabled growing by 10% and is restricted to 40MB.
To just empty it:
backup log <dbname> with truncate_only
To save it somewhere:
backup log <dbname> to disk='c:\somefile.bak'
If you dont really need transactional history, try setting the database recovery mode to simple.
Scott, as you guessed: truncating the log is a bad move if you care about your data.
The following, free, videos will help you see exactly what's going on and will show you how to fix the problem without truncating the logs. (These videos also explain why that's such a dangerous hack and why you are right to look for another solution.)
SQL Server Backups Demystified
SQL Server Logging Essentials
Understanding Backup Options
Together these videos will help you understand exactly what's going on and will show you whether you want to switch to SIMPLE recovery, or look into actually changing your backup routines. There are also some additional 'how-to' videos that will show you exactly how to set up your backups to ensure availability while managing log file sizing and growth.
ether backup your database logs regularly if you need to recover up to the minute or do other fun stuff like log shipping in the future, or set the database to simple mode and shrink the data file.
DO NOT copy, rename, or delete the .ldf file this will break your database and after you recover from this you may have data in an inconsistent state making it invalid.
I don't think renaming or moving the log file will work while the database is online.
Easiest thing to do, IMO, is to open the properties for the database and switch it to Simple Recovery Model. then shrink the database and then go back and set the DB to Full Recoery Model (or whatever model you need).
Changing the logging mode forces SQL Server to set a checkpoint in the database, after which shrinking the database will free up the excess space.
My friend who faced this error in the past recommends:
Try
Backing up the DB. The maintenance plan includes truncation of these files.
Also try changing the 'recovery mode' for the DB to Simple (instead of Full for instance)
Cause:
The transaction log swells up due to events being logged (Maybe you have a number of transactions failing and being rolled back.. or a sudden peaking in transactions on the server )
You may want to check related SO question:
How do you clear the transaction log in a SQL Server 2005 database?
Well you could take a copy of the transaction log, then truncate the log file, which is what the error message suggests.
If disk space is full and you can't copy the log to another machine over the network, then connect a drive via USB and copy it off that way.
You have the answer in your question: Backup the log, then it will be shrunk.
Make a maintenance plan to regularly backup the database and don't forget to select "Backup the transaction log". That way you'll keep it small.
If it's a non production environment use
dump tran <db_name> with no_log;
Once this has completed shrink the log file to free up disk space. Finally switch database recovery mode to simple.
As soon as you take a full backup of the database, and the database is not using the Simple recovery model, SQL Server keeps a complete record of all transactions ever performed on the database. It does this so that in the event of a catastrophic failure where you lose the data file, you can restore to the point of failure by backing up the log and, once you have restored an old data backup, restore the log to replay the lost transactions.
To prevent this building up, you must back up the transaction log. Or, you can break the chain at the current point using the TRUNCATE_ONLY or NO_LOG options of BACKUP LOG.
If you don't need this feature, set the recovery model to Simple.
My dear friend it is vey important for a DBA to check his log file quite frequently. Because if you don't give much attention towards it some day it is going to give this error.
For this purpose you have to periodically take back up so that the logs file would not faced such error.
Other then this the above given suggestion are quite right.
Rename it it. eg:
old-log-16-09-08.log
Then the SQL server can use a new empty one.