Hello:
When attaching a database that was detached from another SQL Server instance
and copied over to this machine, I got the error message below:
Error 602: Could not find row in sysindexes for database ID 7, object ID 1,
index ID 1. Run DBCC CHECKTABLE on sysindexes.
Can somebody guide me on the steps I have to follow to resolve this issue?
Thanks.
Venki
Hi
On the original server, run DBCC CHECKDB as during the attach, SQL Server is
finding possible corruption in the DB.
Regards
Mike Epprecht, Microsoft SQL Server MVP
Zurich, Switzerland
IM: mike@.epprecht.net
MVP Program: http://www.microsoft.com/mvp
Blog: http://www.msmvps.com/epprecht/
"vvenk" <vvenk@.discussions.microsoft.com> wrote in message
news:8F0E56C4-F250-465A-A86E-D9DB92BFF9A7@.microsoft.com...
> Hello:
> When attaching a database that was detached from another SQL Server
> instance
> and copied over to this machine, I got the error message below:
> Error 602: Could not find row in sysindexes for database ID 7, object ID
> 1,
> index ID 1. Run DBCC CHECKTABLE on sysindexes.
> Can somebody guide me on the steps I have to follow to resolve this issue?
> Thanks.
> Venki
|||Mike:
The source DB Server has been retired and not available.
Is there any other option available to get the database back online?
Please say yes!
venki
"Mike Epprecht (SQL MVP)" wrote:
> Hi
> On the original server, run DBCC CHECKDB as during the attach, SQL Server is
> finding possible corruption in the DB.
> Regards
> --
> Mike Epprecht, Microsoft SQL Server MVP
> Zurich, Switzerland
> IM: mike@.epprecht.net
> MVP Program: http://www.microsoft.com/mvp
> Blog: http://www.msmvps.com/epprecht/
> "vvenk" <vvenk@.discussions.microsoft.com> wrote in message
> news:8F0E56C4-F250-465A-A86E-D9DB92BFF9A7@.microsoft.com...
>
>
|||
>
What are the results of DBCC CHECKTABLE sysindexes?
Regards
JTC ^..^
|||As I said, I don't have access to the source DB instance anymore. Since my
understanding was that DBCC should be run on the source DB instance, I have
not done it.
"JTC ^..^" wrote:
>
> What are the results of DBCC CHECKTABLE sysindexes?
> --
> Regards
> JTC ^..^
>
|||Hi,
Try the below steps. If it fails restore from a good database backup.
Steps:
1. Create a new database with the same name and same MDF and LDF files
2. Stop sql server and rename the existing MDF to a new one and copy the
original MDF to this location and delete the LDF files.
3. Start SQL Server
4. Now your database will be marked suspect
5. Update the sysdatabases to update to Emergency mode. This will not use
LOG files in start up
Sp_configure "allow updates", 1
go
Reconfigure with override
GO
Update sysdatabases set status = 32768 where name = "BadDbName"
go
Sp_configure "allow updates", 0
go
Reconfigure with override
GO
6. Restart sql server. now the database will be in emergency mode
7. Create a new database and use DTS to copy the objects and data to new
database. You can use this new database.
Note:
If you have the backup file, it is always recommended to use the backup file
to restore the database. SO that data integrity will be maintained.
..
Thanks
Hari
SQL Server MVP
"vvenk" <vvenk@.discussions.microsoft.com> wrote in message
news:4EE00CBA-DB2F-4177-A5C2-B78DA315F97A@.microsoft.com...[vbcol=seagreen]
> As I said, I don't have access to the source DB instance anymore. Since my
> understanding was that DBCC should be run on the source DB instance, I
> have
> not done it.
> "JTC ^..^" wrote:
|||Hari:
Thank you. When following the steps, when I tried to execute the statement,
Update sysdatabases set status = 32768 where name = "BadDbName"
I got an error, "Invalid column nam". However, I found what the dbid was for
that particular row and updated the row with that column in the Where clause.
I will now try to see if the data is accessible.
"Hari Prasad" wrote:
> Hi,
> Try the below steps. If it fails restore from a good database backup.
>
> Steps:
> 1. Create a new database with the same name and same MDF and LDF files
> 2. Stop sql server and rename the existing MDF to a new one and copy the
> original MDF to this location and delete the LDF files.
> 3. Start SQL Server
> 4. Now your database will be marked suspect
> 5. Update the sysdatabases to update to Emergency mode. This will not use
> LOG files in start up
>
> Sp_configure "allow updates", 1
> go
> Reconfigure with override
> GO
> Update sysdatabases set status = 32768 where name = "BadDbName"
> go
> Sp_configure "allow updates", 0
> go
> Reconfigure with override
> GO
> 6. Restart sql server. now the database will be in emergency mode
>
> 7. Create a new database and use DTS to copy the objects and data to new
> database. You can use this new database.
>
> Note:
> If you have the backup file, it is always recommended to use the backup file
> to restore the database. SO that data integrity will be maintained.
> ..
>
> --
> Thanks
> Hari
> SQL Server MVP
>
>
> "vvenk" <vvenk@.discussions.microsoft.com> wrote in message
> news:4EE00CBA-DB2F-4177-A5C2-B78DA315F97A@.microsoft.com...
>
>
|||Hari:
Also, I executed the statements after I was logged into master database; I
could not log onto the badDBName.
I hope that was fine.
Venki
"Hari Prasad" wrote:
> Hi,
> Try the below steps. If it fails restore from a good database backup.
>
> Steps:
> 1. Create a new database with the same name and same MDF and LDF files
> 2. Stop sql server and rename the existing MDF to a new one and copy the
> original MDF to this location and delete the LDF files.
> 3. Start SQL Server
> 4. Now your database will be marked suspect
> 5. Update the sysdatabases to update to Emergency mode. This will not use
> LOG files in start up
>
> Sp_configure "allow updates", 1
> go
> Reconfigure with override
> GO
> Update sysdatabases set status = 32768 where name = "BadDbName"
> go
> Sp_configure "allow updates", 0
> go
> Reconfigure with override
> GO
> 6. Restart sql server. now the database will be in emergency mode
>
> 7. Create a new database and use DTS to copy the objects and data to new
> database. You can use this new database.
>
> Note:
> If you have the backup file, it is always recommended to use the backup file
> to restore the database. SO that data integrity will be maintained.
> ..
>
> --
> Thanks
> Hari
> SQL Server MVP
>
>
> "vvenk" <vvenk@.discussions.microsoft.com> wrote in message
> news:4EE00CBA-DB2F-4177-A5C2-B78DA315F97A@.microsoft.com...
>
>
|||Hari:
Yes, the database is in emergency mode.
When I tried to create a DTS job to import, it does not show up in the list
of databases available as a source.
Any ideas?
venki
"Hari Prasad" wrote:
> Hi,
> Try the below steps. If it fails restore from a good database backup.
>
> Steps:
> 1. Create a new database with the same name and same MDF and LDF files
> 2. Stop sql server and rename the existing MDF to a new one and copy the
> original MDF to this location and delete the LDF files.
> 3. Start SQL Server
> 4. Now your database will be marked suspect
> 5. Update the sysdatabases to update to Emergency mode. This will not use
> LOG files in start up
>
> Sp_configure "allow updates", 1
> go
> Reconfigure with override
> GO
> Update sysdatabases set status = 32768 where name = "BadDbName"
> go
> Sp_configure "allow updates", 0
> go
> Reconfigure with override
> GO
> 6. Restart sql server. now the database will be in emergency mode
>
> 7. Create a new database and use DTS to copy the objects and data to new
> database. You can use this new database.
>
> Note:
> If you have the backup file, it is always recommended to use the backup file
> to restore the database. SO that data integrity will be maintained.
> ..
>
> --
> Thanks
> Hari
> SQL Server MVP
>
>
> "vvenk" <vvenk@.discussions.microsoft.com> wrote in message
> news:4EE00CBA-DB2F-4177-A5C2-B78DA315F97A@.microsoft.com...
>
>
No comments:
Post a Comment