Just den här artikeln heter "Why we never want to trick SQL Server into rebuilding a log file" och handlar om vad som händer om man tvingar MS SQL att återskapa en ny transaktionslogg...
Ett litet klipp från artikeln:
Enough beating around the bush, here is an example of why we don't want to trick SQL Server to forcefully re-create a log file:
Say you have a transaction in which you add a row to the order header table (oh) and five rows to the order details table (od). Physically, each command is reflected in the tlog, the page is modified (but still cached) and at commit, the log records are written to the ldf file. There are lots written about these algorithms, but the concepts are pretty simple. For more details, read this.
Say that we forcefully stop SQL Server, delete the ldf file, start SQL Server, see that the database isn't accessible and somehow "trick" SQL Server into creating an ldf file for us. What is the problem? Why is this so bad? The problem is that you can have no confidence in the state of your data, both at the physical level and at the logical level. Let me start explaining what I mean by the logical level and problems at this level:
Inga kommentarer:
Skicka en kommentar