I've been playing with the SQL 2005 log shipping and have been running into a
few problems.
My system is configured on a virtual server with two instances of SQL 2005.
The OS is Windows 2003. I'm shipping logs from the default instance to the
named instance with the default having the primary database and the named,
the secondary.
When I use the log shipping wizard, and have it do the initial restore to
the secondary, all appears to work well but the database remains in
"(Restoring ...) in the Management Studio (MS) GUI. So after starting over
and manually restoring the database to the secondary, I used the wizard again
to set this up and now the Agent jobs indicate success in applying the logs
but again, the database continues to show as (Restoring ...) in the MS GUI.
It is indeed unavailable as you can't query it in a Query window. I tried
this with upgraded SQL 2000 databases and newly created SQL 2005 databases,
both with the same result.
Has anyone run into this and can you tell me what might be happening?
Hi
By default, you can not access the destination DB in a log shipping
partnership. It was the same in SQL Server 2000.
If you want to have read only access, subject to having your connections
dropped when the next log restore occurs,
you need to execute a restore with the additional parameter of "STANDBY =
{standby_file_name}".
This can not be done in the GUI.
What are you trying to achieve?
Regards
Mike Epprecht, Microsoft SQL Server MVP
Zurich, Switzerland
IM: mike@.epprecht.net
MVP Program: http://www.microsoft.com/mvp
Blog: http://www.msmvps.com/epprecht/
"Dlorbecki" <Dlorbecki@.discussions.microsoft.com> wrote in message
news:4262DE8E-343E-4C2C-B2D6-43A5D6A425A3@.microsoft.com...
> I've been playing with the SQL 2005 log shipping and have been running
> into a
> few problems.
> My system is configured on a virtual server with two instances of SQL
> 2005.
> The OS is Windows 2003. I'm shipping logs from the default instance to the
> named instance with the default having the primary database and the named,
> the secondary.
> When I use the log shipping wizard, and have it do the initial restore to
> the secondary, all appears to work well but the database remains in
> "(Restoring ...) in the Management Studio (MS) GUI. So after starting over
> and manually restoring the database to the secondary, I used the wizard
> again
> to set this up and now the Agent jobs indicate success in applying the
> logs
> but again, the database continues to show as (Restoring ...) in the MS
> GUI.
> It is indeed unavailable as you can't query it in a Query window. I tried
> this with upgraded SQL 2000 databases and newly created SQL 2005
> databases,
> both with the same result.
> Has anyone run into this and can you tell me what might be happening?
|||My goal was to have a readable database on the destination side that could be
accessible in case of failure of the primary database. I guess I'm ignorant
of a basic tenent of log shipping and for that I apologize. Apparently, the
process is working as it should be and I thank you for pointing that out. (I
never used log shipping in 2000 since we only have standard edition). I will
"read up" on the subject a bit more. Thanks much!
"Mike Epprecht (SQL MVP)" wrote:
> Hi
> By default, you can not access the destination DB in a log shipping
> partnership. It was the same in SQL Server 2000.
> If you want to have read only access, subject to having your connections
> dropped when the next log restore occurs,
> you need to execute a restore with the additional parameter of "STANDBY =
> {standby_file_name}".
> This can not be done in the GUI.
> What are you trying to achieve?
> Regards
> --
> Mike Epprecht, Microsoft SQL Server MVP
> Zurich, Switzerland
> IM: mike@.epprecht.net
> MVP Program: http://www.microsoft.com/mvp
> Blog: http://www.msmvps.com/epprecht/
> "Dlorbecki" <Dlorbecki@.discussions.microsoft.com> wrote in message
> news:4262DE8E-343E-4C2C-B2D6-43A5D6A425A3@.microsoft.com...
>
>
Showing posts with label ive. Show all posts
Showing posts with label ive. Show all posts
Wednesday, March 28, 2012
Monday, March 26, 2012
Log Shipping Restore Error 3456
Hi,
I've got a production server log shipping a 280GB database to a remote DR
site server. It has been running without incident for months now, but last
week it stopped restoring logs (the copy process was still running) with an
error 3456:
[Microsoft SQL-DMO (ODBC SQLState: HY000)] Error 3456: [Microsoft][ODBC SQL
Server Driver][SQL Server]Could not redo log record (500478:68225:4), for
transaction ID (3:1085081790), on page (3:2789016), database 'JDE_Prod' (5).
Page: LSN = (500478:57038:10), type = 2. Log: OpCode = 2, context 3,
PrevPageLSN: (500478:68221:4).
I restored the remote database from a full tape backup shipped to the site
via courier (because we weren't sure if the link was to blame for the problem
restoring). Log shipping worked well again for a few days, but this morning
has again stopped restoring with the exact same error!
I've read the article "http://support.microsoft.com/kb/831950", and although
it describes the same error, it doesnt seem to apply to us as we weren't
doing any role changing, and weren't backing up the database manually with
the NORECOVERY switch (i.e. the backups were being done as usual by the log
shipping maint. plan).
Local server build is 8.00.997, and remote (DR) server build is 8.00.818.
Could the fact that they are slightly different versions have anything to do
with this problem?
Could this be corruption introducted by the network link? If so, is the
only way to fix this to fully restore the database again? Or is there some
way to get good copies of the log it failed on and restore those manually? I
don't have a huge amount of experience with log shipping, so any help would
be greatly appreciated - especially being a 24/7 mission critical DR server,
and in the middle of the holidays! Murphy's Law!
Thanks,
david
Hi David
The SQL Builds may cause a problem. I am not sure about it.
Rearding the file restore; it isn't necessary that you restore the entire
db. I would suggest the following steps:
1) Check the table msdb..log_shipping_plan_history for the last loaded file.
try
select * from msdb..log_shipping_plan_history order by endtime desc
2) Try restoring tha tfile manually from the Query Analyzer. try
restore log
<db_name>
from
disk = 'file_path'
with
standby = 'undo.txt'
3) if the above step succeeds keep restoring the successive trn files till
the step fails. Then that file at which the step fails is the corrupt file.
4) Copy only that file from the primary server and try step 2 with it.
5) re-run the LS Jobs and the ywill succeed.
Hope this helps.
I shall get back with mpre information about the affect of SQL builds on LS.
Thanks
Amer M J
MCP
"DavidCur" wrote:
> Hi,
> I've got a production server log shipping a 280GB database to a remote DR
> site server. It has been running without incident for months now, but last
> week it stopped restoring logs (the copy process was still running) with an
> error 3456:
> [Microsoft SQL-DMO (ODBC SQLState: HY000)] Error 3456: [Microsoft][ODBC SQL
> Server Driver][SQL Server]Could not redo log record (500478:68225:4), for
> transaction ID (3:1085081790), on page (3:2789016), database 'JDE_Prod' (5).
> Page: LSN = (500478:57038:10), type = 2. Log: OpCode = 2, context 3,
> PrevPageLSN: (500478:68221:4).
> I restored the remote database from a full tape backup shipped to the site
> via courier (because we weren't sure if the link was to blame for the problem
> restoring). Log shipping worked well again for a few days, but this morning
> has again stopped restoring with the exact same error!
> I've read the article "http://support.microsoft.com/kb/831950", and although
> it describes the same error, it doesnt seem to apply to us as we weren't
> doing any role changing, and weren't backing up the database manually with
> the NORECOVERY switch (i.e. the backups were being done as usual by the log
> shipping maint. plan).
> Local server build is 8.00.997, and remote (DR) server build is 8.00.818.
> Could the fact that they are slightly different versions have anything to do
> with this problem?
> Could this be corruption introducted by the network link? If so, is the
> only way to fix this to fully restore the database again? Or is there some
> way to get good copies of the log it failed on and restore those manually? I
> don't have a huge amount of experience with log shipping, so any help would
> be greatly appreciated - especially being a 24/7 mission critical DR server,
> and in the middle of the holidays! Murphy's Law!
>
> Thanks,
> david
|||Thanks for the quick response. The log files are copied and restored every
15 minutes. The problem occurred this morning around 12:15am. I've tried
your suggestion about restoring manually with the standby undo file.
I ran the following command (using the 12:00am file) successfully, but the
12:15am file produces the following output:
restore log JDE_Prod
from disk = 'K:\Backups\DRLogsIn\JDE_Prod_tlog_200512300015.TR N'
with standby = 'K:\Backups\DRLogsIn\LogUndo.tuf'
Deleting database file 'K:\Backups\DRLogsIn\LogUndo.tuf'.
Processed 34415 pages for database 'JDE_Prod', file 'JDE_PRODUCTION_log' on
file 1.
Server: Msg 3456, Level 21, State 1, Line 1
Could not redo log record (500478:68225:4), for transaction ID
(3:1085081790), on page (3:2789016), database 'JDE_Prod' (5). Page: LSN =
(500478:57038:10), type = 2. Log: OpCode = 2, context 3, PrevPageLSN:
(500478:68221:4).
Connection Broken
This 12:15 file has already been re-copied, but I will try again.
Would be interesting to see if you find any issues with different builds in
log shipping. The patches were applied to the local server a few months ago
(3 or 4 months), and log shipping has been running without incident this
whole time.
Thanks again,
Dave
"Amer M J" wrote:
> Hi David
> The SQL Builds may cause a problem. I am not sure about it.
> Rearding the file restore; it isn't necessary that you restore the entire
> db. I would suggest the following steps:
> 1) Check the table msdb..log_shipping_plan_history for the last loaded file.
> try
> select * from msdb..log_shipping_plan_history order by endtime desc
> 2) Try restoring tha tfile manually from the Query Analyzer. try
> restore log
> <db_name>
> from
> disk = 'file_path'
> with
> standby = 'undo.txt'
> 3) if the above step succeeds keep restoring the successive trn files till
> the step fails. Then that file at which the step fails is the corrupt file.
> 4) Copy only that file from the primary server and try step 2 with it.
> 5) re-run the LS Jobs and the ywill succeed.
> Hope this helps.
> I shall get back with mpre information about the affect of SQL builds on LS.
> Thanks
> Amer M J
> MCP
|||Hi Dave
I am curious here. Was the '.tuf' file deleted as per a part of the process
of manually ?
Also the builds do play a major role here. From what I can see as per your
information, the primary server is of a higher build than the secondary
server. So I was wondering how a log file of a db from a higher build was
getting restored onto a lower build server.
Also I would suggest checking out the integrity of the trn files on the
primary server. try
restore verifyonly command to check the backup set's integrity.
Please do check if anyother process is accessing the db on the secondary
server as this may disrupt the LS process.
Also check this link.
http://support.microsoft.com/kb/329487/en-us
Thanks
Amer M J
MCP
"DavidCur" wrote:
[vbcol=seagreen]
> Thanks for the quick response. The log files are copied and restored every
> 15 minutes. The problem occurred this morning around 12:15am. I've tried
> your suggestion about restoring manually with the standby undo file.
> I ran the following command (using the 12:00am file) successfully, but the
> 12:15am file produces the following output:
> restore log JDE_Prod
> from disk = 'K:\Backups\DRLogsIn\JDE_Prod_tlog_200512300015.TR N'
> with standby = 'K:\Backups\DRLogsIn\LogUndo.tuf'
> Deleting database file 'K:\Backups\DRLogsIn\LogUndo.tuf'.
> Processed 34415 pages for database 'JDE_Prod', file 'JDE_PRODUCTION_log' on
> file 1.
> Server: Msg 3456, Level 21, State 1, Line 1
> Could not redo log record (500478:68225:4), for transaction ID
> (3:1085081790), on page (3:2789016), database 'JDE_Prod' (5). Page: LSN =
> (500478:57038:10), type = 2. Log: OpCode = 2, context 3, PrevPageLSN:
> (500478:68221:4).
> Connection Broken
> This 12:15 file has already been re-copied, but I will try again.
> Would be interesting to see if you find any issues with different builds in
> log shipping. The patches were applied to the local server a few months ago
> (3 or 4 months), and log shipping has been running without incident this
> whole time.
> Thanks again,
> Dave
>
> "Amer M J" wrote:
|||Hi again,
Yes, the standby file (whatever it has been called) is automatically deleted
by the restore process.
Good news though, I seem to have log shipping going again! :-)
I re-copied the 12:15am log file (yet again, 3rd time) and restored it with
the same syntax as in my previous post, and it worked. So the problem must
lie with our link to the remote DR server. Its now been logged to the
telecom company who provide the WAN pipe.
As a precautionary measure I will schedule the remote server to be patched
to the same build level as our local server (will be next year though as we
are in a "holiday change freeze" now).
Funnily enough, the restore headeronly, verifyonly and filelistonly all
seemed to work fine with the corrupt file. Is it possible that the header of
the file was okay, while the actual data was bad?
Thanks very much for the help though, and I will update with anything new we
find.
Dave
"Amer M J" wrote:
> Hi Dave
> I am curious here. Was the '.tuf' file deleted as per a part of the process
> of manually ?
> Also the builds do play a major role here. From what I can see as per your
> information, the primary server is of a higher build than the secondary
> server. So I was wondering how a log file of a db from a higher build was
> getting restored onto a lower build server.
> Also I would suggest checking out the integrity of the trn files on the
> primary server. try
> restore verifyonly command to check the backup set's integrity.
> Please do check if anyother process is accessing the db on the secondary
> server as this may disrupt the LS process.
> Also check this link.
> http://support.microsoft.com/kb/329487/en-us
> Thanks
> Amer M J
> MCP
sql
I've got a production server log shipping a 280GB database to a remote DR
site server. It has been running without incident for months now, but last
week it stopped restoring logs (the copy process was still running) with an
error 3456:
[Microsoft SQL-DMO (ODBC SQLState: HY000)] Error 3456: [Microsoft][ODBC SQL
Server Driver][SQL Server]Could not redo log record (500478:68225:4), for
transaction ID (3:1085081790), on page (3:2789016), database 'JDE_Prod' (5).
Page: LSN = (500478:57038:10), type = 2. Log: OpCode = 2, context 3,
PrevPageLSN: (500478:68221:4).
I restored the remote database from a full tape backup shipped to the site
via courier (because we weren't sure if the link was to blame for the problem
restoring). Log shipping worked well again for a few days, but this morning
has again stopped restoring with the exact same error!
I've read the article "http://support.microsoft.com/kb/831950", and although
it describes the same error, it doesnt seem to apply to us as we weren't
doing any role changing, and weren't backing up the database manually with
the NORECOVERY switch (i.e. the backups were being done as usual by the log
shipping maint. plan).
Local server build is 8.00.997, and remote (DR) server build is 8.00.818.
Could the fact that they are slightly different versions have anything to do
with this problem?
Could this be corruption introducted by the network link? If so, is the
only way to fix this to fully restore the database again? Or is there some
way to get good copies of the log it failed on and restore those manually? I
don't have a huge amount of experience with log shipping, so any help would
be greatly appreciated - especially being a 24/7 mission critical DR server,
and in the middle of the holidays! Murphy's Law!
Thanks,
david
Hi David
The SQL Builds may cause a problem. I am not sure about it.
Rearding the file restore; it isn't necessary that you restore the entire
db. I would suggest the following steps:
1) Check the table msdb..log_shipping_plan_history for the last loaded file.
try
select * from msdb..log_shipping_plan_history order by endtime desc
2) Try restoring tha tfile manually from the Query Analyzer. try
restore log
<db_name>
from
disk = 'file_path'
with
standby = 'undo.txt'
3) if the above step succeeds keep restoring the successive trn files till
the step fails. Then that file at which the step fails is the corrupt file.
4) Copy only that file from the primary server and try step 2 with it.
5) re-run the LS Jobs and the ywill succeed.
Hope this helps.
I shall get back with mpre information about the affect of SQL builds on LS.
Thanks
Amer M J
MCP
"DavidCur" wrote:
> Hi,
> I've got a production server log shipping a 280GB database to a remote DR
> site server. It has been running without incident for months now, but last
> week it stopped restoring logs (the copy process was still running) with an
> error 3456:
> [Microsoft SQL-DMO (ODBC SQLState: HY000)] Error 3456: [Microsoft][ODBC SQL
> Server Driver][SQL Server]Could not redo log record (500478:68225:4), for
> transaction ID (3:1085081790), on page (3:2789016), database 'JDE_Prod' (5).
> Page: LSN = (500478:57038:10), type = 2. Log: OpCode = 2, context 3,
> PrevPageLSN: (500478:68221:4).
> I restored the remote database from a full tape backup shipped to the site
> via courier (because we weren't sure if the link was to blame for the problem
> restoring). Log shipping worked well again for a few days, but this morning
> has again stopped restoring with the exact same error!
> I've read the article "http://support.microsoft.com/kb/831950", and although
> it describes the same error, it doesnt seem to apply to us as we weren't
> doing any role changing, and weren't backing up the database manually with
> the NORECOVERY switch (i.e. the backups were being done as usual by the log
> shipping maint. plan).
> Local server build is 8.00.997, and remote (DR) server build is 8.00.818.
> Could the fact that they are slightly different versions have anything to do
> with this problem?
> Could this be corruption introducted by the network link? If so, is the
> only way to fix this to fully restore the database again? Or is there some
> way to get good copies of the log it failed on and restore those manually? I
> don't have a huge amount of experience with log shipping, so any help would
> be greatly appreciated - especially being a 24/7 mission critical DR server,
> and in the middle of the holidays! Murphy's Law!
>
> Thanks,
> david
|||Thanks for the quick response. The log files are copied and restored every
15 minutes. The problem occurred this morning around 12:15am. I've tried
your suggestion about restoring manually with the standby undo file.
I ran the following command (using the 12:00am file) successfully, but the
12:15am file produces the following output:
restore log JDE_Prod
from disk = 'K:\Backups\DRLogsIn\JDE_Prod_tlog_200512300015.TR N'
with standby = 'K:\Backups\DRLogsIn\LogUndo.tuf'
Deleting database file 'K:\Backups\DRLogsIn\LogUndo.tuf'.
Processed 34415 pages for database 'JDE_Prod', file 'JDE_PRODUCTION_log' on
file 1.
Server: Msg 3456, Level 21, State 1, Line 1
Could not redo log record (500478:68225:4), for transaction ID
(3:1085081790), on page (3:2789016), database 'JDE_Prod' (5). Page: LSN =
(500478:57038:10), type = 2. Log: OpCode = 2, context 3, PrevPageLSN:
(500478:68221:4).
Connection Broken
This 12:15 file has already been re-copied, but I will try again.
Would be interesting to see if you find any issues with different builds in
log shipping. The patches were applied to the local server a few months ago
(3 or 4 months), and log shipping has been running without incident this
whole time.
Thanks again,
Dave
"Amer M J" wrote:
> Hi David
> The SQL Builds may cause a problem. I am not sure about it.
> Rearding the file restore; it isn't necessary that you restore the entire
> db. I would suggest the following steps:
> 1) Check the table msdb..log_shipping_plan_history for the last loaded file.
> try
> select * from msdb..log_shipping_plan_history order by endtime desc
> 2) Try restoring tha tfile manually from the Query Analyzer. try
> restore log
> <db_name>
> from
> disk = 'file_path'
> with
> standby = 'undo.txt'
> 3) if the above step succeeds keep restoring the successive trn files till
> the step fails. Then that file at which the step fails is the corrupt file.
> 4) Copy only that file from the primary server and try step 2 with it.
> 5) re-run the LS Jobs and the ywill succeed.
> Hope this helps.
> I shall get back with mpre information about the affect of SQL builds on LS.
> Thanks
> Amer M J
> MCP
|||Hi Dave
I am curious here. Was the '.tuf' file deleted as per a part of the process
of manually ?
Also the builds do play a major role here. From what I can see as per your
information, the primary server is of a higher build than the secondary
server. So I was wondering how a log file of a db from a higher build was
getting restored onto a lower build server.
Also I would suggest checking out the integrity of the trn files on the
primary server. try
restore verifyonly command to check the backup set's integrity.
Please do check if anyother process is accessing the db on the secondary
server as this may disrupt the LS process.
Also check this link.
http://support.microsoft.com/kb/329487/en-us
Thanks
Amer M J
MCP
"DavidCur" wrote:
[vbcol=seagreen]
> Thanks for the quick response. The log files are copied and restored every
> 15 minutes. The problem occurred this morning around 12:15am. I've tried
> your suggestion about restoring manually with the standby undo file.
> I ran the following command (using the 12:00am file) successfully, but the
> 12:15am file produces the following output:
> restore log JDE_Prod
> from disk = 'K:\Backups\DRLogsIn\JDE_Prod_tlog_200512300015.TR N'
> with standby = 'K:\Backups\DRLogsIn\LogUndo.tuf'
> Deleting database file 'K:\Backups\DRLogsIn\LogUndo.tuf'.
> Processed 34415 pages for database 'JDE_Prod', file 'JDE_PRODUCTION_log' on
> file 1.
> Server: Msg 3456, Level 21, State 1, Line 1
> Could not redo log record (500478:68225:4), for transaction ID
> (3:1085081790), on page (3:2789016), database 'JDE_Prod' (5). Page: LSN =
> (500478:57038:10), type = 2. Log: OpCode = 2, context 3, PrevPageLSN:
> (500478:68221:4).
> Connection Broken
> This 12:15 file has already been re-copied, but I will try again.
> Would be interesting to see if you find any issues with different builds in
> log shipping. The patches were applied to the local server a few months ago
> (3 or 4 months), and log shipping has been running without incident this
> whole time.
> Thanks again,
> Dave
>
> "Amer M J" wrote:
|||Hi again,
Yes, the standby file (whatever it has been called) is automatically deleted
by the restore process.
Good news though, I seem to have log shipping going again! :-)
I re-copied the 12:15am log file (yet again, 3rd time) and restored it with
the same syntax as in my previous post, and it worked. So the problem must
lie with our link to the remote DR server. Its now been logged to the
telecom company who provide the WAN pipe.
As a precautionary measure I will schedule the remote server to be patched
to the same build level as our local server (will be next year though as we
are in a "holiday change freeze" now).
Funnily enough, the restore headeronly, verifyonly and filelistonly all
seemed to work fine with the corrupt file. Is it possible that the header of
the file was okay, while the actual data was bad?
Thanks very much for the help though, and I will update with anything new we
find.
Dave
"Amer M J" wrote:
> Hi Dave
> I am curious here. Was the '.tuf' file deleted as per a part of the process
> of manually ?
> Also the builds do play a major role here. From what I can see as per your
> information, the primary server is of a higher build than the secondary
> server. So I was wondering how a log file of a db from a higher build was
> getting restored onto a lower build server.
> Also I would suggest checking out the integrity of the trn files on the
> primary server. try
> restore verifyonly command to check the backup set's integrity.
> Please do check if anyother process is accessing the db on the secondary
> server as this may disrupt the LS process.
> Also check this link.
> http://support.microsoft.com/kb/329487/en-us
> Thanks
> Amer M J
> MCP
sql
log shipping question
Hi,
I've established the log shipping between my Primary database server and the
Stand by database server.
In the Stand by server, the database is gray, and in the BACKUP folder,
there're MyDB_init.bak and many .TRN files.
1.How do I make the MyDB's color not gray in that Stand by server? I wanna
test the SELECT and see if the record between the Primary and Stand by
server are consistant.
2. What will happen if I delete some .TRN files?
Thanks for help.
Jason
Jason
A standby database must be read-only. You can run SELECT statements againts
it. If you want the db READ-WRITE apply last log file and run
RESTORE DATABASE database_name WITH RECOVERY
EXEC SP_DBOPTION 'database_name', 'read only', 'false'
"Jason Huang" <JasonHuang8888@.hotmail.com> wrote in message
news:OGKoEINJIHA.5208@.TK2MSFTNGP04.phx.gbl...
> Hi,
> I've established the log shipping between my Primary database server and
> the
> Stand by database server.
> In the Stand by server, the database is gray, and in the BACKUP folder,
> there're MyDB_init.bak and many .TRN files.
> 1.How do I make the MyDB's color not gray in that Stand by server? I
> wanna
> test the SELECT and see if the record between the Primary and Stand by
> server are consistant.
> 2. What will happen if I delete some .TRN files?
> Thanks for help.
>
> Jason
>
I've established the log shipping between my Primary database server and the
Stand by database server.
In the Stand by server, the database is gray, and in the BACKUP folder,
there're MyDB_init.bak and many .TRN files.
1.How do I make the MyDB's color not gray in that Stand by server? I wanna
test the SELECT and see if the record between the Primary and Stand by
server are consistant.
2. What will happen if I delete some .TRN files?
Thanks for help.
Jason
Jason
A standby database must be read-only. You can run SELECT statements againts
it. If you want the db READ-WRITE apply last log file and run
RESTORE DATABASE database_name WITH RECOVERY
EXEC SP_DBOPTION 'database_name', 'read only', 'false'
"Jason Huang" <JasonHuang8888@.hotmail.com> wrote in message
news:OGKoEINJIHA.5208@.TK2MSFTNGP04.phx.gbl...
> Hi,
> I've established the log shipping between my Primary database server and
> the
> Stand by database server.
> In the Stand by server, the database is gray, and in the BACKUP folder,
> there're MyDB_init.bak and many .TRN files.
> 1.How do I make the MyDB's color not gray in that Stand by server? I
> wanna
> test the SELECT and see if the record between the Primary and Stand by
> server are consistant.
> 2. What will happen if I delete some .TRN files?
> Thanks for help.
>
> Jason
>
Wednesday, March 21, 2012
Log Shipping on Clustered SQL Server
Hi,
I'm trying to implement Log Shipping on a 2 Node SQL Cluster for certain
DB's.
As far as I understand, I've to share the folder where the transaction logs
are backed.
My questions are:
a) I cannot configure the DB to back the TRN's on a network drive, it says
"Not Allowed" The drive should be local to the SQL server.
b) If I create a share on the existing Drive where the TRN's are getting
back, that share will be lost if a failover occurs.
c) Is it like you've to write a script that will move the TRN's to a shared
Location.
I'd really appreciate any feedback on this.
Thanks a lot.
Vick
You can back up to a UNC network share.
HowTo: Backup to UNC name using Database Maintenance Wizard
http://support.microsoft.com/kb/555128
If you insist on storing the backup files to local cluster disks, you need
to create a separate file share that is a clustered resource. That way, any
instance can access it regardless of the current host node.
Geoff N. Hiten
Senior Database Administrator
Microsoft SQL Server MVP
"Vick Shaw" <nospam@.msft.com> wrote in message
news:eeJaOvdUHHA.1636@.TK2MSFTNGP02.phx.gbl...
> Hi,
> I'm trying to implement Log Shipping on a 2 Node SQL Cluster for certain
> DB's.
> As far as I understand, I've to share the folder where the transaction
> logs
> are backed.
> My questions are:
> a) I cannot configure the DB to back the TRN's on a network drive, it says
> "Not Allowed" The drive should be local to the SQL server.
> b) If I create a share on the existing Drive where the TRN's are getting
> back, that share will be lost if a failover occurs.
> c) Is it like you've to write a script that will move the TRN's to a
> shared
> Location.
> I'd really appreciate any feedback on this.
> Thanks a lot.
> Vick
>
|||Thanks Geoff..
So which is the right way to do it. Should I back it to UNC or should I
create a separate file share?
Thanks again
Vick
"Geoff N. Hiten" <SQLCraftsman@.gmail.com> wrote in message
news:%23pKfx7dUHHA.4744@.TK2MSFTNGP02.phx.gbl...
> You can back up to a UNC network share.
> HowTo: Backup to UNC name using Database Maintenance Wizard
> http://support.microsoft.com/kb/555128
> If you insist on storing the backup files to local cluster disks, you need
> to create a separate file share that is a clustered resource. That way,
any[vbcol=seagreen]
> instance can access it regardless of the current host node.
> --
> Geoff N. Hiten
> Senior Database Administrator
> Microsoft SQL Server MVP
>
> "Vick Shaw" <nospam@.msft.com> wrote in message
> news:eeJaOvdUHHA.1636@.TK2MSFTNGP02.phx.gbl...
says
>
|||Hi Geoff,
When I tried to put a UNC in the TRN log file path it gave me an error:
Error:5110 \\domain\filename.ldf is on a network device not supported for
database files.
ALTER DATABSE failed...
"Vick Shaw" <nospam@.msft.com> wrote in message
news:OS77SMgUHHA.1212@.TK2MSFTNGP03.phx.gbl...[vbcol=seagreen]
> Thanks Geoff..
> So which is the right way to do it. Should I back it to UNC or should I
> create a separate file share?
> Thanks again
> Vick
>
> "Geoff N. Hiten" <SQLCraftsman@.gmail.com> wrote in message
> news:%23pKfx7dUHHA.4744@.TK2MSFTNGP02.phx.gbl...
need[vbcol=seagreen]
> any
certain[vbcol=seagreen]
> says
getting
>
|||Slight misunderstanding.
I think you are trying to store an actual transaction log file, not a
transaction log backup, on a network share. At least, that is what the
error is reporting.
Which version of SQL are you using and what tool are you using? Can you
send the exact steps you are using to generate this error.
Geoff N. Hiten
Senior Database Administrator
Microsoft SQL Server MVP
"Vick Shaw" <nospam@.msft.com> wrote in message
news:uuJjFWgUHHA.1212@.TK2MSFTNGP03.phx.gbl...
> Hi Geoff,
> When I tried to put a UNC in the TRN log file path it gave me an error:
> Error:5110 \\domain\filename.ldf is on a network device not supported for
> database files.
> ALTER DATABSE failed...
> "Vick Shaw" <nospam@.msft.com> wrote in message
> news:OS77SMgUHHA.1212@.TK2MSFTNGP03.phx.gbl...
> need
> certain
> getting
>
I'm trying to implement Log Shipping on a 2 Node SQL Cluster for certain
DB's.
As far as I understand, I've to share the folder where the transaction logs
are backed.
My questions are:
a) I cannot configure the DB to back the TRN's on a network drive, it says
"Not Allowed" The drive should be local to the SQL server.
b) If I create a share on the existing Drive where the TRN's are getting
back, that share will be lost if a failover occurs.
c) Is it like you've to write a script that will move the TRN's to a shared
Location.
I'd really appreciate any feedback on this.
Thanks a lot.
Vick
You can back up to a UNC network share.
HowTo: Backup to UNC name using Database Maintenance Wizard
http://support.microsoft.com/kb/555128
If you insist on storing the backup files to local cluster disks, you need
to create a separate file share that is a clustered resource. That way, any
instance can access it regardless of the current host node.
Geoff N. Hiten
Senior Database Administrator
Microsoft SQL Server MVP
"Vick Shaw" <nospam@.msft.com> wrote in message
news:eeJaOvdUHHA.1636@.TK2MSFTNGP02.phx.gbl...
> Hi,
> I'm trying to implement Log Shipping on a 2 Node SQL Cluster for certain
> DB's.
> As far as I understand, I've to share the folder where the transaction
> logs
> are backed.
> My questions are:
> a) I cannot configure the DB to back the TRN's on a network drive, it says
> "Not Allowed" The drive should be local to the SQL server.
> b) If I create a share on the existing Drive where the TRN's are getting
> back, that share will be lost if a failover occurs.
> c) Is it like you've to write a script that will move the TRN's to a
> shared
> Location.
> I'd really appreciate any feedback on this.
> Thanks a lot.
> Vick
>
|||Thanks Geoff..
So which is the right way to do it. Should I back it to UNC or should I
create a separate file share?
Thanks again
Vick
"Geoff N. Hiten" <SQLCraftsman@.gmail.com> wrote in message
news:%23pKfx7dUHHA.4744@.TK2MSFTNGP02.phx.gbl...
> You can back up to a UNC network share.
> HowTo: Backup to UNC name using Database Maintenance Wizard
> http://support.microsoft.com/kb/555128
> If you insist on storing the backup files to local cluster disks, you need
> to create a separate file share that is a clustered resource. That way,
any[vbcol=seagreen]
> instance can access it regardless of the current host node.
> --
> Geoff N. Hiten
> Senior Database Administrator
> Microsoft SQL Server MVP
>
> "Vick Shaw" <nospam@.msft.com> wrote in message
> news:eeJaOvdUHHA.1636@.TK2MSFTNGP02.phx.gbl...
says
>
|||Hi Geoff,
When I tried to put a UNC in the TRN log file path it gave me an error:
Error:5110 \\domain\filename.ldf is on a network device not supported for
database files.
ALTER DATABSE failed...
"Vick Shaw" <nospam@.msft.com> wrote in message
news:OS77SMgUHHA.1212@.TK2MSFTNGP03.phx.gbl...[vbcol=seagreen]
> Thanks Geoff..
> So which is the right way to do it. Should I back it to UNC or should I
> create a separate file share?
> Thanks again
> Vick
>
> "Geoff N. Hiten" <SQLCraftsman@.gmail.com> wrote in message
> news:%23pKfx7dUHHA.4744@.TK2MSFTNGP02.phx.gbl...
need[vbcol=seagreen]
> any
certain[vbcol=seagreen]
> says
getting
>
|||Slight misunderstanding.
I think you are trying to store an actual transaction log file, not a
transaction log backup, on a network share. At least, that is what the
error is reporting.
Which version of SQL are you using and what tool are you using? Can you
send the exact steps you are using to generate this error.
Geoff N. Hiten
Senior Database Administrator
Microsoft SQL Server MVP
"Vick Shaw" <nospam@.msft.com> wrote in message
news:uuJjFWgUHHA.1212@.TK2MSFTNGP03.phx.gbl...
> Hi Geoff,
> When I tried to put a UNC in the TRN log file path it gave me an error:
> Error:5110 \\domain\filename.ldf is on a network device not supported for
> database files.
> ALTER DATABSE failed...
> "Vick Shaw" <nospam@.msft.com> wrote in message
> news:OS77SMgUHHA.1212@.TK2MSFTNGP03.phx.gbl...
> need
> certain
> getting
>
Friday, March 9, 2012
Log shipping fail over
I assume this is the correct spot for a log shipping question. Pardon if
it's not.
I've set up a log shipping pair (first time) and everything 'appears' to be
running fine, but I have a question about fail over.
In my research I have found that, in order to bring the secondary up as the
primary, I have to run a few procedures. The first of which is to be run on
the primary server to change its role. How would I do this if the server has
crashed? What steps should I take if this is the scenario?
Thanks in advance.
So what's the best fail over method should the primary server crash? This is
how I see it,
1) Run sp_change_secondary_role on the secondary server.
2) Switch app to point to secondary server or rename and re-IP secondary
server.
3) The users log into the application and the app uses one SQL login, so I
assume I don't need to worry too much about resolving logins.
This will get my users back to functional? What about once the old primary
is back up? Should I then run sp_change_primary_role? Or would it be best
to delete the maintenance jobs and recreate the log shipping pair?
Sorry about all of the questions, I've seen plenty of information on how to
change roles if the primary is still functional, but nothing concerning a
primary server crash.
Again, thanks in advance.
"Paul Ibison" wrote:
> Mick,
> you're correct - sp_change_primary_role removes the
> primary server from the maintenance plan and it will not
> usually be possible to do this in reality. The key
> failover procedure is sp_change_secondary_role which gets
> the last log and restores the system with recovery.
> Rgds,
> Paul Ibison (SQL Server MVP)
>
>
|||Mick,
Run sp_change_secondary_role, rename the server and use sp_dropserver,
sp_addserver, restart services. Create the login you require and use
sp_change_users_login if you haven't taken the SID.
There's no simple way of switching back roles to the primary, apart from
setting up a new log shipping pair and reversing the process.
The old maintenance plan at this stage is now defunct and needs to be
removed if the primary server comes online at some later stage.
HTH,
Paul Ibison (SQL Server MVP)
[vbcol=seagreen]
it's not.
I've set up a log shipping pair (first time) and everything 'appears' to be
running fine, but I have a question about fail over.
In my research I have found that, in order to bring the secondary up as the
primary, I have to run a few procedures. The first of which is to be run on
the primary server to change its role. How would I do this if the server has
crashed? What steps should I take if this is the scenario?
Thanks in advance.
So what's the best fail over method should the primary server crash? This is
how I see it,
1) Run sp_change_secondary_role on the secondary server.
2) Switch app to point to secondary server or rename and re-IP secondary
server.
3) The users log into the application and the app uses one SQL login, so I
assume I don't need to worry too much about resolving logins.
This will get my users back to functional? What about once the old primary
is back up? Should I then run sp_change_primary_role? Or would it be best
to delete the maintenance jobs and recreate the log shipping pair?
Sorry about all of the questions, I've seen plenty of information on how to
change roles if the primary is still functional, but nothing concerning a
primary server crash.
Again, thanks in advance.
"Paul Ibison" wrote:
> Mick,
> you're correct - sp_change_primary_role removes the
> primary server from the maintenance plan and it will not
> usually be possible to do this in reality. The key
> failover procedure is sp_change_secondary_role which gets
> the last log and restores the system with recovery.
> Rgds,
> Paul Ibison (SQL Server MVP)
>
>
|||Mick,
Run sp_change_secondary_role, rename the server and use sp_dropserver,
sp_addserver, restart services. Create the login you require and use
sp_change_users_login if you haven't taken the SID.
There's no simple way of switching back roles to the primary, apart from
setting up a new log shipping pair and reversing the process.
The old maintenance plan at this stage is now defunct and needs to be
removed if the primary server comes online at some later stage.
HTH,
Paul Ibison (SQL Server MVP)
[vbcol=seagreen]
Log Shipping copy with compression
I've got several secondary servers setup against my production server, and
working fine. However, one is across a t-1, and the file copying can really
effect latency across this link.
I've been searching far an wide for a "replicator" that has a client server
component, that can do streaming compression. TRNs compress down incrediably
well. I could use a util to zip them to a unc, and then unzip on the other
side, but this seems dumb. Why oh why doesn't SMB support compression...we
have gone backwards since the z-modem days
.
I'm trying to get rsync to work using cygwin, but of course it is a pain in
the butt. Does anyone know of affoardable software that does this seamly
simple task. I'm about to program my own.
Compression has been considered on the packet level, but the reason that it
is not implemented is that in general the data travelling across the wire is
binary and the compression ratio and cost involved in compressing binary
data outweighs the savings in doing so. Compressing purely textual data does
provide much better compression.
Your best bet is to zip then before sending, and then unzip them on the
other end.
"et" <et@.discussions.microsoft.com> wrote in message
news:83CF2440-9764-47D7-8163-AE47C3106035@.microsoft.com...
> I've got several secondary servers setup against my production server, and
> working fine. However, one is across a t-1, and the file copying can
really
> effect latency across this link.
> I've been searching far an wide for a "replicator" that has a client
server
> component, that can do streaming compression. TRNs compress down
incrediably
> well. I could use a util to zip them to a unc, and then unzip on the other
> side, but this seems dumb. Why oh why doesn't SMB support compression...we
> have gone backwards since the z-modem days.
> I'm trying to get rsync to work using cygwin, but of course it is a pain
in
> the butt. Does anyone know of affoardable software that does this seamly
> simple task. I'm about to program my own.
>
|||As I recall Windows 2003 was supposed to offer SMB copying of NTFS compressed
files from server to server without uncompressing in the middle.
But as I've never seen that feature advertised, I'm guessing it never made the
cut before release.
> I've been searching far an wide for a "replicator" that has a client server
> component, that can do streaming compression. TRNs compress down incrediably
> well. I could use a util to zip them to a unc, and then unzip on the other
> side, but this seems dumb. Why oh why doesn't SMB support compression...we
> have gone backwards since the z-modem days.
> I'm trying to get rsync to work using cygwin, but of course it is a pain in
> the butt. Does anyone know of affoardable software that does this seamly
> simple task. I'm about to program my own.
>
Neil Pike. Protech Computing Ltd
Reply here - no email
SQL FAQ (484 entries) see
http://forumsb.compuserve.com/gvforu...?SRV=MSDevApps
(faqxxx.zip in lib 7)
or http://www.ntfaq.com/Articles/Index...partmentID=800
or www.sqlserverfaq.com
or www.mssqlserver.com/faq
working fine. However, one is across a t-1, and the file copying can really
effect latency across this link.
I've been searching far an wide for a "replicator" that has a client server
component, that can do streaming compression. TRNs compress down incrediably
well. I could use a util to zip them to a unc, and then unzip on the other
side, but this seems dumb. Why oh why doesn't SMB support compression...we
have gone backwards since the z-modem days
.I'm trying to get rsync to work using cygwin, but of course it is a pain in
the butt. Does anyone know of affoardable software that does this seamly
simple task. I'm about to program my own.
Compression has been considered on the packet level, but the reason that it
is not implemented is that in general the data travelling across the wire is
binary and the compression ratio and cost involved in compressing binary
data outweighs the savings in doing so. Compressing purely textual data does
provide much better compression.
Your best bet is to zip then before sending, and then unzip them on the
other end.
"et" <et@.discussions.microsoft.com> wrote in message
news:83CF2440-9764-47D7-8163-AE47C3106035@.microsoft.com...
> I've got several secondary servers setup against my production server, and
> working fine. However, one is across a t-1, and the file copying can
really
> effect latency across this link.
> I've been searching far an wide for a "replicator" that has a client
server
> component, that can do streaming compression. TRNs compress down
incrediably
> well. I could use a util to zip them to a unc, and then unzip on the other
> side, but this seems dumb. Why oh why doesn't SMB support compression...we
> have gone backwards since the z-modem days
.> I'm trying to get rsync to work using cygwin, but of course it is a pain
in
> the butt. Does anyone know of affoardable software that does this seamly
> simple task. I'm about to program my own.
>
|||As I recall Windows 2003 was supposed to offer SMB copying of NTFS compressed
files from server to server without uncompressing in the middle.
But as I've never seen that feature advertised, I'm guessing it never made the
cut before release.
> I've been searching far an wide for a "replicator" that has a client server
> component, that can do streaming compression. TRNs compress down incrediably
> well. I could use a util to zip them to a unc, and then unzip on the other
> side, but this seems dumb. Why oh why doesn't SMB support compression...we
> have gone backwards since the z-modem days
.> I'm trying to get rsync to work using cygwin, but of course it is a pain in
> the butt. Does anyone know of affoardable software that does this seamly
> simple task. I'm about to program my own.
>
Neil Pike. Protech Computing Ltd
Reply here - no email
SQL FAQ (484 entries) see
http://forumsb.compuserve.com/gvforu...?SRV=MSDevApps
(faqxxx.zip in lib 7)
or http://www.ntfaq.com/Articles/Index...partmentID=800
or www.sqlserverfaq.com
or www.mssqlserver.com/faq
Wednesday, March 7, 2012
log shipping and replication
Ive got my publishers and distributors on the same server say Server A . We
have implemented log shipping as Disaster Recovery solution.
Ive got my published databases log shipped to Server B.
My questions are : Do I need to log ship the distribution database as well ?
How can I recover from this scenario should Server A fail ?
I have read Books Online on Replication and Log shipping.. We cannot
implement the " sync with backup " option because of the increased latency.
It also talks about the semi-synchronous mode. I havent really followed it
for the fact that the distribution database is on the same server as the
publisher and currently we are not log shipping that.
Can someone guide me here on how to recover based upon my settings ? Using
SQL 2000
Thanks
Hassan,
In my experience when replication databases are restored onto another server
than the original, restoration is only partially successful using
KEEP_REPLICATION, and on failover it was not possible to rename the server
then start synchronizing - I found it easiest to recreate the publications
from scratch. However if you restore to Server A itself (or another "Server
A") then it should be ok.
The "sync with backup" option is to ensure that transactions don't get into
the distribution database before the publication database is backed up,
otherwise the distribution database backup could be ahead of the publication
backup. You can achieve the same effect by making sure that the restore of
the publication database and logs is older than the restore of the
distribution database - then you have essentially performed a synchronous
mode backup. In your case you will need a distribution backup, as regular as
possible.
To see the order of restores if Server A goes down, have a look in BOL at
"replication, backup and restore operations".
hth,
Paul Ibison
have implemented log shipping as Disaster Recovery solution.
Ive got my published databases log shipped to Server B.
My questions are : Do I need to log ship the distribution database as well ?
How can I recover from this scenario should Server A fail ?
I have read Books Online on Replication and Log shipping.. We cannot
implement the " sync with backup " option because of the increased latency.
It also talks about the semi-synchronous mode. I havent really followed it
for the fact that the distribution database is on the same server as the
publisher and currently we are not log shipping that.
Can someone guide me here on how to recover based upon my settings ? Using
SQL 2000
Thanks
Hassan,
In my experience when replication databases are restored onto another server
than the original, restoration is only partially successful using
KEEP_REPLICATION, and on failover it was not possible to rename the server
then start synchronizing - I found it easiest to recreate the publications
from scratch. However if you restore to Server A itself (or another "Server
A") then it should be ok.
The "sync with backup" option is to ensure that transactions don't get into
the distribution database before the publication database is backed up,
otherwise the distribution database backup could be ahead of the publication
backup. You can achieve the same effect by making sure that the restore of
the publication database and logs is older than the restore of the
distribution database - then you have essentially performed a synchronous
mode backup. In your case you will need a distribution backup, as regular as
possible.
To see the order of restores if Server A goes down, have a look in BOL at
"replication, backup and restore operations".
hth,
Paul Ibison
Friday, February 24, 2012
Log shipping and DB corruption
Hi,
I've set up two log shipping pairs between three Microsoft SQL Server 2000
SP3 databases: a primary, a main standby, and an auxiliary standby database.
For the main standby database jobs that create, copy, and restore transaction
log backups run one after another without any delay. Now if the primary
database fails it may well be because it has become corrupt. According to
documentation on the Microsoft website and considering my set-up (i.e. no
delay for loading transaction logs), corrupt data may be carried over into
the main standby databaseby means of log shipping (could you please elaborate
on how/ in which cases this can happen?) . So in order to deal with a
situation, when it's not possible to switch over to the main standby
database, because corrupt data has been carried over into it, I maintain a
lagged auxiliary standby database, which could be restored up to the moment
of corruption and used instead. The question is, how can I determine this
moment? Is it the moment a message about the corrupt primary is logged in the
SQL Server error log? Can this moment be determined at all? How would you
deal with the situation I described?
Respectfully,
Oskar
Oskar
First of all yes it will be logged into ERROR.LOG . At my work place I run
DBCC CHECKDB on regular period.
If the database get corrupted but users still have an access ,so run DBCC
CHECKDB (see more in the BOL) .Personally I have not tried to run this
command on "mirrored" database , so worth to test.
"Oskar" <Oskar@.discussions.microsoft.com> wrote in message
news:B6562D0D-99C4-4291-81DB-A5C67D5DE334@.microsoft.com...
> Hi,
> I've set up two log shipping pairs between three Microsoft SQL Server 2000
> SP3 databases: a primary, a main standby, and an auxiliary standby
> database.
> For the main standby database jobs that create, copy, and restore
> transaction
> log backups run one after another without any delay. Now if the primary
> database fails it may well be because it has become corrupt. According to
> documentation on the Microsoft website and considering my set-up (i.e. no
> delay for loading transaction logs), corrupt data may be carried over into
> the main standby databaseby means of log shipping (could you please
> elaborate
> on how/ in which cases this can happen?) . So in order to deal with a
> situation, when it's not possible to switch over to the main standby
> database, because corrupt data has been carried over into it, I maintain a
> lagged auxiliary standby database, which could be restored up to the
> moment
> of corruption and used instead. The question is, how can I determine this
> moment? Is it the moment a message about the corrupt primary is logged in
> the
> SQL Server error log? Can this moment be determined at all? How would you
> deal with the situation I described?
> Respectfully,
> Oskar
>
|||Very often, the cause is data corruption is the user or administration. For
example, someone *thought* they were in test but they were in prod and
deleted or modified data. It's very important to know when the data was
corrupted because that is the point at which you want to stop restoring your
log.
If you copy the log over to your standby server right after it is backed up,
that's a good thing. Putting a delay of the restoration of the log gives
you a bit of time to investigate. At the very least, you can restore WITH
STANDBY to have a look at what the data looked like and then copy that data
back to the primary.
Tom
Thomas A. Moreau, BSc, PhD, MCSE, MCDBA, MCITP, MCTS
SQL Server MVP
Toronto, ON Canada
https://mvp.support.microsoft.com/profile/Tom.Moreau
"Oskar" <Oskar@.discussions.microsoft.com> wrote in message
news:B6562D0D-99C4-4291-81DB-A5C67D5DE334@.microsoft.com...
Hi,
I've set up two log shipping pairs between three Microsoft SQL Server 2000
SP3 databases: a primary, a main standby, and an auxiliary standby database.
For the main standby database jobs that create, copy, and restore
transaction
log backups run one after another without any delay. Now if the primary
database fails it may well be because it has become corrupt. According to
documentation on the Microsoft website and considering my set-up (i.e. no
delay for loading transaction logs), corrupt data may be carried over into
the main standby databaseby means of log shipping (could you please
elaborate
on how/ in which cases this can happen?) . So in order to deal with a
situation, when it's not possible to switch over to the main standby
database, because corrupt data has been carried over into it, I maintain a
lagged auxiliary standby database, which could be restored up to the moment
of corruption and used instead. The question is, how can I determine this
moment? Is it the moment a message about the corrupt primary is logged in
the
SQL Server error log? Can this moment be determined at all? How would you
deal with the situation I described?
Respectfully,
Oskar
|||Thanks Tom. Though by the word "corruption" here I meant the corruption of
SQL Server's internal storage structures (for lack of a better name),
detected by the CHECKDB command, not the application or user negligence.
The question still remains, how can I determine the moment, just before
corruption was loaded into the main standby database, after which all the
remaining transaction log backups are to be discarded?
"Tom Moreau" wrote:
> Very often, the cause is data corruption is the user or administration. For
> example, someone *thought* they were in test but they were in prod and
> deleted or modified data. It's very important to know when the data was
> corrupted because that is the point at which you want to stop restoring your
> log.
> If you copy the log over to your standby server right after it is backed up,
> that's a good thing. Putting a delay of the restoration of the log gives
> you a bit of time to investigate. At the very least, you can restore WITH
> STANDBY to have a look at what the data looked like and then copy that data
> back to the primary.
> --
> Tom
> ----
> Thomas A. Moreau, BSc, PhD, MCSE, MCDBA, MCITP, MCTS
> SQL Server MVP
> Toronto, ON Canada
> https://mvp.support.microsoft.com/profile/Tom.Moreau
>
> "Oskar" <Oskar@.discussions.microsoft.com> wrote in message
> news:B6562D0D-99C4-4291-81DB-A5C67D5DE334@.microsoft.com...
> Hi,
> I've set up two log shipping pairs between three Microsoft SQL Server 2000
> SP3 databases: a primary, a main standby, and an auxiliary standby database.
> For the main standby database jobs that create, copy, and restore
> transaction
> log backups run one after another without any delay. Now if the primary
> database fails it may well be because it has become corrupt. According to
> documentation on the Microsoft website and considering my set-up (i.e. no
> delay for loading transaction logs), corrupt data may be carried over into
> the main standby databaseby means of log shipping (could you please
> elaborate
> on how/ in which cases this can happen?) . So in order to deal with a
> situation, when it's not possible to switch over to the main standby
> database, because corrupt data has been carried over into it, I maintain a
> lagged auxiliary standby database, which could be restored up to the moment
> of corruption and used instead. The question is, how can I determine this
> moment? Is it the moment a message about the corrupt primary is logged in
> the
> SQL Server error log? Can this moment be determined at all? How would you
> deal with the situation I described?
> Respectfully,
> Oskar
>
|||The error log is your best bet - if SQL Server detected the corruption.
Tom
Thomas A. Moreau, BSc, PhD, MCSE, MCDBA, MCITP, MCTS
SQL Server MVP
Toronto, ON Canada
https://mvp.support.microsoft.com/profile/Tom.Moreau
"Oskar" <Oskar@.discussions.microsoft.com> wrote in message
news:16E74120-24C8-4C6E-B937-61A32EB727CA@.microsoft.com...
Thanks Tom. Though by the word "corruption" here I meant the corruption of
SQL Server's internal storage structures (for lack of a better name),
detected by the CHECKDB command, not the application or user negligence.
The question still remains, how can I determine the moment, just before
corruption was loaded into the main standby database, after which all the
remaining transaction log backups are to be discarded?
"Tom Moreau" wrote:
> Very often, the cause is data corruption is the user or administration.
> For
> example, someone *thought* they were in test but they were in prod and
> deleted or modified data. It's very important to know when the data was
> corrupted because that is the point at which you want to stop restoring
> your
> log.
> If you copy the log over to your standby server right after it is backed
> up,
> that's a good thing. Putting a delay of the restoration of the log gives
> you a bit of time to investigate. At the very least, you can restore WITH
> STANDBY to have a look at what the data looked like and then copy that
> data
> back to the primary.
> --
> Tom
> ----
> Thomas A. Moreau, BSc, PhD, MCSE, MCDBA, MCITP, MCTS
> SQL Server MVP
> Toronto, ON Canada
> https://mvp.support.microsoft.com/profile/Tom.Moreau
>
> "Oskar" <Oskar@.discussions.microsoft.com> wrote in message
> news:B6562D0D-99C4-4291-81DB-A5C67D5DE334@.microsoft.com...
> Hi,
> I've set up two log shipping pairs between three Microsoft SQL Server 2000
> SP3 databases: a primary, a main standby, and an auxiliary standby
> database.
> For the main standby database jobs that create, copy, and restore
> transaction
> log backups run one after another without any delay. Now if the primary
> database fails it may well be because it has become corrupt. According to
> documentation on the Microsoft website and considering my set-up (i.e. no
> delay for loading transaction logs), corrupt data may be carried over into
> the main standby databaseby means of log shipping (could you please
> elaborate
> on how/ in which cases this can happen?) . So in order to deal with a
> situation, when it's not possible to switch over to the main standby
> database, because corrupt data has been carried over into it, I maintain a
> lagged auxiliary standby database, which could be restored up to the
> moment
> of corruption and used instead. The question is, how can I determine this
> moment? Is it the moment a message about the corrupt primary is logged in
> the
> SQL Server error log? Can this moment be determined at all? How would you
> deal with the situation I described?
> Respectfully,
> Oskar
>
|||Apparently the problem with this is that the error message may be logged only
some time after the corruption. How long does it take to log the message
after the corruption has taken place?
"Tom Moreau" wrote:
> The error log is your best bet - if SQL Server detected the corruption.
> --
> Tom
> ----
> Thomas A. Moreau, BSc, PhD, MCSE, MCDBA, MCITP, MCTS
> SQL Server MVP
> Toronto, ON Canada
> https://mvp.support.microsoft.com/profile/Tom.Moreau
>
> "Oskar" <Oskar@.discussions.microsoft.com> wrote in message
> news:16E74120-24C8-4C6E-B937-61A32EB727CA@.microsoft.com...
> Thanks Tom. Though by the word "corruption" here I meant the corruption of
> SQL Server's internal storage structures (for lack of a better name),
> detected by the CHECKDB command, not the application or user negligence.
> The question still remains, how can I determine the moment, just before
> corruption was loaded into the main standby database, after which all the
> remaining transaction log backups are to be discarded?
>
> "Tom Moreau" wrote:
>
>
|||That depends. If SQL Server notices it, it goes into the log right away.
However, I have seen situations where it does not notice it and you find out
the hard way.
Tom
Thomas A. Moreau, BSc, PhD, MCSE, MCDBA, MCITP, MCTS
SQL Server MVP
Toronto, ON Canada
https://mvp.support.microsoft.com/profile/Tom.Moreau
"Oskar" <Oskar@.discussions.microsoft.com> wrote in message
news:F4DDD609-5D12-4E92-A6A9-6A437EE5C746@.microsoft.com...
Apparently the problem with this is that the error message may be logged
only
some time after the corruption. How long does it take to log the message
after the corruption has taken place?
"Tom Moreau" wrote:
> The error log is your best bet - if SQL Server detected the corruption.
> --
> Tom
> ----
> Thomas A. Moreau, BSc, PhD, MCSE, MCDBA, MCITP, MCTS
> SQL Server MVP
> Toronto, ON Canada
> https://mvp.support.microsoft.com/profile/Tom.Moreau
>
> "Oskar" <Oskar@.discussions.microsoft.com> wrote in message
> news:16E74120-24C8-4C6E-B937-61A32EB727CA@.microsoft.com...
> Thanks Tom. Though by the word "corruption" here I meant the corruption of
> SQL Server's internal storage structures (for lack of a better name),
> detected by the CHECKDB command, not the application or user negligence.
> The question still remains, how can I determine the moment, just before
> corruption was loaded into the main standby database, after which all the
> remaining transaction log backups are to be discarded?
>
> "Tom Moreau" wrote:
>
>
I've set up two log shipping pairs between three Microsoft SQL Server 2000
SP3 databases: a primary, a main standby, and an auxiliary standby database.
For the main standby database jobs that create, copy, and restore transaction
log backups run one after another without any delay. Now if the primary
database fails it may well be because it has become corrupt. According to
documentation on the Microsoft website and considering my set-up (i.e. no
delay for loading transaction logs), corrupt data may be carried over into
the main standby databaseby means of log shipping (could you please elaborate
on how/ in which cases this can happen?) . So in order to deal with a
situation, when it's not possible to switch over to the main standby
database, because corrupt data has been carried over into it, I maintain a
lagged auxiliary standby database, which could be restored up to the moment
of corruption and used instead. The question is, how can I determine this
moment? Is it the moment a message about the corrupt primary is logged in the
SQL Server error log? Can this moment be determined at all? How would you
deal with the situation I described?
Respectfully,
Oskar
Oskar
First of all yes it will be logged into ERROR.LOG . At my work place I run
DBCC CHECKDB on regular period.
If the database get corrupted but users still have an access ,so run DBCC
CHECKDB (see more in the BOL) .Personally I have not tried to run this
command on "mirrored" database , so worth to test.
"Oskar" <Oskar@.discussions.microsoft.com> wrote in message
news:B6562D0D-99C4-4291-81DB-A5C67D5DE334@.microsoft.com...
> Hi,
> I've set up two log shipping pairs between three Microsoft SQL Server 2000
> SP3 databases: a primary, a main standby, and an auxiliary standby
> database.
> For the main standby database jobs that create, copy, and restore
> transaction
> log backups run one after another without any delay. Now if the primary
> database fails it may well be because it has become corrupt. According to
> documentation on the Microsoft website and considering my set-up (i.e. no
> delay for loading transaction logs), corrupt data may be carried over into
> the main standby databaseby means of log shipping (could you please
> elaborate
> on how/ in which cases this can happen?) . So in order to deal with a
> situation, when it's not possible to switch over to the main standby
> database, because corrupt data has been carried over into it, I maintain a
> lagged auxiliary standby database, which could be restored up to the
> moment
> of corruption and used instead. The question is, how can I determine this
> moment? Is it the moment a message about the corrupt primary is logged in
> the
> SQL Server error log? Can this moment be determined at all? How would you
> deal with the situation I described?
> Respectfully,
> Oskar
>
|||Very often, the cause is data corruption is the user or administration. For
example, someone *thought* they were in test but they were in prod and
deleted or modified data. It's very important to know when the data was
corrupted because that is the point at which you want to stop restoring your
log.
If you copy the log over to your standby server right after it is backed up,
that's a good thing. Putting a delay of the restoration of the log gives
you a bit of time to investigate. At the very least, you can restore WITH
STANDBY to have a look at what the data looked like and then copy that data
back to the primary.
Tom
Thomas A. Moreau, BSc, PhD, MCSE, MCDBA, MCITP, MCTS
SQL Server MVP
Toronto, ON Canada
https://mvp.support.microsoft.com/profile/Tom.Moreau
"Oskar" <Oskar@.discussions.microsoft.com> wrote in message
news:B6562D0D-99C4-4291-81DB-A5C67D5DE334@.microsoft.com...
Hi,
I've set up two log shipping pairs between three Microsoft SQL Server 2000
SP3 databases: a primary, a main standby, and an auxiliary standby database.
For the main standby database jobs that create, copy, and restore
transaction
log backups run one after another without any delay. Now if the primary
database fails it may well be because it has become corrupt. According to
documentation on the Microsoft website and considering my set-up (i.e. no
delay for loading transaction logs), corrupt data may be carried over into
the main standby databaseby means of log shipping (could you please
elaborate
on how/ in which cases this can happen?) . So in order to deal with a
situation, when it's not possible to switch over to the main standby
database, because corrupt data has been carried over into it, I maintain a
lagged auxiliary standby database, which could be restored up to the moment
of corruption and used instead. The question is, how can I determine this
moment? Is it the moment a message about the corrupt primary is logged in
the
SQL Server error log? Can this moment be determined at all? How would you
deal with the situation I described?
Respectfully,
Oskar
|||Thanks Tom. Though by the word "corruption" here I meant the corruption of
SQL Server's internal storage structures (for lack of a better name),
detected by the CHECKDB command, not the application or user negligence.
The question still remains, how can I determine the moment, just before
corruption was loaded into the main standby database, after which all the
remaining transaction log backups are to be discarded?
"Tom Moreau" wrote:
> Very often, the cause is data corruption is the user or administration. For
> example, someone *thought* they were in test but they were in prod and
> deleted or modified data. It's very important to know when the data was
> corrupted because that is the point at which you want to stop restoring your
> log.
> If you copy the log over to your standby server right after it is backed up,
> that's a good thing. Putting a delay of the restoration of the log gives
> you a bit of time to investigate. At the very least, you can restore WITH
> STANDBY to have a look at what the data looked like and then copy that data
> back to the primary.
> --
> Tom
> ----
> Thomas A. Moreau, BSc, PhD, MCSE, MCDBA, MCITP, MCTS
> SQL Server MVP
> Toronto, ON Canada
> https://mvp.support.microsoft.com/profile/Tom.Moreau
>
> "Oskar" <Oskar@.discussions.microsoft.com> wrote in message
> news:B6562D0D-99C4-4291-81DB-A5C67D5DE334@.microsoft.com...
> Hi,
> I've set up two log shipping pairs between three Microsoft SQL Server 2000
> SP3 databases: a primary, a main standby, and an auxiliary standby database.
> For the main standby database jobs that create, copy, and restore
> transaction
> log backups run one after another without any delay. Now if the primary
> database fails it may well be because it has become corrupt. According to
> documentation on the Microsoft website and considering my set-up (i.e. no
> delay for loading transaction logs), corrupt data may be carried over into
> the main standby databaseby means of log shipping (could you please
> elaborate
> on how/ in which cases this can happen?) . So in order to deal with a
> situation, when it's not possible to switch over to the main standby
> database, because corrupt data has been carried over into it, I maintain a
> lagged auxiliary standby database, which could be restored up to the moment
> of corruption and used instead. The question is, how can I determine this
> moment? Is it the moment a message about the corrupt primary is logged in
> the
> SQL Server error log? Can this moment be determined at all? How would you
> deal with the situation I described?
> Respectfully,
> Oskar
>
|||The error log is your best bet - if SQL Server detected the corruption.
Tom
Thomas A. Moreau, BSc, PhD, MCSE, MCDBA, MCITP, MCTS
SQL Server MVP
Toronto, ON Canada
https://mvp.support.microsoft.com/profile/Tom.Moreau
"Oskar" <Oskar@.discussions.microsoft.com> wrote in message
news:16E74120-24C8-4C6E-B937-61A32EB727CA@.microsoft.com...
Thanks Tom. Though by the word "corruption" here I meant the corruption of
SQL Server's internal storage structures (for lack of a better name),
detected by the CHECKDB command, not the application or user negligence.
The question still remains, how can I determine the moment, just before
corruption was loaded into the main standby database, after which all the
remaining transaction log backups are to be discarded?
"Tom Moreau" wrote:
> Very often, the cause is data corruption is the user or administration.
> For
> example, someone *thought* they were in test but they were in prod and
> deleted or modified data. It's very important to know when the data was
> corrupted because that is the point at which you want to stop restoring
> your
> log.
> If you copy the log over to your standby server right after it is backed
> up,
> that's a good thing. Putting a delay of the restoration of the log gives
> you a bit of time to investigate. At the very least, you can restore WITH
> STANDBY to have a look at what the data looked like and then copy that
> data
> back to the primary.
> --
> Tom
> ----
> Thomas A. Moreau, BSc, PhD, MCSE, MCDBA, MCITP, MCTS
> SQL Server MVP
> Toronto, ON Canada
> https://mvp.support.microsoft.com/profile/Tom.Moreau
>
> "Oskar" <Oskar@.discussions.microsoft.com> wrote in message
> news:B6562D0D-99C4-4291-81DB-A5C67D5DE334@.microsoft.com...
> Hi,
> I've set up two log shipping pairs between three Microsoft SQL Server 2000
> SP3 databases: a primary, a main standby, and an auxiliary standby
> database.
> For the main standby database jobs that create, copy, and restore
> transaction
> log backups run one after another without any delay. Now if the primary
> database fails it may well be because it has become corrupt. According to
> documentation on the Microsoft website and considering my set-up (i.e. no
> delay for loading transaction logs), corrupt data may be carried over into
> the main standby databaseby means of log shipping (could you please
> elaborate
> on how/ in which cases this can happen?) . So in order to deal with a
> situation, when it's not possible to switch over to the main standby
> database, because corrupt data has been carried over into it, I maintain a
> lagged auxiliary standby database, which could be restored up to the
> moment
> of corruption and used instead. The question is, how can I determine this
> moment? Is it the moment a message about the corrupt primary is logged in
> the
> SQL Server error log? Can this moment be determined at all? How would you
> deal with the situation I described?
> Respectfully,
> Oskar
>
|||Apparently the problem with this is that the error message may be logged only
some time after the corruption. How long does it take to log the message
after the corruption has taken place?
"Tom Moreau" wrote:
> The error log is your best bet - if SQL Server detected the corruption.
> --
> Tom
> ----
> Thomas A. Moreau, BSc, PhD, MCSE, MCDBA, MCITP, MCTS
> SQL Server MVP
> Toronto, ON Canada
> https://mvp.support.microsoft.com/profile/Tom.Moreau
>
> "Oskar" <Oskar@.discussions.microsoft.com> wrote in message
> news:16E74120-24C8-4C6E-B937-61A32EB727CA@.microsoft.com...
> Thanks Tom. Though by the word "corruption" here I meant the corruption of
> SQL Server's internal storage structures (for lack of a better name),
> detected by the CHECKDB command, not the application or user negligence.
> The question still remains, how can I determine the moment, just before
> corruption was loaded into the main standby database, after which all the
> remaining transaction log backups are to be discarded?
>
> "Tom Moreau" wrote:
>
>
|||That depends. If SQL Server notices it, it goes into the log right away.
However, I have seen situations where it does not notice it and you find out
the hard way.
Tom
Thomas A. Moreau, BSc, PhD, MCSE, MCDBA, MCITP, MCTS
SQL Server MVP
Toronto, ON Canada
https://mvp.support.microsoft.com/profile/Tom.Moreau
"Oskar" <Oskar@.discussions.microsoft.com> wrote in message
news:F4DDD609-5D12-4E92-A6A9-6A437EE5C746@.microsoft.com...
Apparently the problem with this is that the error message may be logged
only
some time after the corruption. How long does it take to log the message
after the corruption has taken place?
"Tom Moreau" wrote:
> The error log is your best bet - if SQL Server detected the corruption.
> --
> Tom
> ----
> Thomas A. Moreau, BSc, PhD, MCSE, MCDBA, MCITP, MCTS
> SQL Server MVP
> Toronto, ON Canada
> https://mvp.support.microsoft.com/profile/Tom.Moreau
>
> "Oskar" <Oskar@.discussions.microsoft.com> wrote in message
> news:16E74120-24C8-4C6E-B937-61A32EB727CA@.microsoft.com...
> Thanks Tom. Though by the word "corruption" here I meant the corruption of
> SQL Server's internal storage structures (for lack of a better name),
> detected by the CHECKDB command, not the application or user negligence.
> The question still remains, how can I determine the moment, just before
> corruption was loaded into the main standby database, after which all the
> remaining transaction log backups are to be discarded?
>
> "Tom Moreau" wrote:
>
>
Monday, February 20, 2012
Log Shipping (can't "auto_fix" user after db restore)
Anyone,
I've implmented log shipping and it's working fine for the most part, but
since it's in a "read only" state,
I can't run a sp_change_users_login to remap my reports_readonly user to the
login on the secondary server.
Thus, this user can not access the read only database at all.
Anyone else seen this, or have a fix for it.
Thank you,
Wayne
Note the SID of that user in sysusers table within that database.
After that, drop the login and recreate it using sp_addlogin and the most
important being to use the SID noted from the sysusers table above
Look at sp_addlogin in Books Online along with @.sid parameter.. Good luck
!!!
"Wayne" <wgadberry@.comcast.net> wrote in message
news:%23x$ixsqbEHA.368@.TK2MSFTNGP10.phx.gbl...
> Anyone,
> I've implmented log shipping and it's working fine for the most part, but
> since it's in a "read only" state,
> I can't run a sp_change_users_login to remap my reports_readonly user to
the
> login on the secondary server.
> Thus, this user can not access the read only database at all.
> Anyone else seen this, or have a fix for it.
> Thank you,
> Wayne
>
|||i'll give it a shot... thanks..
Wayne
"Hassan" <fatima_ja@.hotmail.com> wrote in message
news:ekyMEmubEHA.3636@.TK2MSFTNGP10.phx.gbl...[vbcol=seagreen]
> Note the SID of that user in sysusers table within that database.
> After that, drop the login and recreate it using sp_addlogin and the most
> important being to use the SID noted from the sysusers table above
> Look at sp_addlogin in Books Online along with @.sid parameter.. Good luck
> !!!
>
> "Wayne" <wgadberry@.comcast.net> wrote in message
> news:%23x$ixsqbEHA.368@.TK2MSFTNGP10.phx.gbl...
but
> the
>
|||Worked like a champ Hassan.. you the man..
Wayne
"Wayne" <wgadberry@.comcast.net> wrote in message
news:%23wqQ3RzbEHA.2816@.TK2MSFTNGP11.phx.gbl...[vbcol=seagreen]
> i'll give it a shot... thanks..
> Wayne
> "Hassan" <fatima_ja@.hotmail.com> wrote in message
> news:ekyMEmubEHA.3636@.TK2MSFTNGP10.phx.gbl...
most[vbcol=seagreen]
luck[vbcol=seagreen]
> but
to
>
I've implmented log shipping and it's working fine for the most part, but
since it's in a "read only" state,
I can't run a sp_change_users_login to remap my reports_readonly user to the
login on the secondary server.
Thus, this user can not access the read only database at all.
Anyone else seen this, or have a fix for it.
Thank you,
Wayne
Note the SID of that user in sysusers table within that database.
After that, drop the login and recreate it using sp_addlogin and the most
important being to use the SID noted from the sysusers table above
Look at sp_addlogin in Books Online along with @.sid parameter.. Good luck
!!!
"Wayne" <wgadberry@.comcast.net> wrote in message
news:%23x$ixsqbEHA.368@.TK2MSFTNGP10.phx.gbl...
> Anyone,
> I've implmented log shipping and it's working fine for the most part, but
> since it's in a "read only" state,
> I can't run a sp_change_users_login to remap my reports_readonly user to
the
> login on the secondary server.
> Thus, this user can not access the read only database at all.
> Anyone else seen this, or have a fix for it.
> Thank you,
> Wayne
>
|||i'll give it a shot... thanks..
Wayne
"Hassan" <fatima_ja@.hotmail.com> wrote in message
news:ekyMEmubEHA.3636@.TK2MSFTNGP10.phx.gbl...[vbcol=seagreen]
> Note the SID of that user in sysusers table within that database.
> After that, drop the login and recreate it using sp_addlogin and the most
> important being to use the SID noted from the sysusers table above
> Look at sp_addlogin in Books Online along with @.sid parameter.. Good luck
> !!!
>
> "Wayne" <wgadberry@.comcast.net> wrote in message
> news:%23x$ixsqbEHA.368@.TK2MSFTNGP10.phx.gbl...
but
> the
>
|||Worked like a champ Hassan.. you the man..
Wayne
"Wayne" <wgadberry@.comcast.net> wrote in message
news:%23wqQ3RzbEHA.2816@.TK2MSFTNGP11.phx.gbl...[vbcol=seagreen]
> i'll give it a shot... thanks..
> Wayne
> "Hassan" <fatima_ja@.hotmail.com> wrote in message
> news:ekyMEmubEHA.3636@.TK2MSFTNGP10.phx.gbl...
most[vbcol=seagreen]
luck[vbcol=seagreen]
> but
to
>
Log Shipping - Resend of Log Files from Primary
I've had a problem with my secondary server where I suspect that a log file
may have been corrupted in-transit and what to re-send again via the
logshipcopy jobs.
I took last nights backup and restored to the secondary and now just want to
"catch-Up" the trans logs to get current.
What is the process to get logshipping to re-send logfiles it has already
sent as part of the maintenance plan jobs?
thks
What process do you use for copying\shipping log? Is it rsynch?
"Tom Frost" wrote:
> I've had a problem with my secondary server where I suspect that a log file
> may have been corrupted in-transit and what to re-send again via the
> logshipcopy jobs.
> I took last nights backup and restored to the secondary and now just want to
> "catch-Up" the trans logs to get current.
> What is the process to get logshipping to re-send logfiles it has already
> sent as part of the maintenance plan jobs?
> thks
|||Built In LogShipping Scripts that come with SQL Server 2000 Enterprise
Edition...
"bluefish" wrote:
[vbcol=seagreen]
> What process do you use for copying\shipping log? Is it rsynch?
> "Tom Frost" wrote:
|||Hi Tom,
One of the scripts should have the copy logs from source to destination
command. ( We have log shipping scripts that we have customized, so I am not
sure which one off hand) . You can look at them, and rerun one of them in QA.
Code may be looking to see if the backup are already copied, so you will have
to look at that, and change the code in a little bit to get the backup set
you are looking for.
"Tom Frost" wrote:
[vbcol=seagreen]
> Built In LogShipping Scripts that come with SQL Server 2000 Enterprise
> Edition...
> "bluefish" wrote:
may have been corrupted in-transit and what to re-send again via the
logshipcopy jobs.
I took last nights backup and restored to the secondary and now just want to
"catch-Up" the trans logs to get current.
What is the process to get logshipping to re-send logfiles it has already
sent as part of the maintenance plan jobs?
thks
What process do you use for copying\shipping log? Is it rsynch?
"Tom Frost" wrote:
> I've had a problem with my secondary server where I suspect that a log file
> may have been corrupted in-transit and what to re-send again via the
> logshipcopy jobs.
> I took last nights backup and restored to the secondary and now just want to
> "catch-Up" the trans logs to get current.
> What is the process to get logshipping to re-send logfiles it has already
> sent as part of the maintenance plan jobs?
> thks
|||Built In LogShipping Scripts that come with SQL Server 2000 Enterprise
Edition...
"bluefish" wrote:
[vbcol=seagreen]
> What process do you use for copying\shipping log? Is it rsynch?
> "Tom Frost" wrote:
|||Hi Tom,
One of the scripts should have the copy logs from source to destination
command. ( We have log shipping scripts that we have customized, so I am not
sure which one off hand) . You can look at them, and rerun one of them in QA.
Code may be looking to see if the backup are already copied, so you will have
to look at that, and change the code in a little bit to get the backup set
you are looking for.
"Tom Frost" wrote:
[vbcol=seagreen]
> Built In LogShipping Scripts that come with SQL Server 2000 Enterprise
> Edition...
> "bluefish" wrote:
Subscribe to:
Comments (Atom)