Topic: Corruptings in a DB
At once I will tell, I 1, with mssql am familiar superficially.
I ask the help in DB recovery.
Prehistory. There Lived-was a DB on 10 sas raid. The controler cheap, cache Hdd has not been ungeared. On the adjacent server it is adjusted logshipping. One fine day from the server-receiver logshipping we receive the message
1. Could not redo log record (1718035:250:44), for transaction ID (0:807870501), on page (1:4299870), database ' tis103 ' (database ID 6). Page: LSN = (1717708:15918:51), type = 2. Log: OpCode = 11, context 3, PrevPageLSN: (1716153:4472:2). Restore from a backup of the database, or repair the database.
Got into broad gulls lohshipping, there found the message that it is impossible to recover the next log file since (in a free translation and I I do not remember word-for-word) the file is not correct continuation of a chain.
That for an error I could not understand, therefore simply took down logshipping and started to adjust . In the course of recovery we receive the information that one departed hdd on the working server and all tightly , we do servers. BASIS in suspect, therefore we recover a copy on the beginning of day, we work in it.
Recovery DBCC CheckDB (' bitaya ', REPAIR_ALLOW_DATA_LOSS) produces the following:
Failed to restart the current database. The current database is switched to master.
Msg 5123, Level 16, State 1, Line 3
CREATE FILE encountered operating system error 3 (the System does not manage to find the specified way.) while attempting to open or create the physical file ' L:\tis103_log.ldf '.
Msg 5024, Level 16, State 2, Line 3
No entry found for the primary log file in sysfiles1. Could not rebuild the log.
Msg 5028, Level 16, State 2, Line 3
The system could not activate enough of the database to rebuild the log.
DBCC results for ' bitaya '.
CHECKDB found 0 allocation errors and 0 consistency errors in database ' bitaya '.
Msg 7909, Level 20, State 1, Line 3
The emergency-mode repair failed. You must restore from backup.
From the message I see that mssql tries to find the transaction log on an old way (L: \tis103_log.ldf) where it certainly is not present as I picked up basis on other server. Picked up so: created a DB with a name "bitaya", stopped service of the server and to the place of empty files "bitaya.mdf" and "bitaya_log.ldf" supposed basis files then launched server service. It was necessary to do so because attach did not work, and a copy of basis after falling did not do, and simply copied files mdf and ldf