A record inserted to a table good while ago with no datetime. Is there any way when this transaction has been done based on the id?
You might be able to do it by importing/digging through the log files and extracting the LSN of the event...
Here's a good link on how to attempt it.
Good luck!
AFAIK, unless you have a datetime column in your table to record the actual time of insertion; there is actually no way to find that out.
You can run DBCC command to check Transaction Log (DBCC LOG ('DB_NAME')) but not sure how much helpful that would be.
You can probably use Server-Side Tracing but have never used that personally.
Nope there is nothing in Sql server that can get you information about that insert unless you have CDC enabled or some sort of Audit Trigger on that table.
Having said all this you do have the Log file which logs details about all the operations in Sql Server. You can use some Third-Party tools to view that Sql Server Transaction Log.
Some of the tools are
Red Gate SQL Log Rescue
Apex Sql Discovery and recovery tool
Related
I have to build a very large table (hundreds of millions of records) from tab-delimited text files that I created with a parsing script and therefore know to be uniform and correct. I would love to find a way to do this without SQL Server using any processing power or disk space to log the transactions--if something goes wrong, I'm happy if the bulk insert just dies without trying to roll back the table to some earlier state. Is that possible?
I've searched extensively on this question and I find mentions of using a "Simple" Recovery Model, but it sounds like that might be only effective with the first bulk insert, when the table is empty? If it matters, I plan to index after all of the bulk inserts have completed.
Any advice would be greatly appreciated.
Bulk logged recovery model is the right one for your scenario, which will be doing minimal logging for bulk operation like BULK INSERT, INDEX maintenance operations, etc.... And in SQL Server there is no operation which is non-logged and everything is logged but based on database recovery model the level of logging and transaction log clearing happens. please find the following link which describes various recovery models.
Anyone know how the underlying replication model in sql server works? Do they essentially depend on UTC datetime values to determine if something is new or do they keep a table of all the changes (like a table of tableID+rowid that have changed).
I am building my own "replication" system and was planning on using the dates to know what to replicate. Then I started wondering what would happen if the date got off in the computer for some reason. The obvious choice is to keep a log of the changes as you go and once you replicate those changes, you remove from the log of changes. But thats a lot of extra work, instead of just checking dates.
I figure if sql server replication works by just checking the dates, then that should be good enough for me.
Any wisdom here?
thanks
As a transaction occurs in SQL Server, it is written to the transaction log along with information pertinent to the transaction.
SQL Server replication uses this transaction log to determine which transactions have not yet been processed and to move them to the subscriber. There is a lot more going on under the hood to keep track of the intersection between transactions, publications, subscriptions, etc. but I will leave that to MSDN documentation about SQL Server replication http://msdn.microsoft.com/en-us/library/ms151198.aspx
Moving on to your point about building your own replication system:
Do not build your own replication system. There are too many complications involved that will cause you to spend many many days working. You will be much better off using the items that are shipped with SQL Server.
SQL Server replication methods are pretty impressive out of the box.
If you outline what causes you to think in terms of building your own replication system, we can help you figure out how to use existing items to provision what you need.
Also, read up as much as you can here to get an idea of what it can do for you http://msdn.microsoft.com/en-us/library/ms151198.aspx
SQL Server has a LogReader job that is aptly named. Replication reads the transaction log and applies appropriate transactions to the subscribing databases.
For one thing SQLServer (and it's not the only one) supports multiple replication algorithms.
You can find here details about the ones implemented in SQLServer 2008. Read first the X Replication Overview then follow the How X Replication works for more details.
In a couple of my tables in my SQL Server 2005 database all of my data has been erased. Is there anyway to get a log in SQL Server of all the statements that have ran in the past day? I am trying to find out if someone did this on accident, there is a vulnerability in my web app, or the actual DB has been compromised.
You're looking for the transaction log. Depending on how, and if, it is setup, you'll be able to see what was run. There some info on it at http://www.databasedesign-resource.com/sql-server-transaction-log.html. Given that, I'm sure you can also Google some better resource.
You could also try running the command DBCC LOG(database,3). It will output the data that is in the transaction log.
See the following there are a couple of programs which will allow you to read the log.
https://web.archive.org/web/20080215075500/http://sqlserver2000.databases.aspfaq.com/how-do-i-recover-data-from-sql-server-s-log-files.html
The one from Red Gate is called SQL Rescue and looks pretty good.
You could try a log rescue tool like Log Rescue
I would also sort out some auditing of your own.
Log Rescue doesn't support SQL 2005 so you could also try Apex SQL Log
There are applications you can buy that can convert a transaction log backup into the actual statements that were run. You may be able to find a trial version of some of these, unfortunately I cannot reccommend any specific one though.
Something else to keep in mind: if a hacker gained enough access to clean out some tables, there's a good chance they gained enough access to have their way with your log files as well.
Make a Transaction Log Backup in SQL Server, download a Trial Version of TOAD for SQL Server there you can import your Transactionlog Backup.
And if you want you can also create INSERT Scripts of the DELETED records. But I dont know if there are any restrictions in the TOAD trial version.
I am a part time developer (full time student) and the company I am working for uses SQL Server 2005. The thing I find strange about SQL Server that if you do a script that involves inserting, updating etc there isn't any real way to undo it except for a rollback or using transactions.
You might say what's wrong with those 2 options? Well if for example someone does an update statement and forgets to put in a WHERE clause, you suddenly find yourself with 13k rows updated and suddenly all the clients in that table are named 'bob'. Now you have the wrath of 13k bobs to face since that "someone" forgot to use a transaction and if you do a rollback you are going to undo critical changes that were needed in other fields.
In my studies I have Oracle. In Oracle you can first run the script then commit it if you find that there isn't any mistakes. I was wondering if there was something that I missed in SQL Server since I am still relatively new in working developer world.
I don't believe you missed anything. Using transactions to prevent against these kind of errors is the best mechanism and it is the same mechanism Oracle uses to protected the end user. The difference is that Oracle implicitly begins a transaction for you whereas in SQL Server you must do it explicitly.
SET IMPLICIT_TRANSACTIONS is what you are probably looking for.
I'm no database/sql server expert and I'm not sure if this is what you're looking for, but there is the possibility to create snapshots of a database. A snapshot allows you to revert the database to that state at any time.
Check this link for more information:
http://msdn.microsoft.com/en-us/library/ms175158.aspx
I think transactions work well. You could rollback the DB (to a previous backup or point in the log), but I think transactions are much simpler.
How about this: never make changes to a production database that have not 1st been tested on your development server, and always make a backup before trying anything that is un-proven.
From what I understand, SQL Server 2008 added an Auditing feature that logs all changes made by users to the various databases and also has the option to roll them back after the fact.
Again, this is from what I've read or overheard from our DBA, but might be worth looking into.
EDIT: After looking into it, it appears to only give the ability to rollback on schema changes, not data modifications (DDL triggers).
If I am doing something with any risk in SQL Server, I write the script like this:
BEGIN TRAN
Insert .... whatever
Update .... whatever
-- COMMIT
The last line is a comment on purpose: I first run the lines before, then make sure there's no error, and then highlight just the word Commit and execute that. This works because in Management Studio you can select a part of the T-SQL and just execute the selected portion.
There are a couple of advantages: Implicit Transactions works too, but it's not the default for SQL Server so you have to remember to turn it on or set options to do that. Also, if it's on all the time, I find it's easy for people to "forget" and leave uncommitted transactions open, which can block others. That's mainly because it's not the default behavior and SQL Server folks aren't used to it.
I was investigating the rapid growth of a SQL Server 2005 transaction log when I found that transaction logs will only truncate correctly - if the sys.databases "log_reuse_wait" column is set to 0 - meaning that nothing is keeping the transaction log from reusing existing space.
One day when I was intending to backup/truncate a log file, I found that this column had a 4, or ACTIVE_TRANSACTION going on in the tempdb. I then checked for any open transactions using DBCC OPENTRAN('tempdb'), and the open_tran column from sysprocesses. The result was that I could find no active transactions anywhere in the system.
Are the settings in the log_reuse_wait column accurate? Are there transactions going on that are not detectable using the methods I described above? Am I just missing something obvious?
I still don't know why I was seeing the ACTIVE_TRANSACTION in the sys.databases log_reuse_wait_desc column - when there were no transactions running, but my subsequent experience indicates that the log_reuse_wait column for the tempdb changes for reasons that are not very clear, and for my purposes, not very relevant. Also, I found that running DBCC OPENTRAN, or the "select open_tran from sysprocess" code, is a lot less informative than using the below statements when looking for transaction information:
select * from sys.dm_tran_active_transactions
select * from sys.dm_tran_session_transactions
select * from sys.dm_tran_locks
Here there are explanations how log_reuse_wait_desc is working:
We also need to understand how the log_reuse_wait_desc reporting mechanism works. It gives the reason why log truncation couldn’t happen the last time log truncation was attempted. This can be confusing – for instance if you see ACTIVE_BACKUP_OR_RESTORE and you know there isn’t a backup or restore operation running, this just means that there was one running the last time log truncation was attempted.
So in your case there is no ACTIVE TRANSACTION right now, but it was when log truncation was attempted last time.
There are a couple of links to additional tools/references you can use to help troubleshoot this problem on the References link for this video:
Managing SQL Server 2005 and 2008 Log Files
That said, the information in log_reuse_wait should be accurate. You likely just had a stalled or orphaned transaction that you weren't somehow able to spot.
My answer from The Log File for Database is Full:
As soon as you take a full backup of the database, and the database is not using the Simple recovery model, SQL Server keeps a complete record of all transactions ever performed on the database. It does this so that in the event of a catastrophic failure where you lose the data file, you can restore to the point of failure by backing up the log and, once you have restored an old data backup, restore the log to replay the lost transactions.
To prevent this building up, you must back up the transaction log. Or, you can break the chain at the current point using the TRUNCATE_ONLY or NO_LOG options of BACKUP LOG.
If you don't need this feature, set the recovery model to Simple.
The data is probably accurate. What you need to do is have a regular transaction log backup. Contrary to other advice you should NOT use the NO_TRUNCATE option on 2005 as it clears the log of transactions committed but it doesn't back them up.
What you should be doing is performing a tail-log backup by using the BACKUP LOG statement with NO_TRUNCATE option. You should be applying regular transaction logs throughout the day as well. This should help keep the size fairly manageable.
Hm, tricky. Could it be that the question it self to sys.databases is causing the ACTIVE_TRANSACTION? In that case though, it should be in the MASTER and not the TEMPDB.