We had a maintenance plan on our SQL server 2000 database with log shipping from main server to standby server. We had to disable the plan due to disk space issues. After resolving that we did a log backup and enabled the plan, but now the initial trn file being created is huge and we had to stop the job in the middle as it was going towards low disk space again. We didn't do any index rebuild, what could be the cause of trn file getting so big?
We also have an archive server (SQL server 2012), which runs an SSIS module, which copies certain data across and deletes it from main server, could that be related to this? The archive did bloat the main transaction log file (.ldf) but after running the aforementioned log backup the percentage of log space used was reduced and the LDF is not growing anymore for now. The LDF file itself is pretty big.
Related
I am running SQL Server in Windows 10. I have gotten one of the following two errors in all recent queries:
The transaction log for database 'MyDB' is full due to 'ACTIVE_TRANSACTION'.
An error occurred while executing batch. Error message is: There is not enough space on the disk.
I have tried DBCC SQLPERF('logspace') to analyze disk space. The database has very little log space after attempting to perform a query as suggested here. I do not anticipate being able to resolve the issue by shrinking the log file. I tried CREATE DATABASE, then
SELECT *
INTO new_db.table
FROM old_db.table
The following error occurs:
Msg 1101, Level 17, State 12, Line 2
Could not allocate a new page for database 'new_db' because of insufficient disk space in filegroup 'PRIMARY'. Create the necessary space by dropping objects in the filegroup, adding additional files to the filegroup, or setting autogrowth on for existing files in the filegroup.
I have deleted log files from C:\Users\username\AppData\Local\Temp, but the same exceptions occur. I have also cleaned files from my hard drive and recycle bin, as well as defragmenting my hard drive. I have tried adjusting the path for query results to a different directory (Tools>Options>Query Results). I have also dropped a number of tables from the database, exited SQL Server and reconnected, as well as shutting down my computer and restarting it.
The first thing to understand is what kind of recovery mode the database is using.
If you are in FULL recovery mode, it's not enough to take regular backups. You must also take frequent (every 20 minutes, or even faster) transaction log backups. Sql Server will never recycle the transaction log unless you do this, and it will continue to grow until you run out of space.
After you have run a transaction log backup, you should be able to shrink the log file and reclaim that disk space.
If you are not in FULL recovery mode, you may be able to just manually clear or expand the transaction log in Sql Server management studio.
SQL 2008 R2. Full back-up every night with replication to a 2nd server for reporting. Business critical multiple databases. SQL Log files in danger of exceeding available disk space
Shrinkfile did not seem effective. Created backup of log file and then chose GUI option to shrink log file. Having done this log file size is much more manageable. When is it safe to delete the Log file backup, or is it never?
You need to keep the transaction log backups for the full backups that you will potentially use to recover the database. E.g. if you keep the last 7 full backups, you just need to keep the log backups for the last week so you can recover the db to any point of time in the week if something is wrong.
I am attempting to do a poor mans log shipping, manually. I need to move a rather large database from one host, to a VM in Azure. The database is currently 16Gb, and we need to do the switch over within an hour.
Note that Replication, Mirroring and Log Shipping are not options due to issues we have run into, and this manual process is what I need to try and achieve.
What I am attempting is to do a full backup the database a few weeks before, using striping of the bak files (So that if a copy fail happens, it's not the full 16Gb we need to restart the copy of), and copy those files of the full backup over a period of a few days.
For my full backup, I am trying to span the backup file over 15 files:
BACKUP DATABASE MyProductionDatabase
TO
DISK='E:\BackupTrial\V5_DEV_FULL_01.bak',
DISK='E:\BackupTrial\V5_DEV_FULL_02.bak',
DISK='E:\BackupTrial\V5_DEV_FULL_03.bak',
DISK='E:\BackupTrial\V5_DEV_FULL_04.bak',
DISK='E:\BackupTrial\V5_DEV_FULL_05.bak',
DISK='E:\BackupTrial\V5_DEV_FULL_06.bak',
DISK='E:\BackupTrial\V5_DEV_FULL_07.bak',
DISK='E:\BackupTrial\V5_DEV_FULL_08.bak',
DISK='E:\BackupTrial\V5_DEV_FULL_09.bak',
DISK='E:\BackupTrial\V5_DEV_FULL_10.bak',
DISK='E:\BackupTrial\V5_DEV_FULL_11.bak',
DISK='E:\BackupTrial\V5_DEV_FULL_12.bak',
DISK='E:\BackupTrial\V5_DEV_FULL_13.bak',
DISK='E:\BackupTrial\V5_DEV_FULL_14.bak',
DISK='E:\BackupTrial\V5_DEV_FULL_15.bak'
WITH FORMAT,
MEDIANAME = 'V5_DEV_FullBackup',
MEDIADESCRIPTION = 'Striped media set for V5_DEV database';
GO
Then restore that database on the new VM in Azure (Virtual Machine, with SQL Server on it, as I am not sure I can go direct BAK file to AzureSQL).
And then daily or weekly (The database has low usage), do log file backups and copy those backups to the new host and restore. So basically, manually trying to keep the databases in sync.
On go-live day, do a final log file backup on the current host, copy that final bak file to the new host, and then both DBs should be in sync, with only small daily copies.
Then switch the site to use the new DB.
But I am stuck:
The MS example is:
BACKUP LOG AdventureWorks2012
TO MyAdvWorks_FullRM_log1;
GO
And it says:
This example creates a transaction log backup for the
AdventureWorks2012 database to the previously created named backup
device, MyAdvWorks_FullRM_log1.
I'm unsure what they mean by "previously created backup device". I have numerous filenames, because of the striping. How do I do a log file backup, of my full backup?
There may be other backup processes that go on on this database. Will this cause me issues with the log file backups (Another full backup of the database might clear my transaction log before I get my backup done?) How should my daily log file backup look?
I'm unsure what they mean by "previously created backup device".
This means that in tis example they previously created virtual backup device.
So now instead of using syntax backup...**to disk** =... they use
backup ...to <device_name>
You can completely ignore this and backup log to differen files as all the world do:
BACKUP LOG AdventureWorks2012
TO disk = 'V:\backups\log\AdventureWorks2012_20190918.trn;
I have numerous filenames, because of the striping. How do I do a log file backup, of my full backup?
Log backup is not done "of full backup".
First you create a "base" by taking full backup, and it doesn't matter if you stripe it into many files or not, then you take log backup (log backups generally are pretty small and you don't need to strip)
There may be other backup processes that go on on this database. Will
this cause me issues with the log file backups (Another full backup of
the database might clear my transaction log before I get my backup
done?)
Full backups are not a problem for you as they just create other "bases" from which you can start your restore chain. You will have problems if others take log backups, as it will interrupt log backup chain (it's not full backup to clear the log, log truncation is done only by log backups).
You should talk to those who take these log backups if they can take them with copy_only: Copy-Only Backups (SQL Server)
or if they can leave these backups for you on some disk.
Our production server has a large .ldf file (300 gb) associated with a .mdf file. On our DEV server, we restore the DEV database using the production backup from time to time. As our DEV server should not have many transactions associated with it, but the .ldf file is 300 gb also. I shrank the .ldf file to 50 gigs in size. Will the DEV .ldf file grow again after a restore from a production backup?
When you restore a database backup, the size of the database and log files will be whatever file size it was from the original database. So if the file size in prod was 300 GB, it will be 300 GB when you restore it to another database/server. It's common to do two things after restoring a prod database backup to a dev environment - shrink the log file size, and set recovery model to SIMPLE (whether you do either will depend on your needs/requirements).
Since you reduced the file size to 50 GB in size, it can grow to exceed 50 GB for many reasons, but most notably:
You create a transaction that generates an enormous amount of log
You have FULL recovery model, and you generate a lot of log, and never do log backups
You enable some kind of replication feature (replication, CDC, etc.) and never run logreader agent.
Will the DEV .ldf file grow again after a restore from a production
backup?
Yes, in case if your production database log file still has such size - 300 GB your database on dev will again have such log file.
We do not know what is the baseline of your live database.
However, if your production database has no regular heavy DML operations that result in long-running transactions, consider reducing the size of the log file on production to smaller size, for instance to 50 GB.
Also, this reduction will significantly reduce restore time, because LDF files are to be zeroed internally before RESTORE starts writing actual data. It means that SQL Server firstly has to create 300 GB file and write zeroes in it. In contrast with log files, data files can benefit from "instant file initialization" and such zeroing can be skipped if SQL Server instance service account correctly configured to have enough permissions.
Otherwise, every time when you do a restore to a dev environment such maintenance task to be done:
USE yourDev
ALTER DATABASE yourDev SET RECOVERY SIMPLE
-- assumption: only one ldf in db
DBCC SHRINKFILE(2, 1024)
You probably have either a background task that is running and running or a lot of open (long running) transactions that are preventing the log being backed up and shrunk. I bet that the same will happen on your new machine. You need to figure out what is preventing the transaction log from shrinking. You should not have to shrink it yourself.
I have a SQL Server 2005 .BAK file (created with a maintenance plan) that I am trying to restore into a different instance of SQL Server 2005.
Regardless of whether I use the UI or RESTORE DATABASE, the restore process seems to halt at 99%. If I use RESTORE VERIFYONLY FROM DISK='mybackup.bak' it reports that my backup is valid.
Interestingly, immediately after I start the restore process, a 43 GB transaction log file appears in my MSSQL\DATA directory. The .BAK file is 60 MB. The system has more than enough free space for this recovery.
Any suggestions on other restore strategies I should try? I'm going to let the restore run overnight and see what happens.
Thanks
If you have a 43Gb transaction log, depending on the speed of your disks, the restore will take a while. What that means is that when you backed up your db, it had a 43Gb log file and it was empty. So when you restore, the SQL Server has to go and allocate 43Gb for the log file, and it has to physically go and zero out 43Gb, and this takes a while.
What I suggest is to wait a while for restore to complete, couple hours maybe, or do a transaction log backup on production, then shrink the trans log file to say 100Mb and then do a backup, and restore from that.
IT is very important to understand recovery models, and backup models used. Dont just slap a db on production and let it run, if you dont manage it, you will end up with big problems.