I have a SQL Server 2012 database, using filestream, which I have backed up. The backup took 24 hours and produced a 300gb file. I now want a backup of just the schema. So I truncated all the tables, and started the backup again. It is taking hours and has not yet reached 10%. I have checked the filestream folder and it is empty. The machine has 8gb of ram, and SQL is using 5gb of it. The database is in Simple recovery mode. Why would the backup still be slow now it is empty?
Related
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.
I have a small SQL Server 2005 database. I take daily backup (automated) and the size of the .bak file typically comes out to be 400MB, growing by 5MB every day (which is inline with its usages).
Last night the size of the backup file jumped to 1GB. Suspecting that someone was trying to fill the database with garbage data, I ran a report (Reports -> Standard Reports -> Disk User By Top Tables) and the total size came out to be around 400MB.
Then thinking maybe something was wrong with the automated backup process, I immediately took backup again but the .bak file came out to be over 1GB. Before this automated backup yesterday, an automated task that defragments indexes also ran. However, all these months, a backup after this index optimization used to actually reduce the size of the .bak file.
I am trying to find an explanation for this big jump in size overnight and also why the .bak file is more than double the size of the the actual database disk usages?
UPDATE: I ran
DBCC SHRINKDATABASE(mydb)
to remove transaction logs. Then took a backup again. The size of the .bak file came out even bigger than last time.
This is the query I ran:
DBCC SHRINKFILE(mydb_log, 1)
BACKUP LOG mydbWITH TRUNCATE_ONLY
DBCC SHRINKFILE(mydb_log, 1)
1 - How are you backing up the data? Maintenance plans?
2 - If you are appending to the same database backup file, the backup will grow!
Check out the contents of the file.
RESTORE FILELISTONLY FROM AdventureWorksBackups WITH FILE=1;
http://technet.microsoft.com/en-us/library/ms173778.aspx
This assumes you have a dump device named AdventureWorksBackups. You can also change it to a DISK='AdventureWorks.bak'.
3 - Also, the maintenance plans do not do a good job with determining when to re-organize/update stats versus rebuild an index.
4 - Check out the ola hallengren scripts. They are way better!
http://ola.hallengren.com/
First, they create a directory structure for you.
c:\backup\<server name>\<database name>\full
c:\backup\<server name>\<database name>\diff
c:\backup\<server name>\<database name>\log
Second, each backup has a date time stamp. No appending to backup files.
Third, they clean up after themselves by passing the number of hours to keep on-line.
Fourth, they handle index fragmentation better - 5-30 = re-organize or 30+ = rebuild.
I usually set up the following for my databases.
1 - system databases - full backup every night, log backups hourly.
2 - user databases - full backup 1 x week, diff backup x 6 days, log backups hourly
Last but not least, SQL Server 2005 does not have native support for compressed backups. This does not mean you can not run a batch file to zip them up afterwards.
Third party tools like QUEST (DELL) and RED GATE used to support their own backup utility. The main reason was to fill this gap. Since SQL Server 2008, compressed backups were available. I think many of the vendors are getting rid of this utility since it is now standard.
The transaction log file for the ReportServerTempDB database (database installed with Reporting Services) is has grown to over 100GB. And I'm not sure why.
Here are the file sizes:
D:\SQLDatabases\ReportServer.mdf - 0.7GB
G:\SQLDatabases\ReportServer.ldf - 1.8GB
E:\SQLDatabases\ReportServerTempDB.mdf - 5GB
G:\SQLDatabases\ReportServerTempDB.ldf - 107.6GB
Recovery mode for all these database is SIMPLE.
We are using SQL Server 2008 R2 Standard Edition.
EDIT: Something that is unique to the reporting services databases:
The collation for these databases is Latin1_General_CI_AS_KS_WS. But for all other database it is Latin1_General_CI_AS.
I don't want to just shink the log files and carry on, because they might just grow again. And I can't see why they should be so large.
Does anyone know what could cause the log file (and the data file) for the ReportServerTempDB database to grow so much
And what I should do about it?
Could this indicate a problem with our Report Server?
You are sure that your temp DB is on recovery model - simple as well?
At least you can shrink the database so you get your disk space back using SHRINK DBCC, check this link for more details: http://msdn.microsoft.com/en-us//library/ms190488.aspx
We had renamed SSRS, but the cleanup / archive procs were still trying to cleanup the old database names. When we changed that, out problem stopped.
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.
We recently moved from a simple DB recovery model (with daily full database dumps) on our SQL Server 2000 Standard database to full recovery -- combined with weekly full database backups, daily incremental, and transaction dumps every 10 minutes.
Our previous reporting DB instance (SQL Server 2005) was built from the daily backups which no longer exist. I can re-build the reporting database by loading the weekly dump, leaving it in recovery mode, and then restore the incremental backups. Unfortunately, this is not easily scriptable and doing this by hand sucks.
Taking additional full backups of the 2000 production database will ruin the incrementals (which are desirable for a number of reasons).
Is there a better way to do this? We can't do log shipping since we're only SQL Server 2000 Standard (eventually we'll upgrade to 2K5).
Depending on how up-to-date your data needs to be, snapshot replication seems like the best fit for you. It's not that difficult to set up and I believe that it's fairly common in scenarios like yours.