restore the replication system

Database A and B are replicated to each other. Both db reside on the same box.
The box has been rebuild due to a system crash. All data base files have
been preserved.
NT SA restored all user databases by attaching the datafiles except
master and msdb. Now, the replication system is out of sync.
Can I restore the master and msdb using attach db to restore the
entire replication system?
Any other better or correct way to restore the entire system when there is a
system crash?
Appreciate any help.
Wen
Wen,
provided you also restore the distribution database this may be possible. It
partly depends on 2 factors:
firstly, is the server name the same as the original one? If not then the
recovery strategy won't work and you'll need to start again - recreate the
publications and initialize.
If the servername is identical, then it may be possible - have a look in BOL
for "replication, backup and restore operations".
The second question is what type of replication are you using? In most cases
it is ok but I'd mention that if the distribution database's backup has been
allowed to get ahead of the publisher's backup and you are using
transactional replication there are likely to be problems.
Anyway, the first port of call is the BOL reference above, and please post
back if you have any issues which arise from that.
Regards,
Paul Ibison
|||Paul.
1. Yes, the servername is the same as the original one. and the
Distribution db
has been restored.
2. We have transactional and merge replication.
I will attache back the master and msdb and see if it works.
Thanks for the help.
Wen
"Paul Ibison" wrote:

> Wen,
> provided you also restore the distribution database this may be possible. It
> partly depends on 2 factors:
> firstly, is the server name the same as the original one? If not then the
> recovery strategy won't work and you'll need to start again - recreate the
> publications and initialize.
> If the servername is identical, then it may be possible - have a look in BOL
> for "replication, backup and restore operations".
> The second question is what type of replication are you using? In most cases
> it is ok but I'd mention that if the distribution database's backup has been
> allowed to get ahead of the publisher's backup and you are using
> transactional replication there are likely to be problems.
> Anyway, the first port of call is the BOL reference above, and please post
> back if you have any issues which arise from that.
> Regards,
> Paul Ibison
>
>
|||Wen,
there should be no problem with the merge database restoration, and you
might want to synchronize with the most upto date subscriber after the
restore.
As for the transactional, there could be issues. Did the publisher have the
sync with backup option set to true? If not, the distribution backup could
be ahead of the publisher restore. After the restore you will get an error
from the Log Reader Agent because it will detect that the Distributor is
ahead of the Publisher. The recommendation is to run sp_replrestart in the
publication database with no parameters. and ensure that that the
distribution agent, which could now deliver duplicate rows to Subscribers,
can continue despite these failures. Choose the -SkipError Distribution
Agent profile, or you can manually add the -SkipError parameter to the
runtime parameters of the Distribution Agents and supply the errors you want
the Distribution Agents to ignore.
You'll need to use linked servers to fix the inconsistencies, or you could
of course resort to reinitializing.
HTH,
Paul Ibison
|||Paul, the sync with backup option is fairly useless unless you are shipping
the transaction logs to a standby server.
The sequence to get this to work is
1) use the sync with backup option on your publication database and possibly
your distribution database
2) restore the msdb, publication database, and distribution database backups
on the standby server with the keep_replication switch.
3) then ship the publication and distribution databases tlogs and without
the keep_replication switch.
4) when the publisher goes offline you rename the standby server with the
name of the original publisher, and then do a sp_replrestart,
and -skiperrors switch.
In the case of this user you can't really use any of these options as they
have not been shipping the database. With a new master database, the user
probably does not have any of the subscribers listed as remote servers and
restoring or attaching any databases will be highly problematic.
The user is best to drop all replication and create publications and
subscriptions from scratch as their data is likely out of sync.
Hilary Cotter
Looking for a book on SQL Server replication?
http://www.nwsu.com/0974973602.html
"Paul Ibison" <Paul.Ibison@.Pygmalion.Com> wrote in message
news:uY4Vt9RfEHA.3916@.TK2MSFTNGP11.phx.gbl...
> Wen,
> there should be no problem with the merge database restoration, and you
> might want to synchronize with the most upto date subscriber after the
> restore.
> As for the transactional, there could be issues. Did the publisher have
the
> sync with backup option set to true? If not, the distribution backup could
> be ahead of the publisher restore. After the restore you will get an error
> from the Log Reader Agent because it will detect that the Distributor is
> ahead of the Publisher. The recommendation is to run sp_replrestart in the
> publication database with no parameters. and ensure that that the
> distribution agent, which could now deliver duplicate rows to Subscribers,
> can continue despite these failures. Choose the -SkipError Distribution
> Agent profile, or you can manually add the -SkipError parameter to the
> runtime parameters of the Distribution Agents and supply the errors you
want
> the Distribution Agents to ignore.
> You'll need to use linked servers to fix the inconsistencies, or you could
> of course resort to reinitializing.
> HTH,
> Paul Ibison
>
|||Hilary,
from a practical point of view I accept your point - log-shipping, the 'sync
with backup' option and keep_replication go well together to minimize the
latency involved if you ship every few minutes.
However in BOL
(mk:@.MSITStore:C:\Program%20Files\Microsoft%20SQL% 20Server\80\Tools\Books\re
plsql.chm::/replbackup_3js7.htm) the recommendation is different to your
implementation:
- they advise 'keep_replication' for the last log.
- and sp_replrestart for semi-synchronous mode only - ie when the 'sync with
backup' option is false.
Are these just alternative methods?
Regards,
Paul Ibison
|||BOL lies.
Try to restore a tlog with the keep_replication switch.
I have reported this doc bug to Microsoft.
Hilary Cotter
Looking for a book on SQL Server replication?
http://www.nwsu.com/0974973602.html
"Paul Ibison" <Paul.Ibison@.Pygmalion.Com> wrote in message
news:%23PFoxqifEHA.3520@.TK2MSFTNGP10.phx.gbl...
> Hilary,
> from a practical point of view I accept your point - log-shipping, the
'sync
> with backup' option and keep_replication go well together to minimize the
> latency involved if you ship every few minutes.
> However in BOL
>
(mk:@.MSITStore:C:\Program%20Files\Microsoft%20SQL% 20Server\80\Tools\Books\re
> plsql.chm::/replbackup_3js7.htm) the recommendation is different to your
> implementation:
> - they advise 'keep_replication' for the last log.
> - and sp_replrestart for semi-synchronous mode only - ie when the 'sync
with
> backup' option is false.
> Are these just alternative methods?
> Regards,
> Paul Ibison
>
|||Hilary,
thanks for pointing this out, and for posting up a bonafide working
sequence.
As far as I remember, when I tested this I followed a different methodology
where I used "WITH KEEP_REPLICATION, RECOVERY" on the last transaction log
and this seemed to work. Unfortunately I didn't make a proper note of it and
I really need 3 boxes to repeat the test. Later this week it might be
possible to set it up and I'll post back then.
Regards,
Paul Ibison

Restore mdf after system crash in sqls2k

During a system crash I was able to manually copy my .mdf but not the log.
After restoring the system sql runs an older version of the file, which i
want to replace with the copied mdf. Sql manager denies attaching the file
because it doesn't mach the log-file.
Is there a way of resetting the database or any other way for me to restore
the .mdf without dataloss?
Try sp_attach_single_file_db (complete syntax in Books Online).
However, it is not _guaranteed_ to work. It is only guaranteed to work if
you explicitly detach the database via EM or sp_detach_db. You might be
lucky though.
Jacco Schalkwijk
SQL Server MVP
"peteroff" <peteroff@.discussions.microsoft.com> wrote in message
news:D9111F32-7436-488A-A4E6-7EB62CC00DA8@.microsoft.com...
> During a system crash I was able to manually copy my .mdf but not the log.
> After restoring the system sql runs an older version of the file, which i
> want to replace with the copied mdf. Sql manager denies attaching the file
> because it doesn't mach the log-file.
> Is there a way of resetting the database or any other way for me to
> restore
> the .mdf without dataloss?
|||Hi,
Best option will be restore using good full database backup and apply your
transaction log backup. This
will provide you the data integrity. Attaching MDF file only might cause you
a data integrity problem
since you have not detached the database.
Thanks
Hari
MCDBA
"Jacco Schalkwijk" wrote:

> Try sp_attach_single_file_db (complete syntax in Books Online).
> However, it is not _guaranteed_ to work. It is only guaranteed to work if
> you explicitly detach the database via EM or sp_detach_db. You might be
> lucky though.
> --
> Jacco Schalkwijk
> SQL Server MVP
>
> "peteroff" <peteroff@.discussions.microsoft.com> wrote in message
> news:D9111F32-7436-488A-A4E6-7EB62CC00DA8@.microsoft.com...
>
>
|||thanks for the posts. I tried sp_attach_single_file_db. The server denied and
gave 9003 mistake. The problem is, that I do not have a valid transaction log
file. I only was able to copy the *.mdf
I restored a good version, I tried building up a whole new set of files, but
none of these would allow me to sneak in with my old *.mdf.
Seems like the security system between *.mdf and *.ldf is too perfect.
Or does anybody know a reliable trick to put an *.mdf and an "empty" *.ldf
together?
"peteroff" wrote:

> During a system crash I was able to manually copy my .mdf but not the log.
> After restoring the system sql runs an older version of the file, which i
> want to replace with the copied mdf. Sql manager denies attaching the file
> because it doesn't mach the log-file.
> Is there a way of resetting the database or any other way for me to restore
> the .mdf without dataloss?
|||"peteroff" <peteroff@.discussions.microsoft.com> wrote in message
news:39D11384-A905-49C9-8C93-F128ADC192E0@.microsoft.com...
> thanks for the posts. I tried sp_attach_single_file_db. The server denied
and
> gave 9003 mistake. The problem is, that I do not have a valid transaction
log
> file. I only was able to copy the *.mdf
> I restored a good version, I tried building up a whole new set of files,
but
> none of these would allow me to sneak in with my old *.mdf.
> Seems like the security system between *.mdf and *.ldf is too perfect.
> Or does anybody know a reliable trick to put an *.mdf and an "empty" *.ldf
> together?
Microsoft can provide a method, but you will need to open a ticket with them
and they'll basically warn you that corruption is very likely.

Restore mdf after system crash in sqls2k

During a system crash I was able to manually copy my .mdf but not the log.
After restoring the system sql runs an older version of the file, which i
want to replace with the copied mdf. Sql manager denies attaching the file
because it doesn't mach the log-file.
Is there a way of resetting the database or any other way for me to restore
the .mdf without dataloss?Try sp_attach_single_file_db (complete syntax in Books Online).
However, it is not _guaranteed_ to work. It is only guaranteed to work if
you explicitly detach the database via EM or sp_detach_db. You might be
lucky though.
--
Jacco Schalkwijk
SQL Server MVP
"peteroff" <peteroff@.discussions.microsoft.com> wrote in message
news:D9111F32-7436-488A-A4E6-7EB62CC00DA8@.microsoft.com...
> During a system crash I was able to manually copy my .mdf but not the log.
> After restoring the system sql runs an older version of the file, which i
> want to replace with the copied mdf. Sql manager denies attaching the file
> because it doesn't mach the log-file.
> Is there a way of resetting the database or any other way for me to
> restore
> the .mdf without dataloss?|||Hi,
Best option will be restore using good full database backup and apply your
transaction log backup. This
will provide you the data integrity. Attaching MDF file only might cause you
a data integrity problem
since you have not detached the database.
Thanks
Hari
MCDBA
"Jacco Schalkwijk" wrote:
> Try sp_attach_single_file_db (complete syntax in Books Online).
> However, it is not _guaranteed_ to work. It is only guaranteed to work if
> you explicitly detach the database via EM or sp_detach_db. You might be
> lucky though.
> --
> Jacco Schalkwijk
> SQL Server MVP
>
> "peteroff" <peteroff@.discussions.microsoft.com> wrote in message
> news:D9111F32-7436-488A-A4E6-7EB62CC00DA8@.microsoft.com...
> > During a system crash I was able to manually copy my .mdf but not the log.
> > After restoring the system sql runs an older version of the file, which i
> > want to replace with the copied mdf. Sql manager denies attaching the file
> > because it doesn't mach the log-file.
> > Is there a way of resetting the database or any other way for me to
> > restore
> > the .mdf without dataloss?
>
>|||thanks for the posts. I tried sp_attach_single_file_db. The server denied and
gave 9003 mistake. The problem is, that I do not have a valid transaction log
file. I only was able to copy the *.mdf
I restored a good version, I tried building up a whole new set of files, but
none of these would allow me to sneak in with my old *.mdf.
Seems like the security system between *.mdf and *.ldf is too perfect.
Or does anybody know a reliable trick to put an *.mdf and an "empty" *.ldf
together?
"peteroff" wrote:
> During a system crash I was able to manually copy my .mdf but not the log.
> After restoring the system sql runs an older version of the file, which i
> want to replace with the copied mdf. Sql manager denies attaching the file
> because it doesn't mach the log-file.
> Is there a way of resetting the database or any other way for me to restore
> the .mdf without dataloss?|||"peteroff" <peteroff@.discussions.microsoft.com> wrote in message
news:39D11384-A905-49C9-8C93-F128ADC192E0@.microsoft.com...
> thanks for the posts. I tried sp_attach_single_file_db. The server denied
and
> gave 9003 mistake. The problem is, that I do not have a valid transaction
log
> file. I only was able to copy the *.mdf
> I restored a good version, I tried building up a whole new set of files,
but
> none of these would allow me to sneak in with my old *.mdf.
> Seems like the security system between *.mdf and *.ldf is too perfect.
> Or does anybody know a reliable trick to put an *.mdf and an "empty" *.ldf
> together?
Microsoft can provide a method, but you will need to open a ticket with them
and they'll basically warn you that corruption is very likely.