I accidentally deleted some rows from the database. But I already have daily database backups.
How can I restore only deleted records from the backup database?
Thanks in advance
You didn't say a database server, so I can't be sure this will work, but I believe the syntax on MSSQL would be:
UPDATE livefile
SET livefile.bloodtypefield=oldfile.bloodtypefieild
FROM [hospital].[dbo].[tblPatientFile] livefile
INNER JOIN [hospitalRapor].[dbo].[tblPatientFile] oldfile on livefile.patientid=oldfile.patientid
I highly recommend running on a test database first to make sure it has the results you want. You will of course need a user who has access to both databases and depending on whether you have triggers etc defined that may take a long time to run on 400k rows.
I take it you have a restore of the database on the same server, in which case assuming all the previous data was correct you could, although you would overwrite any updates to the blood type that have been made since your error.
I would suggest you also backup your 'incorrect' database before you go any further, so that an additional mistakes can be rectified - undone easily so you can at least return to the initial 'error' state instead of compounding problems.
Related
I am very new in Microsoft SQL Server and I am not so into databasess.
Yesterday I made an error and I deletd all the rows inside the wrong table (I should delete the records in another table)
So now it is very important to me restore in some way all the deleted records in this table (only these records and not all the DB, if it is possibile in someway).
for completeness the table is named dbo.VulnerabilityWorkaround and have the following fields:
Id: int not null (is the PK)
Description: varchar(max), not null
I think that the SQL Server
retains the information related to the deleted records in a log file (or in something like it, maybe a DB table...I don't know)
Can in some way restore my original dbo.VulnerabilityWorkaround by a query or something like it?
There is the transaction log, but as far as I know that can be used depending on the backup strategy the database instance has, meaning you would have to fire up a restore backup operation.
Other than restoring a previous backup, I don't think you have much options.
Since you just need one table it could be easier to restore a backup to a different server and then copy/move only the data you need using SSIS or Bulk Import/Export.
Question is in the title really,
I want to know if I can check if the DB has been modified at all since the last backup, as my company change the data very sporadically and we end up with lots of backups all exactly the same.
You could query the last change to any index. This includes changes to tables, since tables are stored as a special form of index (clustered or heap):
select max(last_user_update)
from sys.dm_db_index_usage_stats ius
join sys.databases db
on ius.database_id = db.database_id
where db.name = 'YourDbName'
These statistics are reset after a server restart. You can find the server restart time with:
select create_date
from sys.databases
where database_id = 2 -- tempdb
The easiest way is to keep track of this fact within your schema using a "Last Updated" field. You can have a "global" value (which would be useful in your case where nothing may have changed, but if anything has you should back it up), and/or a column in each table. You can manage this field with triggers, so none of your apps have to care that the field exists, but you could get false positives with this if your apps ever perform updates to records without actually changing the data.
Then it's simple; set up the backup as a scheduled job, predicated on a query checking any and all "Last Updated" fields to see if they're newer than the last backup date (which you can also put somewhere in your schema for quick reference).
I need help writing a TSQL script to modify two columns' data type.
We are changing two columns:
uniqueidentifier -> varchar(36) * * * has a primary key constraint
xml -> nvarchar(4000)
My main concern is production deployment of the script...
The table is actively used by a public website that gets thousands of hits per hour. Consequently, we need the script to run quickly, without affecting service on the front end. Also, we need to be able to automatically rollback the transaction if an error occurs.
Fortunately, the table only contains about 25 rows, so I am guessing the update will be quick.
This database is SQL Server 2005.
(FYI - the type changes are required because of a 3rd-party tool which is not compatible with SQL Server's xml and uniqueidentifier types. We've already tested the change in dev and there are no functional issues with the change.)
As David said, execute a script in a production database without doing a backup or stop the site is not the best idea, that said, if you want to do changes in only one table with a reduced number of rows you can prepare a script to :
Begin transaction
create a new table with the final
structure you want.
Copy the data from the original table
to the new table
Rename the old table to, for example,
original_name_old
Rename the new table to
original_table_name
End transaction
This will end with a table that is named as the original one but with the new structure you want, and in addition you maintain the original table with a backup name, so if you want to rollback the change you can create a script to do a simple drop of the new table and rename of the original one.
If the table has foreign keys the script will be a little more complicated, but is still possible without much work.
Consequently, we need the script to
run quickly, without affecting service
on the front end.
This is just an opinion, but it's based on experience: That's a bad idea. It's better to have a short, (pre-announced if possible) scheduled downtime than to take the risk.
The only exception is if you really don't care if the data in these tables gets corrupted, and you can be down for an extended period.
In this situation, based on th types of changes you're making and the testing you've already performed, it sounds like the risk is very minimal, since you've tested the changes and you SHOULD be able to do it safely, but nothing is guaranteed.
First, you need to have a fall-back plan in case something goes wrong. The short version of a MINIMAL reasonable plan would include:
Shut down the website
Make a backup of the database
Run your script
test the DB for integrity
bring the website back online
It would be very unwise to attempt to make such an update while the website is live. you run the risk of being down for an extended period if something goes wrong.
A GOOD plan would also have you testing this against a copy of the database and a copy of the website (a test/staging environment) first and then taking the steps outlined above for the live server update. You have already done this. Kudos to you!
There are even better methods for making such an update, but the trade-off of down time for safety is a no-brainer in most cases.
And if you absolutely need to do this in live then you might consider this:
1) Build an offline version of the table with the new datatypes and copied data.
2) Build all the required keys and indexes on the offline tables.
3) swap the tables out in a transaction. 00 you could rename the old table to something else as an emergency backup.
sp_help 'sp_rename'
But TEST FIRST all of this in a prod like environment. And make sure your backups are up to date. AND do this when you are least busy.
I think someone with shared access to my SQL Server '05 DB is deleting records from a table in a DB for their own reasons.
Is there any audit table I can check to see manual delete queries which may have been run on the DB in the last X number of days?
Thanks for your help.
Ed
May want to consider using a trigger temporarily.
Here's an example.
I'd add an on delete trigger to the table in question. That would allow you to keep an exact log of deleted records (ie, if on your trigger you insert into another table, etc)
SELECT deqs.last_execution_time AS [Time], dest.TEXT AS [Query]
FROM sys.dm_exec_query_stats AS deqs
CROSS APPLY sys.dm_exec_sql_text(deqs.sql_handle) AS dest
ORDER BY deqs.last_execution_time DESC
SQL Server Profiler is probably the easiest way to do this. You can set it to dump all executed queries to a table in the database, or to a file which might be more suitable in your case. You can also set a filter to capture just the queries you're interested in, or the log files become huge.
Unless you've set things up beforehand (via triggers, running Profiler traces, or the like) no, there is no simple native way to "pull out" commands that have been run against a SQL Server database.
#David's idea of querying the procedure cache is one possibility, but would only work if the execution plan(s) are still in memory.
There are third-party transaction log readers available. They could be used to read the contents of the transaction log, but again that only helps if the data/commands are still in there, and after "X days" that seems unlikely.
Another work-around would depend on backups.
Restore a copmlete backup from before your problem time, and compare and contrast with the current version. This would show if data has been deleted, but not how.
If you are in Full backup mode and you have transaction log backups, you can perform various types of incremental restores and actually observer the deletions happening (if they are), but this would probably require a lot of point-in-time recoveries and would be very time intensive.
I have an SQL table, from which data is being deleted. Nobody knows how the data is being deleted. I added a trigger and know the time, however no jobs are running that would delete the data. I also added a trigger whenever rows are being deleted from this table. I am then inserting the deleted rows and the SYSTEM_USER to a log table, however that doesnt help much. Is there anything better I can do to know who and how the data gets deleted? Would it be possible to get the server id or something? Thanks for any advice.
Sorry: I am using SQL Server 2000.
**update 1*: Its important to find out how the data gets deleted - preferably I would like to know the DTS package or SQL statement that is being executed.
Just a guess, but do you have delete cascades on one of the parent tables (those referenced by foreign keys). If so, when you delete the parent row the entries in the child table are also removed.
If the recovery mode is set to "Full", you can check the logs.
Beyond that, remove any delete grants to the table. If it still happens, whomever is doing it has root/dbo access - so change the password...
Try logging all transactions for the time being, even if if it hurts performance. MS offers a mssql profiler, including for express versions if needed. With it, you should be able to log transactions. As an alternative to profilers, you can use the trace_build stored procedure to dump activity into reference files, then just 'ctrl-f' for any instance of the word 'delete' or other similar keywords. For more info, see this SO page...
Logging ALL Queries on a SQL Server 2008 Express Database?
Also, and this may sound stupid, but investigate the possibility that what you are seeing is not deletes. Instead, investigate if records are simply being 'updated', 'replaced if already exists', 'upserted', or whatever you like to call it. In Mysql, this is the 'INSERT ... ON DUPLICATE KEY UPDATE' statement. I'm not sure of the MSSQL variant.
What recovery model is your database in? If it is full Redgate log Rescue is free and works against SQL2000 which might help you retrieve the deleted data. The Overview Video does appear to show a user column.
Or you could roll your own query against fn_dblog
Change all your passwords. Give as few people delete access as possible.