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.
Related
I would like to get Logs or SQL executed on a perticular Date. I tried with v$sql and v$sqlarea. But its not giving old logs. Please help. I need to investigate a big mistake happened on last month.
The only option I see is to restore an old backup to an auxiliary database and try to find the exact time when the mistake happened.
Afterwards you can compare the current database with the auxiliary database and restore the data manually with export or database link + standard sql.
It depends on what went wrong this will be pretty difficult. In any case I wish you good luck!!
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.
Given a entry in a sysdtslog90 table in SQL Server 2005 from an SSIS package, how do you figure out what database agent job the entry was run under?
It looks like, after many tests and examination of the data generated, you should be able to piece out this information for your environment(s) from a mix of the computer, operator, and source columns, and maybe the sourceid if that remains consistant between restarts of SQL Agent. Deriving it by correlating between job run times and the starttime and endtime column is also possible, and even more complex options could be worked through setting the value in the datacode column (however that may be done).
I no longer have anything to do with DTS packages, and so do not have (and cannot generate) any such sample data and provide a better answer. (I'd have made this a comment, but no one else has replied yet, so I'm making it a bit more formal.)
I have a report which on execution connects to the database with my_report_user username. There can be many end-users of the report. And in each execution a new connection to the database will be made with my_report_user (there is no connection pooling)
I have a result set which I think can just be created once (may be on the first run of the report) and other report executions can just reuse that stuff. Basically each report execution should check whether this result set (stored as temp table) exists or not. If it does not exist then create that result set else just reuse whats available.
Should I use local temp tables (#) or global temp tables (##)?
Has anyone tried such stuff and if yes, please let me know what all things should I care about? (Almost simultaneous report runs, etc.)
EDIT: I am using Sql-Server 2005
Neither
If you want to cache result result sets under your own control, then you cannot use temp tables, of any kind. You should use ordinary user tables, stored either in tempdb or even have your own result set cache database.
Temp tables, bot #local and ##shared have a lifetime controlled by the connection(s). If your application disconnect, the temp table is deleted, and this does not work well with what you describe.
The real difficult prolem will be to populate these cached result sets under concurent runs without mixing things up (end up with result sets containing duplicate items from concurent report runs that both believed are the 'first' run).
As a side note SQL Server Reporting Services already does this out-of-the-box. You can cache and share datasets, you can cache and share reports, it already works and was tested for you.
I find #temp tables can be useful in certain scenarios, but not as a best practice. I have yet to find a valid use for global ##temp tables, either in my own work, or in the work of anyone else who has written about them. The only case I can think of is BCP or other external process which needs to build a temporary data store and then retrieve it in some subsequent step. In that case I would prefer to use a permanent table with some kind of key and a background process to handle cleanup.
It sounds like you are getting into an OLTP mode now. Reading up on database warehousing will definitely help you.
When the SQL Server (2000/2005/2008) is running sluggish, what is the first command that you run to see where the problem is?
The purpose of this question is that, when all answers are compiled, other users can benefit by running your command of choice to segregate where the problem might be.
There are other troubleshooting posts regarding SQL Server performance but they can be useful only for specific cases.
If you roll out and run your own custom SQL script,
then would you let others know what
the purpose of the script is
it returns (return value)
to do to figure out where problem is
If you could provide source for the script, please post it.
In my case,
sp_lock
I run to figure out if there are any locks (purpose) to return SQL server lock information. Since result set displays object IDs (thus not so human readable), I would usually skim through result to see if there are abnormally many locks.
Feel free to update tags
Why run a single query when a picture is worth a thousand words!
I prefer to run the freely avaialable Performance Dashboard Reports.
They provide a complete snapshot overview of your servers performance in seconds. You can then choose the a specific area to investigate (locking, currently running queries, wait requests etc.) simply by clicking the apporpriate area on the Dashboard.
http://www.microsoft.com/downloads/details.aspx?FamilyId=1d3a4a0d-7e0c-4730-8204-e419218c1efc&displaylang=en
One slight caveat, I beleive these are only available in SQL 2005 and above.
sp_who
http://msdn.microsoft.com/en-us/library/aa260384(SQL.80).aspx
I want to see "who", what machines/users are running what queries, length of time, etc. I can also easily scan for blocks.
If something is blocking a bunch of other transactions I can use the spid to issue a kill command if necessary.
sp_who_3 - Provides a lot of information available elsewhere but in one nice output. Also has several parameters to allow customized output.
A custom query which combines what you would expect in sp_who with DBCC INPUTBUFFER(spid) to get the last query text on each spid ordered by the blocked/blocking graph.
Process data is avaliable via master..sysprocesses.
sp_who3 returns standand sp_who2 output, until you specify a specific spid, then gives 6 different recordsets about that spid including locks, blocks, what it's currently doing, the T/SQL it's running, and the statement within the T/SQL that is currently running.
Ian Stirk has a great script I like to use as detailed in this article: http://msdn2.microsoft.com/en-ca/magazine/cc135978.aspx
In particular, I like the missing indexes one:
SELECT
DatabaseName = DB_NAME(database_id)
,[Number Indexes Missing] = count(*)
FROM sys.dm_db_missing_index_details
GROUP BY DB_NAME(database_id)
ORDER BY 2 DESC;
DBCC OPENTRAN to see what the oldest active transaction is
Displays information about the oldest
active transaction and the oldest
distributed and nondistributed
replicated transactions, if any,
within the specified database. Results
are displayed only if there is an
active transaction or if the database
contains replication information. An
informational message is displayed if
there are no active transactions.
followed by sp_who2
I use queries like those:
Number of open/active connections in ms sql server 2005