quote:

---

Originally posted by Kristen

Interesting that it is trying to create the LDF file in:

'C:\Program Files\Microsoft SQL Server\MSSQL\Data\weeweeslap_log.LDF'

make sure that that folder exists (even if you have no intention of hosting the LDF file there!)

BoL says:
"When sp_attach_single_file_db attaches the database to the server, it builds a new log file and performs additional cleanup work to remove replication from the newly attached database.

Use sp_attach_single_file_db only on databases that were previously detached from the server using an explicit sp_detach_db operation.

Use sp_attach_single_file_db only on databases that have a single log file. Do not use this stored procedure on databases that have multiple log files."

Double check that all that is OK

P.S. Please use SQL BACKUP, rather than File Copy, in future!

Kristen

---

quote:

---

I would stop sql server and simply copy the mdf file and kept tit as backups

---

quote:

---

Originally posted by COCOTON

I am tried to recover a data base SQL, I have a backup complete endorsement to the 24 of January of the 2006, and have all the daily backup's of transactions. But the following error appears to me when I am going to recover log of the 31 of January of the 2006:
Server: Msg 4326, Level 16, State 1, Line 2
The log in this backup set terminates at LSN 11000000247500001, which is too early to apply to the database. A more recent log backup that includes LSN 11000000405300001 can be restored.
Server: Msg 3013, Level 16, State 1, Line 2
RESTORE LOG is terminating abnormally.

---

quote:

---

Originally posted by COCOTON

I am tried to recover a data base SQL, I have a backup complete endorsement to the 24 of January of the 2006, and have all the daily backup's of transactions. But the following error appears to me when I am going to recover log of the 31 of January of the 2006:
Server: Msg 4326, Level 16, State 1, Line 2
The log in this backup set terminates at LSN 11000000247500001, which is too early to apply to the database. A more recent log backup that includes LSN 11000000405300001 can be restored.
Server: Msg 3013, Level 16, State 1, Line 2
RESTORE LOG is terminating abnormally

---

quote:

---

HuwR
Semi-Retired Admin



United Kingdom
14748 Posts
Posted - 20 December 2006 : 08:35:56
--------------------------------------------------------------------------------

like we said, you do really really need the log file, however you could try this

Undocumented DBCC Command REBUILD_LOG

EXEC sp_configure 'allow updates', 1
RECONFIGURE WITH OVERRIDE
GO

BEGIN TRAN

UPDATE master..sysdatabases
SET status = status | 32768
WHERE name = 'MyDatabase'

IF @@ROWCOUNT = 1
BEGIN
COMMIT TRAN
RAISERROR('emergency mode set', 0, 1)
END
ELSE
BEGIN
ROLLBACK
RAISERROR('unable to set emergency mode', 16, 1)
END

GO

EXEC sp_configure 'allow updates', 0
RECONFIGURE WITH OVERRIDE
GO

-- Restart SQL Server at this point.

DBCC REBUILD_LOG('MyDatabase','C:\MyDatabase.ldf')


/*Perform physical and logical integrity checks at this point.
Bcp data out if your integrity checks demonstrate that problems exist.
*/

ALTER DATABASE MyDatabase SET MULTI_USER
GO

-- Set database options and recovery model as desired.
GO

---

quote:

---

Originally posted by sleaklight

quote:

---

Originally posted by Kristen

Interesting that it is trying to create the LDF file in:

'C:\Program Files\Microsoft SQL Server\MSSQL\Data\weeweeslap_log.LDF'

make sure that that folder exists (even if you have no intention of hosting the LDF file there!)

BoL says:
"When sp_attach_single_file_db attaches the database to the server, it builds a new log file and performs additional cleanup work to remove replication from the newly attached database.

Use sp_attach_single_file_db only on databases that were previously detached from the server using an explicit sp_detach_db operation.

Use sp_attach_single_file_db only on databases that have a single log file. Do not use this stored procedure on databases that have multiple log files."

Double check that all that is OK

P.S. Please use SQL BACKUP, rather than File Copy, in future!

Kristen

---

Yes, I double checked everything and I am still without luck

---

shutdown sql

move the current database file or rename it

restart sql server

create a new database of the same name and log file and location as the old database and log file

get rid of the old database.
 you may be able to right click delete it in this situation or used sp_removedb

create a new database of the right size and shape with correct log and data file locations

stop sql

rename the new databases.mdf or delete it if you don't have enough space - do not touch the .ldf

move back in the old database .mdf file or rename it back again

restart sql server

it should come up suspect
--------------------------------
1. From a query window, set the status so that you can update the system
tables by running the following query:
use Master
go
sp_configure "allow", 1
go
reconfigure with override
go
 
2. Then set the status of the DB that is giving you the problem (XXXXX) into
Emergency Mode by running the following query:
 
update sysdatabases set status = 32768 where name = '<DBName>'
go
checkpoint
go
shutdown with nowait
go
 
3. Go into the data directory (MSSQL7\DATA) and rename the log file associated
the DB in question (XXXX.ldf) to some 
temporary name, such as XXXX.TMP.
 
4. Exit the query window.
5. Then start up SQL Server from a DOS command window by issuing: 
sqlservr -c -T3608 -T4022.
6. Bring up another query window and verify that the DB is in emergency mode
by issuing:
select Name, Status from Sysdatabases where name = '<DB_Name>'
 
7. Verify that the status is 32768. If it is, then issue the query:
dbcc traceon(3604)
dbcc rebuild_log ('<DB_Name>','<log_filename>') <--- You will need 
the quotation marks 
REBUILD_LOG should take less than 5 minutes even on a very large 
database. It should complete with the message
DBCC execution completed
8. Take the database out of bypass recovery mode by issuing the command
update sysdatabases set status = 0 where name = '<DBName>'
9. Exit the query window and then shutdown (Ctrl-C in the DOS window) and
restart SQL server. Verify the status of the 
database by running DBCC NEWALLOC and DBCC CHECKDB on the database.

quote:

---

Originally posted by jen

quote:

---

I would stop sql server and simply copy the mdf file and kept tit as backups

---

i missed this part, you should have detached the database first before you did that step, then reattached...

---

quote:

---

Originally posted by gongxia649

no.

---