I have a SQL Server 2008 Express Database which is 7.8 GB in size
DataFile 1.2 GB
LogFile 6.6 GB
Recovery Model = Full
Auto Shrink = False
On a Live database, what is the best way to reduce the size of this database?
Before you can shrink a database running in full recovery model, you must backup the transaction log. So the procedure is to run a transaction log backup, and then shrink the log file.
If you have never performed a transaction log backup then you will continue to suffer from run-away log files and shrinking it will only be a band-aid solution.
You can also identify unused tables and remove those tables(if there is)
you can create Archive database that will stored some old unused data
you can normalize your database more to reduce table size.
hope this information helps you.
Related
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 had very large data in database(log) after deleting all the records in the database tables but the database size is not reduced , specially Log File(s) Ldf
ROWS 56274.125000 55306.625000
LOG 179705.437500 179567.046875
how i reduce the size ?
Is the database in Full Recovery Model? If so, you will need to implement Transaction log backups before you can shrink the log-file size.
If you do not need transaction log backups (in case your full backup is taken often enough that the business is okay with losing the amount of data since the previous backup), you can switch the database to run in Simple recovery model.
You can find out which recovery model a database is in by right-clicking the database, selecting "Properties", and then checking the "Options" tab.
You can change the recovery model at that location, too. However, before you do, I highly recommend you to read up on the different recovery models, and the implications of changing them.
When you are ready to change the recovery model, you might want to read this first.
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.
Oracle has SQL commands that one can issue so that a transaction does not get logged. Is there something similar for SQL Server 2008?
My scenario: We need Tx logs on servers (Dev, QA, Prod), but maybe we can do without them on developer machines.
You can't do without transaction logs in SQL Server, under any circumstances. The engine simply won't function.
You CAN set your recovery model to SIMPLE on your dev machines - that will prevent transaction log bloating when tran log backups aren't done.
ALTER DATABASE MyDB SET RECOVERY SIMPLE;
There is a third recovery mode not mentioned above. The recovery mode ultimately determines how large the LDF files become and how ofter they are written to. In cases where you are going to be doing any type of bulk inserts, you should set the DB to be in "BULK/LOGGED". This makes bulk inserts move speedily along and can be changed on the fly.
To do so,
USE master ;
ALTER DATABASE model SET RECOVERY BULK_LOGGED ;
To change it back:
USE master ;
ALTER DATABASE model SET RECOVERY FULL ;
In the spirit of adding to the conversation about why someone would not want an LDF, I add this: We do multi-dimensional modelling. Essentially we use the DB as a large store of variables that are processed in bulk using external programs. We do not EVER require rollbacks. If we could get a performance boost by turning of ALL logging, we'd take it in a heart beat.
SQL Server requires a transaction log in order to function.
That said there are two modes of operation for the transaction log:
Simple
Full
In Full mode the transaction log keeps growing until you back up the database. In Simple mode: space in the transaction log is 'recycled' every Checkpoint.
Very few people have a need to run their databases in the Full recovery model. The only point in using the Full model is if you want to backup the database multiple times per day, and backing up the whole database takes too long - so you just backup the transaction log.
The transaction log keeps growing all day, and you keep backing just it up. That night you do your full backup, and SQL Server then truncates the transaction log, begins to reuse the space allocated in the transaction log file.
If you only ever do full database backups, you don't want the Full recovery mode.
What's your problem with Tx logs? They grow? Then just set truncate on checkpoint option.
From Microsoft documentation:
In SQL Server 2000 or in SQL Server
2005, the "Simple" recovery model is
equivalent to "truncate log on
checkpoint" in earlier versions of SQL
Server. If the transaction log is
truncated every time a checkpoint is
performed on the server, this prevents
you from using the log for database
recovery. You can only use full
database backups to restore your data.
Backups of the transaction log are
disabled when the "Simple" recovery
model is used.
If this is only for dev machines in order to save space then just go with simple recovery mode and you’ll be doing fine.
On production machines though I’d strongly recommend that you keep the databases in full recovery mode. This will ensure you can do point in time recovery if needed.
Also – having databases in full recovery mode can help you to undo accidental updates and deletes by reading transaction log. See below or more details.
How can I rollback an UPDATE query in SQL server 2005?
Read the log file (*.LDF) in sql server 2008
If space is an issue on production machines then just create frequent transaction log backups.
How do I increase the size of the transaction log? Is is also possible to temporarily increase the transaction log?
Let's say I have the following scenario. I have a Delete operation that's too big for the current transaction log. I wan't to:
Increase the transaction log (can I detect the current size?, can I tell how large I need the transaction log to be for my operation?)
(Perform my operation)
Backup the transaction log
Restore the size of the transaction log.
Short answer:
SQL 2k5/2k8 How to: Increase the Size of a Database (SQL Server Management Studio) (applies to log also), How to: Shrink a Database (SQL Server Management Studio)
SQL 2K How to increase the size of a database (Enterprise Manager), How to shrink a database (Enterprise Manager)
Long answer: you can use ALTER DATABASE ... MODIFY FILE to change the size of database files, including LOG files. You can look up master_files/sysfiles (2k) or <dbname>.sys.database_files (2k5/2k8) to get the logical name of the log. And you can use DBCC SHRINKFILE to shrink a file (if possible).
can I tell how large I need the
transaction log to be for my
operation?
It depends on a lot of factors (is this new data? is it an update? is it a delete? what recovery model? Do you have compression on SQL 2k8? etc etc) but is usually bigger than you expect. I would estimate 2.5 times the size of the update you are about to perform.
Update:
Missed you say is an DELETE. A rough estimate is 1.5 times the size of the data deleted (including all indexes).
The transaction log can be configured to expand as needed. You set the option to grow automatically.
However when the transaction log gets too big (running out of disk space) or making sql server unusable.
Back up transaction log. SQL will auto truncate inactive transactions
When you restore the transaction log will be reduced
To configure autogrow:
Right click on the database in management studio.
Select Properties
Update Autogrowth value
The most important part is the last line of your scenario: "Restore the size of the transaction log." You mean shrink the log back to its original size.
This is really dangerous for a lot of reasons, and we've covered them in a couple of stories over at SQLServerPedia:
http://sqlserverpedia.com/wiki/Shrinking_Databases
http://sqlserverpedia.com/blog/sql-server-backup-and-restore/backup-log-with-truncate_only-like-a-bear-trap/
http://sqlserverpedia.com/blog/sql-server-bloggers/i-was-in-the-pool-dealing-with-sql-shrinkage/