Tag Info

New answers tagged

1

You need to restore/recover your database. If you can't then yes the code is buried in the system table spaces. But it won't be easy looking through the data file with a hex editor trying to find the code. You should either try to restore the database or just rewrite the code. Do you have a backup of your database? Do you have all of the data files, control ...


0

If you know which rows were accidentally updated, you just don't know what the previous value of those rows were, then what you can do is: Restore to a new non-production server from your base backup. Recover that server to the point just before the error. Write a query to select the values for the rows you know got mistakenly updated. Turn that into a ...


3

Is it possible to restore this to a different file group No. possibly even on a different database) No.


1

A filegroup restore can be done on a database in FULL recovery model. There are requirements and consequences of the restore. You must be using Enterprise Edition. The primary filegroup must be the first restore. Filegroups that are not yet restored remain offline. Start reading at this topic in MSDN: ...


0

Simply make new folder "C:\DB\" and restore there your DB with MOVE option - in any case if you again reinstall another SQL Server VERSION on your PC - this path will NOT BE CHANGED.


-3

RESTORE DATABASE DB_NAME ... WITH RECOVERY, REPLACE; -- will restore your "DB"(overwrite) ALWAYS! Do not listen for "DB_A & DB_B as well". "DB" will be your restored database name. Use RECOVERY for the state "ON-LINE" and REPLACE for overwriting existing database files. Use MOVE for the different file location (different from original one). No other ...


2

Violation of PRIMARY KEY constraint 'PK__backupse__21F79AAB0E391C95'. Cannot insert duplicate key in object 'dbo.backupset'. The duplicate key value is (60979). This might happen if someone have done a reseed on the dbo.backupset. From table definition : PK__backupse* --> clustered, unique, primary key located on PRIMARY --> backup_set_id To fix ...


0

Seems like a good reason to visit the Oracle Documentation site. The 2-day dba documents are very good. If your database is running in ARCHIVELOG mode, it copies all transactions to the archivelog destination. The transactions are always written to the redolog files but when they are full, they are only saved when running in archivelog mode. This enables ...


0

What about using the tables already in the MSDB database, Restorehistory, BackupSet and BackupMediaFamily? These databases will already have all of the backup and restore history. I would check though that in your particular case what the behaviour looks like in the Restorehistory table. You should be able to check in these tables that after your restore ...


0

If try/catch doesn't work for you, then you could add another step to the restore portion to test and see if the database restore worked or not. Or you could run a VERIFYONLY restore first and test it that way.



Top 50 recent answers are included