Error 5172, xxx.mdf is not a valid database file header.

[ken_halvorsen2]

Hi All

I'm attempting to creat a new system by copying the datafiles from an existing system. I've used the same <sid> (the 2 systems are not in the same landscape), ECC 6.0 & SQL Server 2005 versions. I've copied the datafiles from the source system onto an external drive, attached the external drive to the target system and copied the files onto my new system

When I try to bring up the database, I receive the follwoing error:

Error: 5172, Severity 16, State: 15.

The header file '..... .mdf' is not a valid database file header. The PageAudit property is incorrect.

In trouble shooting, I shut down SQL, renamed the datafiles, created a New Database with the same name. Then shut down SQL again, changing the Original files back to the New Database name, but the system still would not come up.

I'm thinking that my original datafiles are corrupted and will have to get another backup or copy of the datafiles from the original source.

Does anyone one have any ideas on how I might be able to quickly restore the system from these files?

Ken

[Former Member · Accepted solution]

>

> I'm attempting to creat a new system by copying the datafiles from an existing system. I've used the same <sid> (the 2 systems are not in the same landscape), ECC 6.0 & SQL Server 2005 versions. I've copied the datafiles from the source system onto an external drive, attached the external drive to the target system and copied the files onto my new system

>

>

> Does anyone one have any ideas on how I might be able to quickly restore the system from these files?

>

Hi Ken,

Why don't you try to make a new system through backup/restore method? It is also fast.

Well what you are doing looks pretty tricky to me ..I will use backup/restore method to make a new system.

Regards,

Rohit

[ken_halvorsen2 · Accepted solution]

Hi Rohit

Yes, in normal situations that would be work. But in this case, (being some what abnormal) I'm trying to setup a copy of the Dev system from one location, in a totally different landscape as a Demo system in a different location. The 2 locations can not physically connect to each other.

Also the source server doesn't have enough free space for me to create a SQL Backup on and copy the back up file over to the Target server.

Thus only way I could think of was to copy the SQL data and log files to an external device and then copy them to the Target server. The same as doing a restore from datafiles. Unfortunately the primary file seems to have corrupted during the copy process.

Has anyone had any experience with the Stellar Pheonix MS SQL Data Recovery application?

I'm wondering if trying this product might be quicker than trying another copy.

Ken

[Former Member · Accepted solution]

>

The same as doing a restore from datafiles. Unfortunately the primary file seems to have corrupted during the copy process.

>

Well I am not sure but before copying the datafiles SAP was down and services were stopped or not?

>

>

> Has anyone had any experience with the Stellar Pheonix MS SQL Data Recovery application?

> I'm wondering if trying this product might be quicker than trying another copy.

>

I heard about stellar alot ....just give a shotif you do not have any other option

-Rohit

[ken_halvorsen2 · Accepted solution]

Thanks Rohit

Yes, SAP and SQL Services had to be shut down before doing the file copy.

Thanks anyway.

Ken

[Former Member · Accepted solution]

What is your database size ?? you can use EXPORT/IMPORT method as well ....because normally export size is very small like 10 GB approx in case of 80-100 Gb database ....anyways..best of luck

-Rohit

[ken_halvorsen2 · Accepted solution]

Source database size is small, less than 60 GB.

But the source system is Non-Unicode. The target system was installed as unicode and converted, so I need a Non-unicode database restored, to bring up the system, before I could do the Client export - import method.

Like I mentioned this is not our average situation I have here.

Thanks for the suggestions

[Former Member · Accepted solution]

Well see if this link helps

http://ekasiswanto.wordpress.com/2009/02/04/resolving-sql-error-5172/

-rohit

[gudmundur_karlsson · Accepted solution]

Hi Ken,

you are right, it's not the average situation :-).

Ok but it should work. Just remember:

1. copy the files of the source system while either SQL Server is shutdown or the database is detached. I assume you're only copying the files of one database (the <SID>), the .mdf, .ndf and .ldf files.

2. The SQL Server release and build number must be either exactly the same on the source and the target, or the target must be higher. You can't go from a newer to an older server. Check out SELECT @@version on both sides.

3. I guess you have an database attached to the target server which you don't want to use (a unicode one?). Either detach it or rename this one - or delete it completely if you don't care about it.

4. Attach the files you copied over to the target system using the sp_attach_db or the SQL Server Management Studio while SQL Server is running. Don't try to replace the files of an existing database while SQL Server is down and then bringing up SQL Server. I'm guessing this is where you went wrong.

5. This is not related to your current problem, but if you want to change the target system from unicode to non-unicode (using the database you copied over), you have to replace all the unicode SAP executables by non-unicode ones. This includes the service executables (sapstartsrv.exe etc.). So you need to shutdown the SAP system, and all the services and then install all completely new executables. I hope that works, otherwise you'll have to re-install the application server using the non-unicode kernel cds.

Hope this helps,

Gudmundur

[ken_halvorsen2 · Accepted solution]

Thanks Gudmundur

1. copy the files of the source system while either SQL Server is shutdown or the database is detached. I assume you're only copying the files of one database (the <SID>), the .mdf, .ndf and .ldf files.

Correct, the SAP & SQL Services have to be turned off before you can start copying the datafiles.

2. The SQL Server release and build number must be either exactly the same on the source and the target, or the target must be higher. You can't go from a newer to an older server. Check out SELECT @@version on both sides.

Correct, both systems are exactly the same versions and Patch level.

3. I guess you have an database attached to the target server which you don't want to use (a unicode one?). Either detach it or rename this one - or delete it completely if you don't care about it.

Correct - Deleted the original Uni-code database and files

4. Attach the files you copied over to the target system using the sp_attach_db or the SQL Server Management Studio while SQL Server is running. Don't try to replace the files of an existing database while SQL Server is down and then bringing up SQL Server. I'm guessing this is where you went wrong.

Yes, using the SQL Server Managment Studio, the SQL Services need to be turned back on. This is where I got the error message. When pointing to the xxx.mdf file to attach the database.

5. This is not related to your current problem, but if you want to change the target system from unicode to non-unicode (using the database you copied over), you have to replace all the unicode SAP executables by non-unicode ones. This includes the service executables (sapstartsrv.exe etc.). So you need to shutdown the SAP system, and all the services and then install all completely new executables. I hope that works, otherwise you'll have to re-install the application server using the non-unicode kernel cds.

Correct, which is one of the reasons I can't bring the SAP System up to do a Client export - import method to create my new sytems.

I'm re-copying the Target system data and log files another way this time. Hopefully it was the copying over the network process that corrupted the files and not the files them selves.

(Yes, the source system is up and running fine again, proving the original files are fine and not corrupted)

[gudmundur_karlsson · Accepted solution]

Ok Ken, sorry I misunderstood, you were doing it the way I suggested. So the files (the .mdf file) must have been corrupted somehow during the handling, maybe the detaching of your temporary device etc.

Possibly it could help to temporarily detaching the database on the source while you do the copy - instead of shutting down.

Maybe the second time will be the charm.

Good luck,

Gudmundur

[ken_halvorsen2 · Accepted solution]

Thanks Gudmundur

I think this second attempt may prove weither it's the datafiles on the Temporary device that are corrupt or the copying process.

I did not think that the files could have been corrupted while disconnecting from the Source system. Good suggestion.

Thanks again.

[Former Member]

This indicates that you probably could well have a corrupt database.  The full message should tell you which database and what property it is objecting to. for more information Know How to Resolve Microsoft SQL Server Error 5172

[Former Member]

This message was moderated.

[ken_halvorsen2]

I'm iin the process of getting another copy of the original (source) backup files. The one's being used on this External Hard drive must be corrupted.

Thanks for all suggestions everyone.

Ken