I was just shrinking some .ldf log files to reduce some space on my server and I was wondering if when I do so if I am deleting any temp tables that are currently on that server? I wouldn't think so because I would think that those would be stored in the .mdf Data files, but just figured that I would ask!
Thanks!
Temp tables are created in the tempdb database only. Shrinking files on user databases will not impact tempdb.
Temp tables are objects, and are stored in the data file. Log files contain the transaction history of the database. Maintenance operations on a log file could remove the history in the file, but will not remove objects.
Shrinking a database file simply removes unused pages to free up space in a file. If a page is being used, it will not be touched by the shrink operation.
So the answer to you question is no, shrinking log files will not delete temp tables.
Related
I am working on my laptop for my study.
I have a table that has 150 million records.
I have to insert these records into another table.
While doing this process after around 2 hours I get my 150GB harddisk full notification.
when I check created files I see that .ldf size around 120GB while .mdf file around 30GB
I googled and found that ldf is the transaction log.
How can stop this file from creating or empty it during the process of insertion?
You can think of below options to reduce the log file growth:
You can go for SELECT * INTO to load to another table. It is minimally logged operation.
If possible, You can change the recovery model to simple for reducing the amount of log generated
Alternatively, if you want to keep the recovery model as Full, want to recover from the current scenario, then you can do below things to free up space:
Take backup of the log to free up the log file size. Safer approach, in case something goes wrong with full backup in next step, you can restore from the log backup and last available full backup.
Take Full backup of the database.
Once you take Full backup of database, you can delete the log backup taken in step no. 1
How to get rid of deleted data (names, addresses etc) which no longer exist at database but .MDF file still has them.
In my country there is a law obligating me to get rid of these data but I can't.
I've switched database (SQL SERVER 2005) to Simple recovery model, performed full backup and shrinked database and files (data file and log file).
The data still pesist in data file (MDF).
Is the table a heap?
Heaps do not physically remove the data when you delete rows. To reclaim the space create a clustered index on the table.
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.
My sql database .mdf file is 130mb and .ldf file is 1300mb. I want to reduce my .ldf file size.
How can I do it and is there any problem occur after deleted data.
Thanks in advance
To start with, do a full backup, a log backup, and then set up scheduled log backups if you haven't done so already. After a few log backups you can shrink the log file and hopefully it won't grow that large again (unless you do some really unusual updates that touch a lot of data over and over again).
See http://msdn.microsoft.com/en-us/library/ms189275.aspx for more info on the different SQL Server recovery modes and backup requirements.
This is really a two prong question.
One, I'm experiencing a phenomenon where SQL server consumes a lot of tempDB log file space when using a global temp table while using a local temp table will consume data file space?
Is this normal? I can't find anywhere on the web where it talks about consuming log file space in such a way when using global temp tables vs. local temp tables.
Two, if this is expected behavior, is there any way to tell it not to do this :). I have plenty of data space (6 GB), but my log space is restricted (750 MB with limited growth). As usual, the tempDB is setup with Simple Recovery so running into the log file space limit has never been a problem before ... but I've never used global temp tables like I'm using them before either.
Thanks!! Joel
When either form of temporary table is created (local or global) the table is physically created and stored in the tempdb database. Any transactional activity on these tables is therefore logged in the tempdb transaction log file.
There is no setting per say however, you could implement a physical table as opposed to a temporary table in order to store your data within a user database, thereby using the associated data and transaction log file for this database.
If you really want to get stuck in and learn about the tempdb database take a look at the following resources.
Everyning you ever wanted to know about the tempdb database
What is the lifespan of one of these global temp tables? Are they dropped in a reasonable time? "Regular" temp tables get dropped when the user disconnects, if not manually before then, and "Global" (##) temp tables get dropped, if memory serves, when the creating session ends. I can see the log growing if the global temp tables last for a long time, because it could be that the log records governing the temp table activity are still marked as active log records and don't get freed with log backup (full recovery) or checkpoints (simple)
The length of the session will have an impact as noted above.
Also, temporary tables work within transactions and table variable work outside the context of transactions. Because of this the temporary will log entries in the log file that relate to the updates to the use of the table.