I have a SQL Server DB that is about 13Gb with a 1.6Gb log file. When I back it up, however, it creates a 50Gb .bak file! Why is that?
I have read some commentary here about transaction logs, but my DB runs on my laptop and there is no DB activity during the time of the backup. (It only takes 5 minutes).
My backup type is Full, my recovery type is Full, and I am doing Copy-Only backups. Any ideas? Much appreciated!
I am using SQL 2008 R2, Developer Edition.
It might be because the backup routine is appending the new backup to the same file?
There is an option in the Backup dialog in Sql Management Studio to Append or Overwrite all existing backup sets. If you have Append if will add the backup to the same .bak file and the .bak file will be larger for every backup.
In Transact Sql it is the INIT and NOINIT option which determine if the bak file is overwritten or appended.
In my case, I found that the 500MB database also had a 560MB full text catalogue attached which gets included in the backup file. I thought I'd add this despite another answer having been accepted in case anyone else is still stumped :)
In my case, heavy use of filestream objects made for the largest part of the backup file.
Related
Can any body tel me how to overcome this error when taking a backup in SQL Server 2008 Express?
Backup failed for Server '\SQLEXPRESS'. (Microsoft.SqlServer.SmoExtended)
For help, click: http://go.microsoft.com/fwlink?ProdName=Microsoft+SQL+Server&ProdVer=10.50.1447.4+((KJ_RTM).100213-0103+)&EvtSrc=Microsoft.SqlServer.Management.Smo.ExceptionTemplates.FailedOperationExceptionText&EvtID=Backup+Server&LinkId=20476
System.Data.SqlClient.SqlError: The media loaded on "D:\Project 2014\PayrollBackup" is formatted to support 2 media families, but 1 media families are expected according to the backup device specification. (Microsoft.SqlServer.Smo)
For help, click: http://go.microsoft.com/fwlink?ProdName=Microsoft+SQL+Server&ProdVer=10.50.1447.4+((KJ_RTM).100213-0103+)&LinkId=20476
I just want to take a single backup of my database. But always I have to give two destinations and then when restoring I cant restore the database using a single backup file? Is there anything to configure in SSMS? If any, could you please clearly explain?
EDIT:
BACKUP DATABASE [Payroll] TO DISK = N'D:\Project 2014\PayrollBackup' WITH NOFORMAT, NOINIT, NAME = N'Payroll-Full Database Backup', SKIP, NOREWIND, NOUNLOAD, STATS = 10
GO
A simple solution has arisen (via SSMS), based on the answer of #DMason and answer of #Carol Baker West.
Just create a new media set for a single media family.
The backup statement is using the NOINIT clause. This causes each successive backup to append to the existing backup file. You are attempting to backup to one media set (one file), but it appears the existing backup you are attempting to append to consisted of two media sets (two files).
For a quick turnaround, specify a new filename:
BACKUP DATABASE [Payroll] TO DISK = N'D:\Project 2014\<insert new filename>' WITH ...
The issue for me was there were two sources in the Destination.
After you backup with only one destination, removing the other. You don't get the error anymore.
Let me know if this helps!
I also received the error. In my case, I wanted to specify a different location to which the file should be backed up to. But what it was trying to do, was to now split the backup to both files in both locations - thus the part of the error:
is formatted to support 1 media families, but 2 media families are expected according to the backup device specification. (Microsoft.SqlServer.Smo)
So, remove one of the destinations specified in the 'Destination' section of the Back Up Database wizard. It should only have one destination if it only backed up to one file previously.
I got the same error with my project, so I did a couple of simple things:
Copied my old MyDB.bak file from the default backup path, say C:\Program Files\Microsoft SQL Server\MSSQL14.SQLEXPRESS\MSSQL\Backup
Removed it from there
Backed up new version of DB to the same path. (It now succeeded)
Copied the newly created backup to desired place.
When I was attempting to restore a backup onto another server, I got the same error that you got.
I was able to get past this error by deleting the "Backup Device" object and recreating a new one. As you know, the Backup Device is an object that saves a path to your backup folder and to the backup file. Apparently, it also saves other information like the media family.
In the SSMS interface, expand the Server Objects section, and then the Backup Devices section. Find the named backup device for the database and path that you are getting the error on. Delete that object and recreate it. That should take care of the issue.
Now, just so we are clear, I'm NOT talking about deleting the backup itself. I'm NOT talking about deleting or removing any drives. I'm NOT talking about deleting all of the backup devices listed on your server. I'm simply talking about deleting the backup device (which is an object) for one database on your server.
I received this message when I was adding a database to Always On Group and log backup failed with this message:
'The Backup cannot be performed because the existing media set is formatted with an incompatible version'
Problem: I was using the same backup shared folder as I was using two servers with multiple instances. Database was promoted from SQL Server 2008 R2 to SQL Server 2016. I did not delete the old 2008 R2 backups from that shared folder.
Solution: Try and clear out the old version backups and try again. It worked for me.
Just had a disk and raid failure on the drives holding the our live databases. The log files (.ldf) are on a separate disk array and are OK (I think).
I've recovered the databases from the most recent backup however my question is can I use the logs (LDF files) to update the databases to the most recent point?
It's a Sindows 2003 box running SQL Server 2000 Standard edition.
Thanks!
John
Sorry, no.
You'd need log backups to apply to your full backup.
Don't try to replace the new LDF (created from restore) with the one you've recovered. It won't work because the internal ID and log state (LSN) will not match.
Basically, MDF/LDF files and backup files are unrelated to each other.
I am working on a website that has access data from a database (sql server). It will also be adding, updating deleting records in the database. It seems like there is an MDF file that gets created containing the database schema and all the records I guess? Once development is complete and I want to move this database to a real server then all I need to do is move this MDF file to the real server and that is it? is it that simple? or not really?
Also, I hope the MDF file is not a read-only file and can be updated/modified or is it?
Yes, the MDF data file (and the associated *.LDF transaction log file) contains all the database objects that make up your system.
And yes, you can definitely detach a database (an .MDF/.LDF file pair) from your (dev) SQL Server, copy it onto another "real" Production SQL Server, and re-attach it there, without loss of data or information.
Yes, the MDF file is modifyable - through the SQL Server commands and methods. You should never tamper with the file yourself, directly (flipping bits). Use SQL Server and its official interfaces (T-SQL, ADO.NET etc.) to work with your data.
Yes you can do that. Right click the database and click "detach". Make sure you click the drop connections box and click ok (if you don't do this some errors could occur). You can now move the mdf and ldf files.
However, there is a better way imho. Instead, create a full backup of the database, copy the backup file, and restore from the backup on the new server. Now you have two copies of the database, a development version and a production version.
You will need to take .MDF file as well as .LDF file which will have your logs. You have to take both mdf and ldf files and attach on the real server.
I have a .bak file which contains backup sets of two different databases. It was made by sql server maintenance plan. Now I have to restore both databases. The problem is, that while the first database is restored ok (db_companies) the other database (db_data) gives an error:
Restore failed for Server 'SBSERVER'.
(Microsoft.SqlServer.Smo)
System.Data.SqlClient.SqlError:
Logical file 'CompaniesDB'
is not part of database 'DataDB'. Use
RESTORE FILELISTONLY to list the
logical file names.
(Microsoft.SqlServer.Smo)
The database restore wizards shows up both databases, and I select full and the lastest differential sets. The RESTORE FILELIST command show only the CompaniesDB. What's up with this?
I've also tried RESTORE DATABASE WITH MOVE but it doesn't recognize the DataDB logical name.
Is there any way to restore the DataDB from the backup set?
After doing some intensive research, I finally found out that this is a bug in sql server 2005. After I installed the SP3 everything went fine.
1)If you (in Management Studio), detach db_data, back up the existing mdf and log, then delete database completely, making sure the mdf and log are gone from their original DATA folder.
2)Then, right click on databases and go to "Restore Database"
3)Choose the source first! Go to "From Device" and browse to the .MDF
4)Now expand the drop down list with the heading "To Database" under the "Destination for Restore" section and choose db_data.
5)Click OK
6)It should restore fine, right click on it, go to properties and set the owner.
Note, this is me using MSSQL 08 but if memory serves me right there wasnt a drastic difference in management studio for 05.
Im sure someone else here knows a cleaner way, but the above will work.
The bak file may not have the backup of both databases.
Depending on your setup, it's one backup per file unless the file is actually a "device" and the backup did not initiase the device/file.
So I have been neglecting to do any backups of my fogbugz database, and now the fogbugz ldf file is over 2 and half gigs. Thats been built up over the six months we've been using fogbugz.
I backed up the database, then I backed up, and truncated the transaction log, yet the transaction log is still 2 and a half gigs. I did a shrink on the log file and its still 2 and a half gigs. Nothing I do seems to shrink the file in size.
Is there anyway to fix the problem? Or is the only way back at this point to detach the database, delete the log file and then reattach with a new one?
Perform a full backup of your database. Don't skip this. Really.
Change the backup method of your database to "Simple"
Open a query window and enter "checkpoint" and execute
Perform another backup of the database
Change the backup method of your database back to "Full" (or whatever it was, if it wasn't already Simple)
Perform a final full backup of the database.
Run below queries one by one
USE Database_Name
select name,recovery_model_desc from sys.databases
ALTER DATABASE Database_Name SET RECOVERY simple
DBCC SHRINKFILE (Database_Name_log , 1)
Welcome to the fickle world of SQL Server log management.
SOMETHING is wrong, though I don't think anyone will be able to tell you more than that without some additional information. For example, has this database ever been used for Transactional SQL Server replication? This can cause issues like this if a transaction hasn't been replicated to a subscriber.
In the interim, this should at least allow you to kill the log file:
Perform a full backup of your database. Don't skip this. Really.
Change the backup method of your database to "Simple"
Open a query window and enter "checkpoint" and execute
Perform another backup of the database
Change the backup method of your database back to "Full" (or whatever it was, if it wasn't already Simple)
Perform a final full backup of the database.
You should now be able to shrink the files (if performing the backup didn't do that for you).
Good luck!
This is one of the best suggestion in which is done using query. Good for those who has a lot of databases just like me. Can run it using a script.
https://medium.com/#bharatdwarkani/shrinking-sql-server-db-log-file-size-sql-server-db-maintenance-7ddb0c331668
USE DatabaseName;
GO
-- Truncate the log by changing the database recovery model to SIMPLE.
ALTER DATABASE DatabaseName
SET RECOVERY SIMPLE;
GO
-- Shrink the truncated log file to 1 MB.
DBCC SHRINKFILE (DatabaseName_Log, 1);
GO
-- Reset the database recovery model.
ALTER DATABASE DatabaseName
SET RECOVERY FULL;
GO
Ensure the database's backup mode is set to Simple (see here for an overview of the different modes). This will avoid SQL Server waiting for a transaction log backup before reusing space.
Use dbcc shrinkfile or Management Studio to shrink the log files.
Step #2 will do nothing until the backup mode is set.
You have to shrink & backup the log a several times to get the log file to reduce in size, this is because the the log file pages cannot be re-organized as data files pages can be, only truncated. For a more detailed explanation check this out.
WARNING : Detaching the db & deleting the log file is dangerous! don't do this unless you'd like data loss
I had the same problem, my database log file size was about 39 gigabyte, and after shrinking (both database and files) it reduced to 37 gigabyte that was not enough, so I did this solution:
(I did not need the ldf file (log file) anymore)
(**Important) : Get a full backup of your database before the process.
Run "checkpoint" on that database.
Detach that database (right click on the database and chose tasks >>
Detach...) {if you see an error, do the steps in the end of this text}
Move MyDatabase.ldf to another folder, you can find it in your hard disk in the same folder as your database (Just in case you need it in the future for some reason such as what user did some task).
Attach the database (right click on Databases and chose Attach...)
On attach dialog remove the .ldf file (which shows 'file not found' comment) and click Ok. (don`t worry the ldf file will be created after the attachment process.)
After that, a new log file create with a size of 504 KB!!!.
In step 2, if you faced an error that database is used by another user, you can:
1.run this command on master database "sp_who2" and see what process using
your database.
2.read the process number, for example it is 52 and type "kill 52", now your
database is free and ready to detach.
If the number of processes using your database is too much:
1.Open services (type services in windows start) find SQL Server ... process
and reset it (right click and chose reset).
Immediately click Ok button in the detach dialog box (that showed the
detach error previously).