I am currently searching a query that can reform data back to its original form.
For example if I do the following query:
UPDATE Pupil
SET Telephone = '999'
WHERE Telephone = '0161'
I have done this query and realized I do not wish to change the telephone and want it as it was before. I understand using views and copying the same table to test query's is useful.
But I am wondering if there is actually a query to redo a update or delete query I have made.
This assumes other data might have already contained 999 which you would want left as it was or you could just revert all 999 back to 0161 by inverting your original query values.
If you have full database logging on and did it during a transaction then it might be possible to rollback just that one transaction... Certainly if you restore an old backup you can rerun the transactional changes since the backup.
Otherwise you may have to restore a backup to a copy database, find the matching record, and update to the old value from that one... Restoring to the same server as for example MyDataBaseName_Old means you can join across the databases to get the old record. e.g.
update MyDatabaseName.dbo.Pupil
set p.Telephone = pold.Telephone
from MyDatabaseName.dbo.Pupil p
inner join MyDatabaseName_Old.dbo.Pupil pold on p.PupilID = pold.PupilID
where pold.Telephone = '0161'
Sorry I can't be more help. Hope it gives you some hints for what else you might want to search for.
You can do it only my means of your BackUps. Use Full BackUp both with Transaction log backup. Then you'll be able to restore your database state to the needed one. Otherwise there is no way to restore updated rows in SQL Server. I've heard that in Oracle there exists a feature to make a query to the state of database, in which it was some time ago. Hope that SQL server will follow them and develop such feature too.
Since you are using SQL Server 2008 R2, you might be interested in Change Data Capture. It wouldn't be an easy crtl-z, but it could help.
Related
I was meant to update a single column of a record in th database but i forgot to specify the id and every single record has now been updated! is there a way i can roll back the data please help!
I was meant to run the following statement :
Update Table set Cusname = "some name" where id = 2;
but i actually ran the following:
update Table set Cusname = "some name"
now every single cusname column has the same name . please help
Please help !
There's not much you can do... this is why you have a good backup strategy in place (and, ideally, don't execute any "ad hoc" t-sql in a production database before testing in a test database, then copy/paste the statements to help avoid these types of errors in the future).
Pulling info from the comments, you can start off by doing something along these lines: Can I rollback a transaction I've already committed? (data loss)
(this is for PostgreSQL, but the idea is the same... stop the server, backup all relevant files, etc).
If you have transaction logging and log backups, you can attempt a point in time restore, but this must be set up prior to your error. See here: Reverse changes from transaction log in SQL Server 2008 R2?
Your best bet in this case may be to spend some time working on resolving without restoring. It looks like you updated your customer names. Do you have another source for customer information? Can you compile an external list of customers and, say, addresses, so you can do a match on those to reset your db's customer names? If so, that might be a much easier route, getting you most of the way to a full recovery of your bonked field. If you don't have a ton of data, you can do this and fill the rest in manually. It's a process, but without a good backup of the db to revert to, it may very well be worth looking at...
Also note that if the database is hosted on a cloud based S/P/Iaas, you may have deeper level backups, or in the case of "SQL Database" (e.g., SQL Azure), point in time backups are set up out of the box even for the lowest service plans.
I just used the SQLAzureMW (SQL Azure Migration Wizard Tool) to migrate my SQL Server database to Azure SQL. It went off without a hitch - all my tables are there, the website is running fine off it, etc.
Here's what's odd: if I execute a simple SELECT statement against my tables, I get only a few of the rows. I assumed they were missing, but my website is using some of those records as if they're there. So I queried with a WHERE clause and BAM - they showed up. How the... what the... why isn't my select showing me everything? This applies to many of the tables I've tested.
SQL Azure
On-Premise
I gave up on MS SQL Management Studio and am instead using SQL Server Object Explorer from Visual Studio 2012/2013. It functions properly and allows inline editing of data.
Consider this SELECT statement:
SELECT
SvcTimeID,
LoginName,
MeanSeconds,
MedianSeconds,
RequestCount,
StdDevSeconds,
SvcDate,
CAST (TS AS INT) AS TS
FROM dbo.SvcTime
WHERE SvcDate >= #SvcDate
Where the parameter is set:
cmd.Parameters["#SvcDate"].Value = DateTime.UtcNow - new TimeSpan(31, 0, 0, 0);
Execute that statement in an Azure Web Role - brought back, say 24 rows.
Now, insert two new rows; wait at least one minute; execute the statement again. Do the recently inserted rows appear? In my case, they did not. Note: the default value of SvcDate in the database is getutcdate().
Move the SQL Azure database from the web edition to the standard (S2) edition. Rows magically appear.
Here is my theory. The issue you had was not with MS SQL Management Studio but with SQL Azure itself where, under certain circumstances, the same query will return the original rows from a cache someplace and will miss the new rows in the database.
This has blown any remaining confidence I had with Azure.
I was scared at first, but I think this has an explanation:
If you inserted some rows in connection "A" and can't find them in other sessions, maybe you have a uncommited transaction. By default, in SQL Server on premise, your second connections would hung until transaction is commited or rolled back. (Isolation level read committed)
Somehow, using the same isolation level, Azure acts differently. I seems to work in some cases as a snapshot isolation. Because of that, you can read from the table, but results are not updated. Or maybe the lock are set in a different way.
To solve this, check sysprocesses for sessions with open_tran > 0 or just be careful commmiting trans. In the example, running commit in your session "A" should do it.
Good luck!
I've got about 13,000 AccountIDs that I need to pull various data from several data tables using left-joins. The total # of accountIDs is in the millions. I don't have write-access to the server but I was wondering if there was a way I could maybe create a custom/temporary table anyway and do a join to that rather than writing a really, really long Where AccountID in (.....) statement. The accountIDs are currently in a single Excel column so I'd have to get them back in the server somehow.
Thoughts?
You can use OPENDATASOURCE to access your Excel file, but someone will have to push you the Excel file to the server (not ideal).
SELECT * FROM OPENDATASOURCE('Microsoft.Jet.OLEDB.4.0',
'Data Source=C:\DataFolder\Documents\TestExcel.xls;Extended Properties=EXCEL 5.0')...[Sheet1$] ;
You can ask your DBA team to install a SQl Server Client on your local machine and set up a linked server to the live server, and you are all set. Ask them to set up a view of the data you need, and give you access to the view. That's all you need, I guess.
By mistake I have updated all the rows of a table with same data for certain columns (missed the statement that contains where clause). Are there any free tools that can help me to restore old data for these rows.
If the recovery model is full then it is possible to go back in time. Other than that, I don't think it's possible to recover that data. Unless you backup your data regularly.
See How to: Restore to a Point in Time (SQL Server Management Studio)
I need to quickly implement a read-only database containing data pulled from two identically structured live databases.
The live dbs are actually company dbs from a Dynamics accounting system so I'm happy for any Dynamics specific advice but this is mostly a SQL question. It's a fairly old version of Dynamics from before Great Plains was acquired by Microsoft. This is on SQL Server 2000.
We have reports and applications which access the Dynamics data. These apps are designed to look at one company db. Now we need to add another. It's appropriate that most of these reports and apps see combined data. They don't really care which company an order or invoice exists in. They only look at a small number of the tables.
It seems to me that the simplest solution is to create a reports only db with combined data. Preferably, we need an efficient way to update this db with changes several times a day.
I'm a developer, not a db expert but here's my plan:
Create the combined reporting db with the required tables initially with the same table structure as the live dbs.
All Dynamics tables seem to have an int identity column called DEX_ROW_ID. I'm not sure what it's used for, (it's not indexed) but that seems like the obvious generic way to uniquely identify rows. On the reporting db I will change it to a normal int (not an identity). I will create a unique index on DEX_ROW_ID in all dbs.
Dynamics does not have timestamps so I will add a timestamp column to tables in the live dbs and a corresponding binary(8) column in the reporting db. I'm assuming and hoping that Dynamics won't be upset by the additional index and column.
Add an int CompanyId column to the reporting db tables and add it to the end of any unique indexes. Most data will be naturally unique even without that. ie, order and invoice numbers etc will be different for the two live dbs. We may need to make some minor changes to the applications but I'm not expecting to do much other than point them to the new reporting db.
Assuming my reporting db is called Reports, the live dbs are Live1 and Live2, the timestamp column is called TS and all dbs are on the same server ... here's my first attempt at an update script for copying the changes in one table called MyTable in Live1 to the reporting db.
USE Reports
CREATE TABLE #Changes
(
ReportId int,
LiveId int
)
/* Collect in a temp table the ids or rows which have been deleted or changed
in the live db L.DEX_ROW_ID will be null if the row has been deleted */
INSERT INTO #Changes
SELECT R.DEX_ROW_ID, L.DEX_ROW_ID
FROM MyTable R LEFT OUTER JOIN Live1.dbo.MyTable L ON L.DEX_ROW_ID = R.DEX_ROW_ID
WHERE R.CompanyId = 1 AND L.DEX_ROW_ID IS NULL OR L.TS <> R.TS
/* Delete rows that have been deleted or changed on the live db
I wonder if using join syntax would run better than the subquery. */
DELETE FROM MyTable
WHERE CompanyId = 1 AND DEX_ROW_ID IN (SELECT ReportId FROM #Changes)
/* Recopy rows that have changed in the live db */
INSERT INTO MyTable
SELECT 1 AS CompanyId, * FROM Live1.dbo.MyTable L
WHERE L.DEX_ROW_ID IN (SELECT ReportId FROM #Changes WHERE LiveId IS NOT NULL)
/* Copy the rows that are new in the live db */
INSERT INTO MyTable
SELECT 1 AS CompanyId, * FROM Live1.dbo.MyTable
WHERE DEX_ROW_ID > (SELECT MAX(DEX_ROW_ID) FROM MyTable WHERE CompanyId = 1)
Then do the same for the Live2 db. Repeat for every table in Reports. I know I should use a parameter #CompanyId instead of the literal but I can't do that for the live db name some I might generate these dynamically with a C# program or something.
I'm looking for any advice, suggestions or critique on what I'm doing here. I know it won't be atomic. Things could be happening on the live db while this script runs. I think we can live with that. We'll probably do a full copy either nightly or weekly when nothing is happening on the live dbs.
We need to favor performance over elegance or perfection. Some initial testing has the first query with the TS comparisons running at about 30 seconds for the biggest table so I'm optimistic that this is going to work but I'd also like to know if I'm missing something obvious or not seeing the forest for the trees.
We don't really want to deal with log files on the reporting db. Can we just set that to simple recovery model and forget about logs?
Thanks
I think there are a couple open questions here.
Do you need these reports to be near-real-time? Or is this this sort of reporting that could live with daily updates? But assume you need up-to-the-minute data.
Have you considered querying the databases directly and merging the data per-report on the fly? You'll have to do a lot of reporting to duplicate the effort that's going to go into designing, creating, and supporting a real-time merged replicated database.
Thirty seconds is (IMHO) unacceptable for any single query against a production database. There could be any number of tuning-related reasons for taking this long, but it at least means you're going to need serious professional SQL Server optimization resources (i.e. people). And if this is a problem for the queries for reports, it doesn't bode well for the queries to maintain a separate database for reporting.
Tuck into the back of your mind the consideration that, if you need to consolidate to a single database, it's worth considering whether you should make it an OLAP database rather than a mirror. The mirror will be quicker and easier, but the OLAP would be far more flexible and powerful in the long term; and it might be well to go the whole way from the beginning.
The last thing I'd want to do is write a custom update script. Try these bulletproof methods first:
Let's hope your production databases are backed up. Restore those backups every night to the reporting server. You can automate restores with the RESTORE command, which will work with a file on a network server.
Use SQL Server replication to push data from the live servers to the backend.
Schedule a DTS package every night to import the entire production database.
This might seem like brute force. But since you're copying a 2000-era database, brute force cannot be a problem with today's hardware. As an added advantage, these methods can be supported by a sysadmin instead of a developer.
Method 1 has the added added advantage of serving as backup verification. :)