Please start any new threads on our new
site at https://forums.sqlteam.com. We've got lots of great SQL Server
experts to answer whatever question you can come up with.
| Author |
Topic |
|
wided
Posting Yak Master
218 Posts |
 Posted - 2010-04-19 : 06:41:49
|
| hellohow can i read then log filethanks |
|
|
tkizer
Almighty SQL Goddess
38200 Posts |
|
|
wided
Posting Yak Master
218 Posts |
Posted - 2010-04-20 : 09:19:49
|
| thankif i can dump the log file and i can shrink it,i think we must can read ithow |
 |
|
|
GilaMonster
Master Smack Fu Yak Hacker
4507 Posts |
Posted - 2010-04-20 : 10:10:28
|
| The log is not intended to be human readable. It's for transactional consistency and it's only the DB engine that needs to read it. It's not an error or informational log.If you're really curious, there's an undocumented command.SELECT * FROM fn_dblog(null, null);Don't expect the output to be particularly easy to comprehend. btw, you shouldn't dump (truncate) or shrink the log. Bad practice both. Please read through this - [url]http://www.sqlservercentral.com/articles/64582/[/url]--Gail ShawSQL Server MVP |
|
|
|
denis_the_thief
Aged Yak Warrior
596 Posts |
Posted - 2010-04-21 : 10:35:23
|
quote:
Originally posted by wided
thankif i can dump the log file and i can shrink it,i think we must can read ithow
It's a good question. I'm sure that would be helpful to be able to read it.I think part of the reason is because it is proprietary. If it were publicly accessible, SQL Server would have to document it. And if they wanted to change the format of the Transaction Log in a future version that would be harder because they would have to explain all their changes to everyone. |
|
|
|
tosscrosby
Aged Yak Warrior
676 Posts |
Posted - 2010-04-21 : 15:03:37
|
| There are some third party tools that can be useful. Case in point, we had a user that after an upgrade, claimed when he entered data it didn't exist in the app. We had upgraded the app and SQL to 2005 (several years ago) onto a new SQL server. Couldn't figure out the problem as it was isolated to this one user. Well, we served up the upgraded application on Citrix, which pointed to the correct SQL server. Unknown to us was he had shortcuts on his desktop pointing to the old verion of the app/database (for whatever reason, the only user who had them). I downloaded an eval copy of a log reader (I think Redgate but it could've been Apex). This allowed me to view the SQL logs and determine he wasn't making a connection to the new version of SQL (could've done it with profiler too, I'm sure). I went to the older server and found he WAS inputting the data, just into the wrong version of the app/database. It might have taken a few days, and a possible roll-backup of the upgrade, to determine what exactly was occuring. The log reader allowed me to make pretty quick work of resolving the problem. It was a free eval copy - not sure I could have justified an expenditure for the product for a one-time use. But, hey, it sure helped in that particular case.Terry-- The problem with socialism is that you eventually run out of other people’s money. -- Margaret Thatcher |
|
|
|
Kristen
Test
22859 Posts |
Posted - 2010-04-21 : 15:37:10
|
| We mark DBs as Read-only and (usually) DBO as part of any migration to new boxWe do the same thing for TEST DBs when we roll out to LIVE / PRODUCTION. DEVs have to specifically ask for the restriction to be lifted - stops people accidentally connecting to TEST when they meant to sort something out on Production.I'm not meaning to point-fingers, just a suggestion - it has saved our backon on a number of occasions. |
|
|
|
|
|
|
|
|
log file