I am running SQL Server 2005.
My db backup scheme is:
Recovery model: FULL
Backup Type: Full
Backup component: Database
Backup set will expire: after 0 days
Overwrite media: Back up to the existing media set, Append to the existing backup set
The db is writing to 250GB drive (232GB actual).
My _Data.mdf file is over 55GB and my _Log.ldf is over 148GB.
We ran into a situation where our drive was filled today. I moved our ab_Full.bak and ab_Log.bak files to another drive to make space - about 45GB. Five hours later, free space is at 37GB.
I'm new to managing SQL server; so, I have some basic questions about my backups.
I know I need to update the db to start managing the transaction log size to help prevent this problem in the future. So, assuming I have enough free space, I:
1. right click the db and choose Backup
2. set 'Backup Type' to 'Transaction Log'
3. change 'Backup set will expire' after to 30 days
4. click 'ok'
My understanding is this will move 'closed' transactions from the transaction log to a backup and truncate the transaction log.
Is this plan sound? Will I need to manually resize the log file afterwards?
Thanks for your time.
Are you backing up the transaction log at any time at all?
If you are using the FULL recovery model, then you need to back up the transaction log in addition to backing up the main database, or if you don't want to back up the log (why would you then use the FULL recovery model?) then at least truncate the log at some regular interval.
You should back up the transaction log before every full backup (and keep it as long as you keep the previous full backup) so you can restore to any point in time since the first full backup you've kept. Also, it might be worth backing up the transaction log more often (the total size is the same) in case something bad happens between two full backups.
The best procedure is to regularly backup your log file. In the mean-time, for 'catastrofic' scenarios like the one you described, you may use this snippet to reduce the size of your log:
http://www.snip2code.com/Snippet/12913/How-to-correctly-Shrink-Log-File-for-SQL
Related
We use IBM DB2 10.1 on Windows Server 2008 R2
Majority of the DB2 space is occupied by fields of the type BLOB and CLOB.
Currently, full backup of the entire database takes very long time and goes beyond time limits.
We tried to use incremental backup to speed up backup, but problem did not go away as BLOB and CLOB fields are still
being pulled into the backup, irrespective of whether they were changed, so it is almost the same as doing a full backup.
We decided to proceed with following approach:
Create a new tablespace and put there tables with BLOBs and CLOBs. Old data will be archived once a year, and this tablespace every day.
Once the size of tablespace exceeds a certain limit, we will create a new space and start writing new data to it, and so on.
Problem occurs with restoration when using above mentioned approach.
Offline backup steps:
Full backup of all data is done.
DB2 -svl%LOG% BACKUP DATABASE %DB_NAME% TO %DB_PATH_BACKUP% COMPRESS EXCLUDE LOGS WITHOUT PROMPTING
Logs are copied.
Backup of a separate tablespace is done.
B2 -svl%LOG% BACKUP DATABASE %DB_NAME% TABLESPACE (TSPACEGEN1) TO %DB_PATH_BACKUP% COMPRESS EXCLUDE LOGS WITHOUT PROMPTING
Logs are copied.
Restoration approach:
Full backup is restored.
RESTORE DB EAPOBLOB FROM "..." TAKEN AT ... REPLACE HISTORY FILE WITHOUT PROMPTING
Logs are copied and ROLLFORWARD performed. So far everything is OK.
ROLLFORWARD DATABASE COMMDB TO END OF LOGS
Backup of a separate tablespace is restored.
RESTORE DATABASE EAPOBLOB TABLESPACE (TSPACEGEN1 ) FROM "..." TAKEN AT WITHOUT PROMPTING
Logs are copied and ROLLFORWARD performed. So far everything is OK.
ROLLFORWARD DATABASE COMMDB TO END OF LOGS
!! when we try to connect to DB:
The following errors were received:
A connection attempt was unsuccessful.
Summary
SQL1117N A connection to or activation of the database cannot be made because of ROLLFORWARD PENDING.
Is this feasible approach for backup and are steps we take to backup and restore adequate?
Is there a better way to speed up backup, while still maintaining same level of resilience?
Im deploying my db, i more or less emptied the db(data) and then created a backup.
the .bak file is over 100mb.
why is this?
how do i get it down?
im using sql server 2008
EDIT
When you back up, please note that SQL Server backup files can contain multiple backups. It does not overwrite by default. If you choose the same backup file and do not choose the overwrite option, it simply adds another backup to the same file. So your file just keeps getting larger.
Run this and all will be revealed:
select dpages *8 [size in kbs]
from sysindexes
where indid <= 1
order by 1 desc
You can also..
Do two backups in a row to have the 2nd backup contain minimal log data. The first backup will contain logged activity so as to be able to recover. The 2nd one would no longer contain them.
There is also an issue with leaked Service Broker handles if you use SSSB in your database with improper code, but if this is the case, the query above will reveal it.
To get the size down, you can use WITH COMPRESSION, eg.
backup database mydb to disk = 'c:\tempdb.bak' with compression
It will normally bring it down to about 20% the size. As Martin has commented above, run also
exec sp_spaceused
To view the distribution of data/logs. From what you are saying, 1.5 MB for first table... down to 8kB on the 45th row, that accounts for maybe tens of MB, so the rest could be in the log file.
In SQL Server Management Studio, I did the query below.
Unfortunately, I forgot to uncomment the WHERE clause.
1647 rows were updated instead of 4.
How can I undo the last statement?
Unfortunately, I've only just finished translating those 1647 rows and was doing final corrections , and thus don't have a backup.
UPDATE [dbo].[T_Language]
SET
[LANG_DE] = 'Mietvertrag' --<LANG_DE, varchar(255),>
,[LANG_FR] = 'Contrat de bail' -- <LANG_FR, varchar(255),>
,[LANG_IT] = 'Contratto di locazione' -- <LANG_IT, varchar(255),>
,[LANG_EN] = 'Tenancy agreement' -- <LANG_EN, varchar(255),>
--WHERE [LANG_DE] like 'Mietvertrag'
There is a transaction protocol, at least I hope so.
A non-committed transaction can be reverted by issuing the command ROLLBACK
But if you are running in auto-commit mode there is nothing you can do....
If you already have a full backup from your database, fortunately, you have an option in SQL Management Studio. In this case, you can use the following steps:
Right click on database -> Tasks -> Restore -> Database.
In General tab, click on Timeline -> select Specific date and time option.
Move the timeline slider to before update command time -> click OK.
In the destination database name, type a new name.
In the Files tab, check in Reallocate all files to folder and then select a new path to save your recovered database.
In the options tab, check in Overwrite ... and remove Take tail-log... check option.
Finally, click on OK and wait until the recovery process is over.
I have used this method myself in an operational database and it was very useful.
Considering that you already have a full backup I’d just restore that backup into separate database and migrate the data from there.
If your data has changed after the latest backup then what you recover all data that way but you can try to recover that by reading transaction log.
If your database was in full recovery mode than transaction log has enough details to recover updates to your data after the latest backup.
You might want to try with DBCC LOG, fn_log functions or with third party log reader such as ApexSQL Log
Unfortunately there is no easy way to read transaction log because MS doesn’t provide documentation for this and stores the data in its proprietary format.
Since you have a FULL backup, you can restore the backup to a different server as a database of the same name or to the same server with a different name.
Then you can just review the contents pre-update and write a SQL script to do the update.
If you can catch this in time and you don't have the ability to ROLLBACK or use the transaction log, you can take a backup immediately and use a tool like Redgate's SQL Data Compare to generate a script to "restore" the affected data. This worked like a charm for me. :)
I have a good way to undo or recovery databases using SQL Server Manager. by following the below points :
1 - Go to Database from left side -> Right-click -> Task-> Restore -> Database.
2- Go to Timeline then select your time.
I've created a Back Up Database Task for a few selected databases in my server. What I want to do is to have only one backup file for any database. The new one could overwrite the old one or create a new one and delete the old one, doesn't matter. I've checked Backup set will expire: 2 days but but evidently this doesn't do what I thought it'd do, it keeps creating new backup files every day. How can accomplish this?
I wouldn’t set the backup to expire in 2 days, as this means that you can only restore the backup for two days once the backup expires you can no longer rebuild the database using it.
In the same why you built a maintenance plan to backup the database you can create a maintenance plan to clean up the system and delete backup over x days old. then just run it after your backup plan.
Use a history cleanup task and then pick, remove everything older than 1 day or whatever your desired time frame is
I am using SQL Express 2005 and do a backup of all DB's every night. I noticed one DB getting larger and larger. I looked at the DB and cannot see why its getting so big! I was wondering if its something to do with the log file?
Looking for tips on how to find out why its getting so big when its not got that much data in it - Also how to optimise / reduce the size?
Several things to check:
is your database in "Simple" recovery mode? If so, it'll produce a lot less transaction log entries, and the backup will be smaller. Recommended for development - but not for production
if it's in "FULL" recovery mode - do you do regular transaction log backups? That should limit the growth of the transaction log and thus reduce the overall backup size
have you run a DBCC SHRINKDATABASE(yourdatabasename) on it lately? That may help
do you have any log / logging tables in your database that are just filling up over time? Can you remove some of those entries?
You can find the database's recovery model by going to the Object Explorer, right click on your database, select "Properties", and then select the "Options" tab on the dialog:
Marc
If it is the backup that keeps growing and growing, I had the same problem. It is not a 'problem' of course, this is happening by design - you are just making a backup 'set' that will simply expand until all available space is taken.
To avoid this, you've got to change the overwrite options. In the SQL management studio, right-click your DB, TASKS - BACKUP, then in the window for the backup you'll see it defaults to the 'General' page. Change this to 'Options' and you'll get a different set of choices.
The default option at the top is 'Append to the existing media set'. This is what makes your backup increase in size indefinitely. Change this to 'Overwrite all existing backup sets' and the backup will always be only as big as one entire backup, the latest one.
(If you have a SQL script doing this, turn 'NOINIT' to 'INIT')
CAUTION: This means the backup will only be the latest changes - if you made a mistake three days ago but you only have last night's backup, you're stuffed. Only use this method if you have a backup regime that copies your .bak file daily to another location, so you can go back to any one of those files from previous days.
It sounds like you are running with the FULL recovery model and the Transaction Log is growing continuously as the result of no Transaction Log backups being taken.
In order to rectify this you need to:
Take a transaction log backup. (See: BACKUP(TRANSACT-SQL) )
Shrink the transaction log file down
to an appropriate size for your needs. (See:How to use DBCC SHRINKFILE.......)
Schedule regular transaction log
backups according to data recovery
requirements.
I suggest reading the following Microsoft reference in order to ensure that you are managing your database environment appropriately.
Recovery Models and Transaction Log Management
Further Reading: How to stop the transaction log of a SQL Server database from growing unexpectedly
One tip for keeping databases small would be at design time, use the smallest data type that you can use.
for Example you may have a status table, do you really need the index to be an int, when a smallint or tinyint will do?
Darknight
as you do a daily FULL backup for your Database , ofcourse it will get so big with time .
so you have to put a plan for your self . as this
1st day: FULL
/ 2nd day: DIFFERENTIAL
/ 3rd day: DIFFERENTIAL
/ 4th day: DIFFERENTIAL
/ 5th day: DIFFERENTIAL
and then start over .
and when you restore your database , if you want to restore the FULL you can do it easily , but when you need to restore the DIFF version , you backup the first FULL before it with " NO-recovery " then the DIFF you need , and then you will have your data back safely .
7zip your backup file for archiving. I recently backed up a database to a 178MB .bak file. After archiving it to a .7z file is was only 16MB.
http://www.7-zip.org/
If you need an archive tool that works with larger files sizes more efficiently and faster than 7zip does, I'd recommend taking a look at LZ4 archiving. I have used it for archiving file backups for years with no issues:
http://lz4.github.io/lz4/