In SQL Server Management Studio, I did the query below.
Unfortunately, I forgot to uncomment the WHERE clause.
1647 rows were updated instead of 4.
How can I undo the last statement?
Unfortunately, I've only just finished translating those 1647 rows and was doing final corrections , and thus don't have a backup.
UPDATE [dbo].[T_Language]
SET
[LANG_DE] = 'Mietvertrag' --<LANG_DE, varchar(255),>
,[LANG_FR] = 'Contrat de bail' -- <LANG_FR, varchar(255),>
,[LANG_IT] = 'Contratto di locazione' -- <LANG_IT, varchar(255),>
,[LANG_EN] = 'Tenancy agreement' -- <LANG_EN, varchar(255),>
--WHERE [LANG_DE] like 'Mietvertrag'
There is a transaction protocol, at least I hope so.
A non-committed transaction can be reverted by issuing the command ROLLBACK
But if you are running in auto-commit mode there is nothing you can do....
If you already have a full backup from your database, fortunately, you have an option in SQL Management Studio. In this case, you can use the following steps:
Right click on database -> Tasks -> Restore -> Database.
In General tab, click on Timeline -> select Specific date and time option.
Move the timeline slider to before update command time -> click OK.
In the destination database name, type a new name.
In the Files tab, check in Reallocate all files to folder and then select a new path to save your recovered database.
In the options tab, check in Overwrite ... and remove Take tail-log... check option.
Finally, click on OK and wait until the recovery process is over.
I have used this method myself in an operational database and it was very useful.
Considering that you already have a full backup I’d just restore that backup into separate database and migrate the data from there.
If your data has changed after the latest backup then what you recover all data that way but you can try to recover that by reading transaction log.
If your database was in full recovery mode than transaction log has enough details to recover updates to your data after the latest backup.
You might want to try with DBCC LOG, fn_log functions or with third party log reader such as ApexSQL Log
Unfortunately there is no easy way to read transaction log because MS doesn’t provide documentation for this and stores the data in its proprietary format.
Since you have a FULL backup, you can restore the backup to a different server as a database of the same name or to the same server with a different name.
Then you can just review the contents pre-update and write a SQL script to do the update.
If you can catch this in time and you don't have the ability to ROLLBACK or use the transaction log, you can take a backup immediately and use a tool like Redgate's SQL Data Compare to generate a script to "restore" the affected data. This worked like a charm for me. :)
I have a good way to undo or recovery databases using SQL Server Manager. by following the below points :
1 - Go to Database from left side -> Right-click -> Task-> Restore -> Database.
2- Go to Timeline then select your time.
Related
I am trying to create a new database from an old backup of database on the same server.
When using SQL server management studio and trying to restore to the new DB from the backup I get this error
System.Data.SqlClient.SqlError: The backup set holds a backup of a database
other than the existing 'test' database. (Microsoft.SqlServer.Smo)
after googling around I found this piece of code
RESTORE DATABASE myDB
FROM DISK = 'C:\myDB.bak'
WITH MOVE 'myDB_Data' TO 'C:\DATA\myDB.mdf',
MOVE 'myDB_Log' TO 'C:\DATA\myDB_log.mdf'
GO
I was wondering will the move statements mess with the database that the backup came from on that server?
Thanks, all help appreciated.
What I should to do:
Click on 'Restore Database ...' float menu that appears right clicking the "Databases" node on SQL Server Management Studio.
Fill wizard with the database to restore and the new name.
Important If database still exists change the "Restore As" file names in the "Files" tab to avoid "files already in use, cannot overwrite" error message.
What I do
IDk why I prefer to do this:
I create a blank target database with my favorite params.
Then, in "SQL Server Management Studio" restore wizard, I look for the option to overwrite target database. It is in the 'Options' tab and is called 'Overwrite the existing database (WITH REPLACE)'. Check it.
Remember to select target files in 'Files' page.
You can change 'tabs' at left side of the wizard (General, Files, Options)
It's even possible to restore without creating a blank database at all.
In Sql Server Management Studio, right click on Databases and select Restore Database...
In the Restore Database dialog, select the Source Database or Device as normal.
Once the source database is selected, SSMS will populate the destination database name based on the original name of the database.
It's then possible to change the name of the database and enter a new destination database name.
With this approach, you don't even need to go to the Options tab and click the "Overwrite the existing database" option.
Also, the database files will be named consistently with your new database name and you still have the option to change file names if you want.
Checking the Options Over Write Database worked for me :)
Think of it like an archive.
MyDB.Bak contains MyDB.mdf and MyDB.ldf.
Restore with Move to say HerDB basically grabs MyDB.mdf (and ldf) from the back up, and copies them as HerDB.mdf and ldf.
So if you already had a MyDb on the server instance you are restoring to it wouldn't be touched.
The script in the question is just missing the replace statement so the restore script will be
RESTORE DATABASE myDB
FROM DISK = 'C:\myDB.bak' ,
WITH MOVE 'myDB_Data' TO 'C:\DATA\myDB.mdf',
,
MOVE 'myDB_Log' TO 'C:\DATA\myDB_log.mdf' , NOUNLOAD, REPLACE, STATS = 5
In "Back UP" I only get a bak file, but I would like to create .sql file
Use SQL Server's Generate Scripts commend
right click on the database; Tasks -> Generate Scripts
select your tables, click Next
click the Advanced button
find Types of data to script - choose Schema and Data.
you can then choose to save to file, or put in new query window.
results in CREATE and INSERT statements for all table data selected in bullet 2.
This is a possible duplicate of: SQL script to get table content as "SELECT * FROM tblname"
To do a full database backup to File/Query you can use the 'Generate Scripts...' option on the Database.
Open SQL Server Management studio, right click on the database and choose 'Tasks->Generate Scripts...'
Then use the wizard to backup the database. You can script the whole database or parts of it. Two important options: In the 'Advanced' section, you will probably want to ensure 'Type of backup = 'Schema and Data' and the 'Script Statistics' is on.
This will produce a *.sql file that you can use as a backup that includes the schema and table data.
Ok, I read through most of these, but I had no "advanced button". But, there is still a way to do it, it's just a little hard to find, so here you go:
You can generate a script from a database, see http://msdn.microsoft.com/en-us/library/ms178078.aspx
If you want to create a script of your database you right-click on the databases and Generate Scripts (it's in different sub-menus depending on what version of SQL and Enterprise Manager / SQL Server Management studio you're using).
That will, however, only get you the database objects. It will not generate scripts for data. Backing up a database will give you all of the database objects as well as the data, depending on what recovery model your database is set to.
This fellow may have achieved what you are trying to do by creating the backup, and then restoring it and giving it a new name.
This approach copies the data along with all of the database objects.
If you want a file with insert statements for your data have a look here:
This procedure generates INSERT statements using existing data from the given tables and views. Later, you can use these INSERT statements to generate the data. It's very useful when you have to ship or package a database application. This procedure also comes in handy when you have to send sample data to your vendor or technical support provider for troubleshooting purposes.
http://vyaskn.tripod.com/code.htm#inserts
I am running SQL Server 2005.
My db backup scheme is:
Recovery model: FULL
Backup Type: Full
Backup component: Database
Backup set will expire: after 0 days
Overwrite media: Back up to the existing media set, Append to the existing backup set
The db is writing to 250GB drive (232GB actual).
My _Data.mdf file is over 55GB and my _Log.ldf is over 148GB.
We ran into a situation where our drive was filled today. I moved our ab_Full.bak and ab_Log.bak files to another drive to make space - about 45GB. Five hours later, free space is at 37GB.
I'm new to managing SQL server; so, I have some basic questions about my backups.
I know I need to update the db to start managing the transaction log size to help prevent this problem in the future. So, assuming I have enough free space, I:
1. right click the db and choose Backup
2. set 'Backup Type' to 'Transaction Log'
3. change 'Backup set will expire' after to 30 days
4. click 'ok'
My understanding is this will move 'closed' transactions from the transaction log to a backup and truncate the transaction log.
Is this plan sound? Will I need to manually resize the log file afterwards?
Thanks for your time.
Are you backing up the transaction log at any time at all?
If you are using the FULL recovery model, then you need to back up the transaction log in addition to backing up the main database, or if you don't want to back up the log (why would you then use the FULL recovery model?) then at least truncate the log at some regular interval.
You should back up the transaction log before every full backup (and keep it as long as you keep the previous full backup) so you can restore to any point in time since the first full backup you've kept. Also, it might be worth backing up the transaction log more often (the total size is the same) in case something bad happens between two full backups.
The best procedure is to regularly backup your log file. In the mean-time, for 'catastrofic' scenarios like the one you described, you may use this snippet to reduce the size of your log:
http://www.snip2code.com/Snippet/12913/How-to-correctly-Shrink-Log-File-for-SQL
I am using SQL Express 2005 and do a backup of all DB's every night. I noticed one DB getting larger and larger. I looked at the DB and cannot see why its getting so big! I was wondering if its something to do with the log file?
Looking for tips on how to find out why its getting so big when its not got that much data in it - Also how to optimise / reduce the size?
Several things to check:
is your database in "Simple" recovery mode? If so, it'll produce a lot less transaction log entries, and the backup will be smaller. Recommended for development - but not for production
if it's in "FULL" recovery mode - do you do regular transaction log backups? That should limit the growth of the transaction log and thus reduce the overall backup size
have you run a DBCC SHRINKDATABASE(yourdatabasename) on it lately? That may help
do you have any log / logging tables in your database that are just filling up over time? Can you remove some of those entries?
You can find the database's recovery model by going to the Object Explorer, right click on your database, select "Properties", and then select the "Options" tab on the dialog:
Marc
If it is the backup that keeps growing and growing, I had the same problem. It is not a 'problem' of course, this is happening by design - you are just making a backup 'set' that will simply expand until all available space is taken.
To avoid this, you've got to change the overwrite options. In the SQL management studio, right-click your DB, TASKS - BACKUP, then in the window for the backup you'll see it defaults to the 'General' page. Change this to 'Options' and you'll get a different set of choices.
The default option at the top is 'Append to the existing media set'. This is what makes your backup increase in size indefinitely. Change this to 'Overwrite all existing backup sets' and the backup will always be only as big as one entire backup, the latest one.
(If you have a SQL script doing this, turn 'NOINIT' to 'INIT')
CAUTION: This means the backup will only be the latest changes - if you made a mistake three days ago but you only have last night's backup, you're stuffed. Only use this method if you have a backup regime that copies your .bak file daily to another location, so you can go back to any one of those files from previous days.
It sounds like you are running with the FULL recovery model and the Transaction Log is growing continuously as the result of no Transaction Log backups being taken.
In order to rectify this you need to:
Take a transaction log backup. (See: BACKUP(TRANSACT-SQL) )
Shrink the transaction log file down
to an appropriate size for your needs. (See:How to use DBCC SHRINKFILE.......)
Schedule regular transaction log
backups according to data recovery
requirements.
I suggest reading the following Microsoft reference in order to ensure that you are managing your database environment appropriately.
Recovery Models and Transaction Log Management
Further Reading: How to stop the transaction log of a SQL Server database from growing unexpectedly
One tip for keeping databases small would be at design time, use the smallest data type that you can use.
for Example you may have a status table, do you really need the index to be an int, when a smallint or tinyint will do?
Darknight
as you do a daily FULL backup for your Database , ofcourse it will get so big with time .
so you have to put a plan for your self . as this
1st day: FULL
/ 2nd day: DIFFERENTIAL
/ 3rd day: DIFFERENTIAL
/ 4th day: DIFFERENTIAL
/ 5th day: DIFFERENTIAL
and then start over .
and when you restore your database , if you want to restore the FULL you can do it easily , but when you need to restore the DIFF version , you backup the first FULL before it with " NO-recovery " then the DIFF you need , and then you will have your data back safely .
7zip your backup file for archiving. I recently backed up a database to a 178MB .bak file. After archiving it to a .7z file is was only 16MB.
http://www.7-zip.org/
If you need an archive tool that works with larger files sizes more efficiently and faster than 7zip does, I'd recommend taking a look at LZ4 archiving. I have used it for archiving file backups for years with no issues:
http://lz4.github.io/lz4/
Folks,
Assume you receive a disconnected backup of a SQL Server database (2005 or 2008) and you restore that to your SQL Server instance.
Is there a way, is there a system catalog or something, to find out when the last write operation occured on that particular database? I'd like to be able to find out what day a particular database backup was from - unfortunately, that's not really being recorded explicitly anywhere, and checking all dozens of data table for the highest date/time stamp isn't really an option either....
Any ideas? Sure - I can look at the date/time stamp of the *.bak file - but can I find out more precisely from within SQL Server (Management Studio) ??
Thanks!
Marc
If you have access to the SQL Server instance where the backup was originally run, you should be able to query msdb:
SELECT backup_set_id, backup_start_date, backup_finish_date
FROM msdb.dbo.backupset
WHERE database_name = 'MyDBname' AND type = 'D'
There are several table relating to backup sets:
backupfile -- contains one row for each data file or log file backed up
backupmediafamily -- contains one row for each media family
backupmediaset -- contains one row for each backup media set
backupset -- contains one row for each backup set
By querying these tables you can determine when the last backups occurred, what type of backups occurred and where the files were written to.
You can try RESTORE HEADERONLY on your backup file, as described here
that should give you the information you're looking for.
A bit late, but should be what you want.
Each write to the database is an entry in the log file. Which has an LSN.
This must be stored in the backup for log restores at least.
So, how to match LSN to a datetime?
SELECT TOP 5 [End Time] AS BringFirst, *
FROM ::fn_dblog (NULL, NULL)
WHERE [End Time] IS NOT NULL
ORDER BY BringFirst DESC
I've never used this before (just had a play for this answer). Some writes are very likely part of the backup itself, but you should be able to distinguish them with some poking around.
as far as I know in the master database there exists a Log-table where every write is stored with detailed information. BUT I'm unsure if you need to enable the Log-mechanism - so that the default is not to log and you have to enable it.
In Oracle for example it is the way around there exists a system-database table Log that you can query.
If that is not the case - you could still write yourself a trigger and apply that on every table/column needed and do the logging yourself.