Do you have a consistency group setup for all the LUNs for those databases?  If not, you should probably do that - That might be why it doesn't work.  That will make sure the data is in a crash-consistent state.  Also, make sure you're replicating all LUNs with databases (tempdb and anything else as well) and logs on them (you might want to have 2 copies of the Logs, one in a consistency group and one that isn't in the consistency group that is updated as frequently as possible in case you need to roll forward).

If the DBA couldn't open a database in an "open state", then that would mean all server OS crashes would mean a restore.  Esentially you're doing the same thing with MirrorView/A.  You're bringing up a database in a crash-consistent state.  SQL is capable of recovering in a crash-consistent state.  That's why they have transaction logs.

If you want application consistent copies, you could write a script to periodically take a VSS snapshot of the LUNs (SQL 2005 may have the capability to do this automatically - Your DBA probably knows how to do this already.).  Once the snapshot is created, you update your remote replica manually, then release the VSS snapshot. The script would just be a naviseccli command that the DBA could embed in his script when he creates the VSS snapshot.

Thanks for the reply.

I have consistency group setup already.Could you please breifly explain me how to restart the SQL .i think my DBA is doing some thing wrong while restarting .