September 22, 2011 at 7:04 am
hi
i'm planning to do the DRP (disaster Recovery Plan), in order to avoid any surprise , i decided to restore my critical databases.i noticed that the latest critical database backup was not a backup file but mdf and ldf since the third party replication software which transfers files from the production server to the backup server copied only the mdf and ldf files.Now, i have to use those files to restore.
i've tried to attach those files, the attach activity went properly but the database is read only status. i run the<< alter database XXXX set read_write>> but it gave me this error << Device activation error. The physical file name... >>
i dont know what to do anymore .
help!!!
September 22, 2011 at 7:31 am
pls post the complete error msg (obscuring filenames if you want)
---------------------------------------------------------------------
September 23, 2011 at 6:42 am
here is the command
ALTER DATABASE r123
SET READ_WRITE
*****************************************
here is the full erro message :
Msg 5105, Niveau 16, État 4, Ligne 1
Device activation error. The physical file name 'G:\data_prod\rd_prod1.mdf' may be incorrect.
Msg 5105, Niveau 16, État 4, Ligne 1
Device activation error. The physical file name 'G:\index\rd_prod1_1.ndf' may be incorrect.
Msg 5105, Niveau 16, État 9, Ligne 1
Device activation error. The physical file name 'G:\index\rd_prod1_1.ndf' may be incorrect.
Msg 5105, Niveau 16, État 4, Ligne 1
Device activation error. The physical file name 'G:\logs\rd_prod1_log.ldf' may be incorrect.
Device activation error. The physical file name 'G:\logs\rd_prod1_log.ldf' may be incorrect.
Msg 5181, Niveau 16, État 5, Ligne 1
Could not restart database 'rdprm_prod12'. Reverting back to old status.
Msg 5069, Niveau 16, État 1, Ligne 1
ALTER DATABASE statement failed.
September 23, 2011 at 6:47 am
Are the physical location of the files correct ?
Can you ensure that sql server service account has privileges to access that files ?
Regards,
Paulo Condeça.
September 23, 2011 at 7:39 am
yes i can confirm that the paths are correct because i even browsed in sql to select the correct file. i was thinkinf of mdf file, those files have been copied while the server was running on production environnment.may be it can cause error while restoring i think.
I'm also connected with sa user, i even succeded to attach the database.
September 23, 2011 at 7:46 am
Can you show the script to attach the DB, please ?
September 23, 2011 at 7:49 am
Either the files G:\data_prod\rd_prod1.mdf, G:\index\rd_prod1_1.ndf' and G:\logs\rd_prod1_log.ldf don't exist or SQL doesn't have access to them (or, if this is a cluster, the G drive is not properly configured in the cluster)
Gail Shaw
Microsoft Certified Master: SQL Server, MVP, M.Sc (Comp Sci)
SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability
September 23, 2011 at 8:33 am
the path are correct and the mdf,ldf,ndf file are in read write mode .the second option, i'll may be tested it the the Win administrator account which is supposed to have acces to the file.
i'll let you know
September 23, 2011 at 8:35 am
soulesidibe2011 (9/23/2011)
the path are correct and the mdf,ldf,ndf file are in read write mode .the second option, i'll may be tested it the the Win administrator account which is supposed to have acces to the file.i'll let you know
Please show the attach script.
September 23, 2011 at 8:40 am
The error means that SQL cannot open the file. It doesn't mean anything else.
Double-check there's not a spelling mistake somewhere. Double check that SQL has access to the files (your account is completely and totally irrelevant). If it's a cluster, check the drive dependencies. Check that the folder is not compressed (ntfs compression), though that usually gives different errors. Check that the files are read-write.
Post the attach statement, post any messages in the SQL error log after the attach.
Gail Shaw
Microsoft Certified Master: SQL Server, MVP, M.Sc (Comp Sci)
SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability
September 23, 2011 at 11:41 am
i've tested it with the Admin right locally on the server, that database being attached succesfully is still on read only status, but i succeded to attached the rest of the databases on the same server without any issue and they are on read_write status.
it's only the biggest database (around 30GB) which is giving me errors shown above.althought all files have been transfer the same time with the same third party software.
i'm guessing now that it could not be the security issue on the file but the Space issue.does the set read_write commande require space to put any DB on read_write status since the remaining space is less than 30 GB ?
September 23, 2011 at 11:54 am
GilaMonster (9/23/2011)
Post the attach statement, post any messages in the SQL error log after the attach.
Gail Shaw
Microsoft Certified Master: SQL Server, MVP, M.Sc (Comp Sci)
SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability
September 23, 2011 at 12:29 pm
SQL Server doesn't need extra space. It needs the space of the files and if they exist there, then that's enough.
It's a security issue. It doesn't matter if you connect to the server as admin, and run SSMS there. Your account is completely irrelevant. It's the service account for SQL Server that matters.
September 23, 2011 at 12:58 pm
don't think this has been mentioned....
check the permissions that the SQL server service account has on the files themselves (right click file, properties, security)
---------------------------------------------------------------------
September 26, 2011 at 6:33 am
i,ve checked the Sql service account, it the same windows admin account which is running SQL. he got full access to everything on the server.
Viewing 15 posts - 1 through 15 (of 20 total)
You must be logged in to reply to this topic. Login to reply