Microsoft iSCSI Initiator & SQL Server services

Hello all,
I have Microsoft iSCSI Initiator (SAN) installed on a SQL Server machine and has this drive acting as a local drive. All the database's data files are residing on this drive, attached with SAN.
It runs as a service "Microsoft iSCSI Initiator" on the SQL Server machine.

Now the question is, when we restart the SQL Server all the databases change their status to "Suspect" and we have to stop all the sqlserver services (all the SQL instances) and start them all up. This is the only temporary solution we came up with.
Could any one has any real solution or had encounter such a problem before?

Any help is appreciated.

Thanks bunch!
imransi.Looks like your SQL Service starts before your SAN is available.|||Originally posted by rdjabarov
Looks like your SQL Service starts before your SAN is available.

You are 100% right. So thats why we are restarting SQL services.
We can manually start sql services but thats not what we wnat and really thsi should not be the solutuion ;)|||See if you can "impose" a dependency on MSSQLSERVER service in regards to this SAN service.

meta data cleanup

Hi
I am running a couple of sql 2000 SP3a servers with merge and snapshot
replication. One server acting as publisher and distributor and the rest
subscribers. On one of the server I have got the error below and have tried
most of the suggestions by msdn. This server has not crashed ever before or
any hardware problems. It has been running for a couple of months and no
problems. This has not happened no any of the other servers. Any
suggestions would be greatly appreciated as the only resolution I have left
is to bring up a new instance, setup replication and see if this would
resolve the issue. Thanx
Server: EASTSRV3
DBMS: Microsoft SQL Server
Version: 08.00.0760
user name: dbo
API conformance: 2
SQL conformance: 1
transaction capable: 2
read only: N
identifier quote char: "
non_nullable_columns: 1
owner usage: 31
max table name len: 128
max column name len: 128
need long data len: Y
max columns in table: 1024
max columns in index: 16
max char literal len: 524288
max statement len: 524288
max row size: 524288
[4/14/2005 12:57:26 PM]EASTSRV3.ICASData: {call sp_MSgetversion }
Percent Complete: 2
Connecting to Subscriber 'EASTSRV3'
Percent Complete: 3
Retrieving publication information
Percent Complete: 4
Retrieving subscription information
Percent Complete: 4
The merge process is cleaning up meta data in database 'HO_Master'.
Percent Complete: 4
The merge process cleaned up 0 row(s) in MSmerge_genhistory, 0 row(s) in
MSmerge_contents, and 0 row(s) in MSmerge_tombstone.
Percent Complete: 4
The merge process is cleaning up meta data in database 'ICASData'.
The merge process could not perform retention-based meta data cleanup in
database 'ICASData'.
Percent Complete: 0
The merge process could not perform retention-based meta data cleanup in
database 'ICASData'.
Percent Complete: 0
Category:NULL
Source: Merge Replication Provider
Number: -2147199467
Message: The merge process could not perform retention-based meta data
cleanup in database 'ICASData'.
Percent Complete: 0
Category:COMMAND
Source: Failed Command
Number: 0
Message: {call sp_mergemetadataretentioncleanup(?, ?, ?)}
Percent Complete: 0
Category:SQLSERVER
Source: EASTSRV3
Number: 11
Message: General network error. Check your network documentation.
Message posted via http://www.sqlmonster.com
Jayanthi from MS posted this before:
"The most common reason I can think of is that the query timed out. Sometime
retention based cleaup may need to cleanup a lot of rows and that can take
time. Rerunning the merge with a larger value for the querytimeout parameter
should fix this problem."
Rgds,
Paul Ibison SQL Server MVP, www.replicationanswers.com/default.asp
(recommended sql server 2000 replication book:
http://www.nwsu.com/0974973602p.html)
|||Hi Paul
Thanx for the reply.
I have played with the agent profiles aswell. From default to 1800. This
has been going on for like two days now no synch at all. I have tried to
reindex also as this was also one of the msdn suggestions.
Message posted via http://www.sqlmonster.com