I am having 2 .bak files for the same database in MSSQL Server. One is the test snapshot and the other is the production snapshot. The test one is about 500 MB and the production one is about 10 GB. This is because the Test one has many tables truncated. When I restore them in sql server a .mdf file is created at \Microsoft SQL Server\MSSQL.1\MSSQL\Data folder. But I see that the sze of the .mdf file is about 10 GB even when I restore only the test snapshot. Since the test snapshot has many tables truncated and data is less, I would assume that the the size of the .mdf file should be less than that for production snapshot. But that is not the case. Does sql server reserve space in the mdf file and hence it is the same size for both the versions?
Yes it does reserve space. You can see this in the create database page and later in the properties pages.
MDF = space reserved
bak = 8k pages with data
When the database is restored, it reads the size from sys.database_files. The pages are put back into the same relative place.
Unless you are really short of disk space, I'd leave it... but you can shrink the files if it makes you feel better
You are using (ballpark figures) 64,000 pages but have reserved 12,800,000
i think you need to run the following on your DB.
DBCC SHRINKDATABASE (UserDB, 10);
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'm trying to take a copy of a database into another server. I usually been making backup, copy the backup file to another server and restore it. But the backup is 90GB, and the space left after copying the backup to the destination folder is only 26GB. As you probably understand by now I'm not able to restore the database as it doesn't have enough space. So my question is is possible to restore database by replacing backup file? Any other suggestions? Increasing the disc space is not an option as this is just a testing server and the space will be enough after restoring. Thank you
Depending on your SQL Server version have you tried enabling compressing during backup. You would be surprised by how small the backup file can get after compression. Also if your database is set to SIMPLE recovery you could look to reduce the log file size before you backup.
You can find some steps on how to enable compression during backup here
https://sqlbak.com/blog/how-to-configure-backup-compression/
I'm trying to restore a database from 32MB backup. I have 6GB available on my disk. When I'm trying to restore the backup it shows the insufficient disk space error. How is it possible that a 32MB backup requires more than 6GB of disk space?
Probably because the backup is compressed, or because there is a very large log file that doesn't need to be part of the backup itself, or because the data file itself has been cleaned out - the backup is only comprised of pages that contain data. But when restored, it still has to expand the data file to its original size, even if most of it is empty.
Show us what the size column says when you run:
RESTORE FILELISTONLY FROM DISK = '[path]\whatever.bak';
I had the same issue, I had a 800 MB database backup file which needed 320 GB free space to be restored in destination computer.
Turned out it was just because of database log file, to make sure log file is what caused the matter, right click on intended databse and click on properties, after that in General tab check Size of the database, if it's huge, go to the Files tab and navigate to the path of tfiles.
I ran Shrink command on database and on files through interface but it didn't help, following query saved me eventually:
ALTER DATABASE DataBase_Name SET RECOVERY SIMPLE;
GO
DBCC SHRINKFILE(DataBase_Name_log, 200);
GO
ALTER DATABASE DataBase_Name SET RECOVERY FULL;
GO
It means you have to run query on the database, then create a back file once again.
NB: As you see in the query above, Database recovery mode should be on Simple before SHRINKFILE be executed.
It's always good to double-check which disk you're restoring the mdf and the ldf to, maybe you're creating the files in a full disk, it could happen.
Other than that, I'd suggest restoring that backup in another place, have the files SHRINKed, and backing up it again for a desperate measure.
The other answers explain the reason for the error message but do not provide a solution to the problem. I had the same problem and this is the solution I found.
Plug in an external hard drive with a massive amount of space available, then move the .mdf and .ldf files to the external hard drive. This script can be used to move the files while restoring:
RESTORE DATABASE [MyDb] FROM DISK = N'C:\Data\Backup\MyDb_FULL.bak' WITH FILE = 1, MOVE N'MyDb' TO N'E:\Data\MyDb.mdf', MOVE N'MyDb_log' TO N'E:\Data\MyDb_log.ldf', NOUNLOAD, REPLACE, STATS = 5
Once the database restores successfully to the external drive, you have the option of shrinking the files and then moving them to your hard drive or wherever else you want them to be.
First of all, I know it's better not shrink database. But in our situation we had to shrink the data file to claim more space back.
Environment: SQL Server 2005 x64 SP3 Ent running on Windows Server 2003 Enterprise x64.
The database has one single data file and one log file. Before we run DBCC SHRINKFILE, the data file has 640GB, in which 400GB is free, so the data is about 240GB. To speed up the shrink process,we had to defrag the database first then we shrink data file.
However, after we shrinked the database data file using DBCC SHRINKFILE, the data changed to 490GB. How could it happen?
I asked around include Paul Randal. Here's the possible reason:
When I rebuild indexes for those indexes that were dropped, the indexes would not physically removed from data file, they would be put in deferred drop queue, instead they would stay there and would be dropped in batch.
I discovered an error in a log file while troubleshooting another issue on our SQL 2000 server. I am seeing primary filegroup is full. The MDF and LDF files are in the default location on the system partition, on an NTFS drive. The MDF file is 1962MB in size. Some posts have indicated that the size can't excede 2GB. I ran a db shrinkdatabase against it but it does not appear to have changed the size. Is there a command I need to run first to remove old information first, before running the shrink?
When I go into the Enterprise manager I have 2 SQL groups. Once is local and the other is listed by the server name. The database problem is happening on the 2nd gorup. When I try to manually increase the size of the data file it says due to licensing restrictions I am limited to 2048 MB. The SQL instances in the other group allow me to change that number above 2048 MB.
The 2GB database size limit only applies to MSDE (the free, "desktop" version of SQL 2000). Other SQL 2000 version don't have that limitation.
There is no "magic" way to purge or archive old, historical data. You have to know your database and its structure, your customer requirements, and your data retention needs.
You can try this:
ALTER DATABASE foo ADD FILE (
NAME = 'file2',
FILENAME = 'C:\PATH\TO\FILE.ndf',
SIZE = 100MB,
MAXSIZE = UNLIMITED,
FILEGROWTH = 10MB;
Make sure you back up first.
Also, are you running SQL Server Express? There is a definite 2GB limit there...
MDF files are where the data is stored, so it's possible it holds that much data.
I've got a MDF file of 13GB so I don't believe that limit is correct.
Regarding shrinking this, by removing data, you might delete some data, and then shrink it, or you could extend that filegroup, by adding another data file to it.
Alternatively create a database maintainence plan to reduce the amount of free space per page, and also possibly remove unused space.
I would suggest you extend it, and then review your maintenance plans to ensure they are correct.