Disk Subsystem Problem during snapshot

We have set up a new SQL environment that has to replace our current SQL
environment. On our current environment we apply a snapshot every night from
our production database (the production database is hosted on another
environment). This means every night approximately 15GB is being copied to
the subscriber. It takes a long time to do this (3+ hours), but is not a
problem in our environment.
Exactly the same snapshot has to be applied on our new SQL environment. In
this environment we are having serious problems with our Disk Subsystem when
applying the snapshot. In the new environment we use a shared HP MSA1000 Disk
System. When applying the snapshot, the load is so high on the MSA1000 that
it can’t handle all the requests no more. This results in a crash of SQL
server (SQL can’t find the tempdb anymore) and other systems that use the
MSA1000 (two more servers, so three in total) are having problems with the
disks also (event id 51).
We’ve contacted HP and Microsoft and the conclusion will probably be that
the load generated by applying the snapshot is to high for the MSA1000.
Microsoft’s explanation about how this can be, knowing that the exact same
process runs on an old environment, is very reasonable (although it’s still
hard to believe that old hardware operates better under high load than new
advanced hardware).
I’d like to know what the opinion from you all is about applying a snapshot
every night to a subscriber, which involves copying approximately 15GB of
data. Should it be no problem to this, or is it very uncommon to do this
because of hardware limitations? Is it normal that the MSA1000 has problems
of this kind with this, or should it be able to handle the load (should it
result in disks that cannot be contacted anymore or should it just perform
very slow)?
Your opinion is very much appreciated!
Kind regards,
Jan Martijn Schuur
"Martijn" schrieb:
...
> I’d like to know what the opinion from you all is about applying a snapshot
> every night to a subscriber, which involves copying approximately 15GB of
> data. Should it be no problem to this, or is it very uncommon to do this
> because of hardware limitations?
15 GB is a large amount of data for a nightly snapshot. Why don't you use
the incremental transactional replication?
Your other problems with this are not familiar to me. Sorry.

Disappearing conflicts and snapshot

Hi ng,
we have serious problem,
we administrating one merge replication between Sql 2000 Serwers,
we had about 1000 conflicts in ConflictViewer,
we wanted to resolve this conflicts in monday, but during the weekend new
snapshot was generated and our all conflicts disappeared.
now we have no data from subscriber refered to this conflicts and we don't
know what to do?
we tried to update all records at the subscriber, but this didn't help, all
records was replicated except this 1000 conflicted,
thanks for any help
pozdrawiam
Kuba Guszkiewicz
k.gluszkiewicz@.citysoftware.com.pl
tel. 509-650-351
(22) 869-51-76
(22) 869-51-77
fax (22) 869-51-78
restore the publisher backup (from a day before the snapshot was generated)
on a separate server. You will find them there.
Hilary Cotter
Looking for a SQL Server replication book?
http://www.nwsu.com/0974973602.html
Looking for a FAQ on Indexing Services/SQL FTS
http://www.indexserverfaq.com
"Kuba Guszkiewicz" <k.gluszkiewicz@.citysoftware.com.pl> wrote in message
news:%23YhmBdtsFHA.2592@.TK2MSFTNGP09.phx.gbl...
> Hi ng,
> we have serious problem,
> we administrating one merge replication between Sql 2000 Serwers,
> we had about 1000 conflicts in ConflictViewer,
> we wanted to resolve this conflicts in monday, but during the weekend new
> snapshot was generated and our all conflicts disappeared.
> now we have no data from subscriber refered to this conflicts and we don't
> know what to do?
> we tried to update all records at the subscriber, but this didn't help,
all
> records was replicated except this 1000 conflicted,
> thanks for any help
> --
> pozdrawiam
> Kuba Guszkiewicz
> k.gluszkiewicz@.citysoftware.com.pl
> tel. 509-650-351
> (22) 869-51-76
> (22) 869-51-77
> fax (22) 869-51-78
>
|||Hilary,
many thanks for your advice,
indeed, we have that backup, but i'm not sure how to restore this on another
database,
could you tell me some more details?
tia
kg
|||Hilary Cotter
Looking for a SQL Server replication book?
http://www.nwsu.com/0974973602.html
Looking for a FAQ on Indexing Services/SQL FTS
http://www.indexserverfaq.com
"Kuba Guszkiewicz" <k.gluszkiewicz@.citysoftware.com.pl> wrote in message
news:%23K3J21usFHA.3424@.TK2MSFTNGP14.phx.gbl...
> Hilary,
> many thanks for your advice,
> indeed, we have that backup, but i'm not sure how to restore this on
another
> database,
> could you tell me some more details?
> tia
> kg
>
|||Create a new database, and restore the backup into this database. Use the
keep_replication switch.
Hilary Cotter
Looking for a SQL Server replication book?
http://www.nwsu.com/0974973602.html
Looking for a FAQ on Indexing Services/SQL FTS
http://www.indexserverfaq.com
"Kuba Guszkiewicz" <k.gluszkiewicz@.citysoftware.com.pl> wrote in message
news:%23K3J21usFHA.3424@.TK2MSFTNGP14.phx.gbl...
> Hilary,
> many thanks for your advice,
> indeed, we have that backup, but i'm not sure how to restore this on
another
> database,
> could you tell me some more details?
> tia
> kg
>

Disabling Repl error (22538)

Posted - 02/01/2007 : 22:35:02

---

one week ago, for testing purpose, I set up trans repl, trans repl with updateable, snapshot repl using the same instance.

configuration is like this,

publisher and distributor are on the same server, 2 remote subscribers, one is 2000, the other is 2005.

It works OK, today I am trying to disable the replicaiton, clean up the machine. keep getting the errors:

an exception occurred while executing a T-SQL statement or batch
only replicaiton jobs,or job schedules can be added, modified,dropped or viewed through replicaiton SPs
could not update the distribution database subscription table, the subscription status could not be changed.
changed database context to 'master',(MSSQL SERVER error 22538)

Please help

publisher: 2005 Standard SP2 CTP

Try dropping the subscriptions before trying to disable publishing and distribution. If you still have issues cleaning up, try using sp_removedbreplication at the subscriber and publisher. You can get more information on sp_removedbreplication from http://msdn2.microsoft.com/en-us/library/ms188734.aspx

Hope this helps,

Tom

This posting is provided "AS IS" with no warranties, and confers no rights.

|||

Tom, thanks,

Could not be able to drop subscriptions, getting the same error.

Trying to use sp_removedbreplication, it works at subscribers side, while does not work at publisher side, getting the error:

Msg 22538, Level 16, State 1, Procedure sp_MSrepl_check_job_access, Line 155

Only replication jobs or job schedules can be added, modified, dropped or viewed through replication stored procedures.

Disable sp_MSadd_merge_history

Hi Guys,
I'm currently running a dynamic snapshot replication over a 56k modem. I
have built the snapshot and inserted the snapshot file to a USB key and
applying the snapshot from the USB Key. The problem I am encountering is
that, for every script file that is applied to the local database this sp
get fired to the Head Office server exec sp_MSadd_merge_history, is there
anyway I can disable this for an install as I can't take the server with us.
I dialup to the head office server so authentication can take place, but the
exec sp_MSadd_merge_history is slowing things down a lot.
Thanks Tim.
no, this proc is necessary for tracking information.
"Tim Ford" <tford@.in2focusnospam.com> wrote in message
news:u1mlBUdMEHA.3664@.TK2MSFTNGP10.phx.gbl...
> Hi Guys,
> I'm currently running a dynamic snapshot replication over a 56k modem. I
> have built the snapshot and inserted the snapshot file to a USB key and
> applying the snapshot from the USB Key. The problem I am encountering is
> that, for every script file that is applied to the local database this sp
> get fired to the Head Office server exec sp_MSadd_merge_history, is there
> anyway I can disable this for an install as I can't take the server with
us.
> I dialup to the head office server so authentication can take place, but
the
> exec sp_MSadd_merge_history is slowing things down a lot.
> Thanks Tim.
>