I have a database "DBName" on SQL Server 2008. I want to take backup of it without logs(.ldf file). Because this log file is around 20 GB and I don't want to increase the size of backup file.
I also want to do this without truncating logs from current Live database.
Meaning, the backed up copy shouldn't contain transaction logs but the live database "DBName" should remain unaffected.
P.S. - I am taking backup through following script. Variables are set from UI in WPF.
exec('BACKUP DATABASE '+ #DBName +' TO DISK ='''+ #DBBackupPath +'''')
Thank you.
EDIT
Should SQL Server Simple Recovery Model help ?
A full backup only contains the portion of the log that was generated during the backup. Should be very small.
If you enable simple recovery that will throw away all logs that are not backed up and break the log chain. Is there a reason to be in full recovery mode? If yes you should probably make yourself more familiar with how to not break the log chain.
Related
My database has filled the drive with the transaction log, its about 15GB and the drive is now full. The database won't start. The database is currently offline.
I can access SQL Server Management Studio, but not sure what to do next to fix up the transaction log, and get the database back on line.
You would appear to have the database set to use the Full recovery model.
The log is supposed to be truncated when the database is backed up using a backup tool that integrates with SQL Server (at that point you have a snapshot of the DB at that point in time for recovery), but if you don't have an appropriate regular backup in place, the log tends to bloat out to fill the available disk space.
If you don't require the full recovery model, then change to the Simple Recovery model (right-click on the database node in SSMS, select Properties and go to the Options page) and then shrink the DB.
Ok, so I'm having a bit of an issue - I executed some code on my SQL Server and didn't realize that I didn't have the WHERE bit selected. Of course, when I saw the "608 rows affected" rather than "1 row affected", I freaked a bit.
Luckily, I have a backup saved, but for some reason, I'm getting a couple issues. Now, I took the server down, so I know that it's not being used by anyone, but it's giving me the following error
"Restore failed for Server 'myserver'.
System.Data.sqlclient.sqlerror: Exclusive access could not be obtained
because the database is in use. (Microsoft.SqlServer.Smo)"
I saw something that stated I should be using
Alter Database Databases
SET SINGLE_USER WITH ROLLBACK IMMEDIATE
RESTORE DATABASE PRODUCT
FROM DISK = ''
but I'm having three reservations about this code. First, I'm completely unsure of how to turn multi_user back on. Second, I don't know where the program stores its backups. Third, this SQL is a bit above my head - I'm relatively new to the language, honestly, so I'm not sure how this will affect things.
Anyone have any answers to my troubles?
I might suggest instead of overwriting the existing database from the backup, that you instead recover the backup with a different database name... this way you can have the current and previous databases side-by-side.
Then, you can simply write an update statement to recover the data from just that one specific table instead of resetting the whole database.
EDIT: The specifics would depend on your environment, but the restore would look something like this:
restore database PRODUCT_OLD
from disk='C:\PRODUCT.bak'
with
move 'PRODUCT_Data' to 'C:\PRODUCT_OLD_Data.MDF',
move 'PRODUCT_Log' to 'C:\PRODUCT_OLD_Log.LDF'
And then the update statement would also be based on your specific table...
right on the database click tasks->takeoffline , when its succeed do the same thing but put it Bring Online
then try to restore your database
Set the database to single user is correct. When you are complete with your restoration you'll execute this
alter database YourDb
set multi_user
As for where your .bak file resides, you'll have to find it prior to restoring.
Scary.
Ok, some things to check:
Make sure you are the only person connected to the server.
Make sure no other applications, web servers, app servers, etc. hold connections to your DB.
Make sure your SQL manager has no open windows to tables or other objects in your database.
THEN you should be able to do the restore w/o single user stuff.
Go to the activity Monitor and see if users are still logged in then kill the process for that user using the respective db.
Then go ahead restore the backup
Let me start by saying I am not an SQL or SQL Server expert by ANY means. I know how to create a database and develop a website that uses it. Beyond that, db administration is completely lost on me :(
that being said I'm stuck. My log file for two of my databases has grown ridiculously large. One is 650MB, and the other is 16 GB that's GIGABYTES! the data in both of these databases is less than 10mb, so I can't imagine how in good god this happened...
I did some research on this which led me to believe that doing either a full database backup or a transactional log backup would fix this...
attempting to do a full database backup I received an error telling me the transaction log was full. so I tried the log backup instead
that worked, and now if I do a full database backup, I no longer get that error.
however, the database log files are still the same size as before.
I went into the shrink too which says that 650mb or so of space is free space, but when I told it to free the space it did nothing. I received no error message, it just closed and did nothing. at least I believe it did nothing because my log files are still gimongous...
so first of all, how in the heck did this happen?! all I did was open my database, change a column here and there. and on the other database I didn't even do that!!
finally, how do I fix this so that I can clear out that log?
any help is appreciated, thanks!
Unless you need point in time restore or need to do frequent backups, it sounds like you can do without the log files. Change to simple recovery mode. That will cause the log to be truncated after each committed transaction instead of waiting for a log file backup.
USE MyDatabase
GO
Backup Log MyDatabase WITH TRUNCATE_ONLY
GO
DBCC SHRINKFILE (MyDatabase_Log, 1)
GO
Note, this will invalid your backup history, so after using TRUNCATE_ONLY you must perform a full backup.
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
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.