We've been experiencing above average "Log Shipping
Restore" fails. All copy and restore can be worked for
first two or three times. For no apparent reason, the job
of log shipping restore fails. I checked the windows event
viewer,the message is "SQL Server Scheduled Job 'Log
Shipping Restore for Test2.NorthwindCopy_logshipping'
(0x63382D0A9860D541B191C36DCB658480) - Status: Failed -
Invoked on: 2003-10-31 12:30:00 - Message: The job
failed. The Job was invoked by Schedule 12 (Schedule 1).
The last step to run was step 1 (Log Shipping Restore)."
I'm sure that disk space and netowkr access isn't an issue
and the secondary server isn't busy.Anyone knows what
might cause this .Thanks.Are users accessing the database at the time of failure?
Can you run the restore command yourself? Does it work?
You can get more information regarding log shipping here:
http://sqlguy.home.comcast.net/logship.htm
-- Keith
"kelly" <kelly_lu@.kingston.com.tw> wrote in message =news:45bd01c39f73$9f9f2b90$7d02280a@.phx.gbl...
> We've been experiencing above average "Log Shipping > Restore" fails. All copy and restore can be worked for > first two or three times. For no apparent reason, the job > of log shipping restore fails. I checked the windows event > viewer,the message is "SQL Server Scheduled Job 'Log > Shipping Restore for Test2.NorthwindCopy_logshipping' > (0x63382D0A9860D541B191C36DCB658480) - Status: Failed - > Invoked on: 2003-10-31 12:30:00 - Message: The job > failed. The Job was invoked by Schedule 12 (Schedule 1). > The last step to run was step 1 (Log Shipping Restore)."
> I'm sure that disk space and netowkr access isn't an issue > and the secondary server isn't busy.Anyone knows what > might cause this .Thanks. >
Showing posts with label fails. Show all posts
Showing posts with label fails. Show all posts
Monday, March 26, 2012
Wednesday, March 21, 2012
Log Shipping Plan fails (event: 208)
Hi,
We've been using logshipping successfully for over a year,
but recently we are experiencing more and more failures
relating to the Transaction Log Backup Job. We are
currently log shipping 30 databases from a W2K(SP4)
SQL2000(SP3) server to a W2K3 Server (SQL2000SP3).
The backup jobs aren't consistently failing, which is
making this harder to diagnose. If I manually run the jobs
from Enterprise Manager they work fine, and the only error
messages that i'm seeing are like the following:
EventID: 208
SQL Server Scheduled Job 'Transaction Log Backup Job for DB
Maintenance Plan 'Unity_Server1 Log Shipping''
(0x318A0055279BA840AABD24DA1BA5B440) - Status: Failed -
Invoked on: 2004-09-20 17:15:10 - Message: The job failed.
The Job was invoked by Schedule 59 (Schedule 1). The last
step to run was step 1 (Step 1).
There aren't any issues with disk space, and I don't think
this is a security issue, as the jobs aren't consistently
failing.
Hoping that someone has come across this issue before.
Thanks,
Martin
Martin,
I'm not too sure where this message originates from, but if it is the job,
then in the maintenance plan can you enable logging to the textfile and then
examine the resulting messages. I often just receive sqlmaint.exe failed
messages in the job, but in the textfile find out the real cause of the
problem.
Regards,
Paul Ibison
(recommended sql server 2000 replication book:
http://www.nwsu.com/0974973602p.html)
|||Paul Ibison wrote:
> Martin,
> I'm not too sure where this message originates from, but if it is the job,
> then in the maintenance plan can you enable logging to the textfile and then
> examine the resulting messages.
This is interesting - when I examine the folder containing the
log-shipping logs - whenever a job fails there is no log created.
However, successful log-shipping jobs do create a log file. So not only
is the job failing to complete, but it's also failing to create a log of
the failure.
Looking at the job history shows a complete list of all the log-shipping
jobs with corresponding results (failed or successful).
Thanks
Martin
|||Martin,
in that case you could use profiler. Some things are
incompatible with backups - eg file management operations
such as the ALTER DATABASE statement with either the ADD
FILE or REMOVE FILE options; shrink database or shrink
file - this includes autoshrink operations.
HTH,
Paul Ibison
(recommended sql server 2000 replication book:
http://www.nwsu.com/0974973602p.html)
sql
We've been using logshipping successfully for over a year,
but recently we are experiencing more and more failures
relating to the Transaction Log Backup Job. We are
currently log shipping 30 databases from a W2K(SP4)
SQL2000(SP3) server to a W2K3 Server (SQL2000SP3).
The backup jobs aren't consistently failing, which is
making this harder to diagnose. If I manually run the jobs
from Enterprise Manager they work fine, and the only error
messages that i'm seeing are like the following:
EventID: 208
SQL Server Scheduled Job 'Transaction Log Backup Job for DB
Maintenance Plan 'Unity_Server1 Log Shipping''
(0x318A0055279BA840AABD24DA1BA5B440) - Status: Failed -
Invoked on: 2004-09-20 17:15:10 - Message: The job failed.
The Job was invoked by Schedule 59 (Schedule 1). The last
step to run was step 1 (Step 1).
There aren't any issues with disk space, and I don't think
this is a security issue, as the jobs aren't consistently
failing.
Hoping that someone has come across this issue before.
Thanks,
Martin
Martin,
I'm not too sure where this message originates from, but if it is the job,
then in the maintenance plan can you enable logging to the textfile and then
examine the resulting messages. I often just receive sqlmaint.exe failed
messages in the job, but in the textfile find out the real cause of the
problem.
Regards,
Paul Ibison
(recommended sql server 2000 replication book:
http://www.nwsu.com/0974973602p.html)
|||Paul Ibison wrote:
> Martin,
> I'm not too sure where this message originates from, but if it is the job,
> then in the maintenance plan can you enable logging to the textfile and then
> examine the resulting messages.
This is interesting - when I examine the folder containing the
log-shipping logs - whenever a job fails there is no log created.
However, successful log-shipping jobs do create a log file. So not only
is the job failing to complete, but it's also failing to create a log of
the failure.
Looking at the job history shows a complete list of all the log-shipping
jobs with corresponding results (failed or successful).
Thanks
Martin
|||Martin,
in that case you could use profiler. Some things are
incompatible with backups - eg file management operations
such as the ALTER DATABASE statement with either the ADD
FILE or REMOVE FILE options; shrink database or shrink
file - this includes autoshrink operations.
HTH,
Paul Ibison
(recommended sql server 2000 replication book:
http://www.nwsu.com/0974973602p.html)
sql
Monday, March 19, 2012
Log Shipping Issue
I have log shipping setup b/t 2 servers and everything is working fine except for one thing. The T-Log Restore to the Standby server fails everytime. Everyone has full permissions to it and I am using the Network Admin account to transfer and restore. Has anyone had any similar issues and might have any solutions? Thank you.What error do you receive?
For log shipping to work properly you have to first restore the database =WITH STANDBY
You then restore your logs
The (destination) database cannot be in use when the log is applied.
Refer to http://sqlguy.home.comcast.net/logship.htm for more =information.
-- Keith
"Don" <donolwert@.hotmail.com> wrote in message =news:5A8317ED-4B10-41B5-981E-A35F6008C319@.microsoft.com...
> I have log shipping setup b/t 2 servers and everything is working fine =except for one thing. The T-Log Restore to the Standby server fails =everytime. Everyone has full permissions to it and I am using the =Network Admin account to transfer and restore. Has anyone had any =similar issues and might have any solutions? Thank you.|||Thanks for responding. There error message I am getting is as follows
Executed as user: FS-SA\fssaadmin. sqlmaint.exe failed. [SQLSTATE 42000] (Error 22029). The step failed
I verified and made sure I restored the DB in Standby mode as well. Permissions should be fine as the user fssaadmin is our Domain Admins account
I also switched the Database to Single-User mode and then ran the restore job but am still getting the error. Thanks for any help
Do
-- Keith Kratochvil wrote: --
What error do you receive
For log shipping to work properly you have to first restore the database WITH STANDB
You then restore your log
The (destination) database cannot be in use when the log is applied
Refer to http://sqlguy.home.comcast.net/logship.htm for more information
--
Keit
"Don" <donolwert@.hotmail.com> wrote in message news:5A8317ED-4B10-41B5-981E-A35F6008C319@.microsoft.com..
> I have log shipping setup b/t 2 servers and everything is working fine except for one thing. The T-Log Restore to the Standby server fails everytime. Everyone has full permissions to it and I am using the Network Admin account to transfer and restore. Has anyone had any similar issues and might have any solutions? Thank you|||Can you run the appropriate T-SQL (restore database and restore log) =commands within Query Analyzer on the target server when connected as =sa? Does it work?
You may find some helpful infomation within Tibor Karaszi's post:
http://groups.google.com/groups?hl=3Den&lr=3D&ie=3DUTF-8&oe=3DUTF-8&threa=
dm=3D08ea01c18440%249e9828f0%2439ef2ecf%40TKMSFTNGXA08&rnum=3D1&prev=3D/g=roups%3Fhl%3Den%26lr%3D%26ie%3DUTF-8%26oe%3DUTF-8%26q%3DError%2B22029%26b=tnG%3DGoogle%2BSearch%26meta%3Dgroup%253Dmicrosoft.public.sqlserver.*
or
http://tinyurl.com/3f4e4
-- Keith
"Don" <donolwert@.hotmail.com> wrote in message =news:6DF3AC39-C30A-4DBA-9438-C2CA32758BB7@.microsoft.com...
> Thanks for responding. There error message I am getting is as =follows:
> > Executed as user: FS-SA\fssaadmin. sqlmaint.exe failed. =[SQLSTATE 42000] (Error 22029). The step failed.
> > I verified and made sure I restored the DB in Standby mode as well. =Permissions should be fine as the user fssaadmin is our Domain Admins =account.
> > I also switched the Database to Single-User mode and then ran the =restore job but am still getting the error. Thanks for any help.
> > Don
> > > -- Keith Kratochvil wrote: --
> > What error do you receive?
> > For log shipping to work properly you have to first restore the =database WITH STANDBY
> > You then restore your logs
> > The (destination) database cannot be in use when the log is =applied.
> Refer to http://sqlguy.home.comcast.net/logship.htm for more =information.
> > -- > Keith
> > > "Don" <donolwert@.hotmail.com> wrote in message =news:5A8317ED-4B10-41B5-981E-A35F6008C319@.microsoft.com...
> > I have log shipping setup b/t 2 servers and everything is =working fine except for one thing. The T-Log Restore to the Standby =server fails everytime. Everyone has full permissions to it and I am =using the Network Admin account to transfer and restore. Has anyone had =any similar issues and might have any solutions? Thank you.
>|||Keith, Thank you for all your help. I discovered what the issue is...McAfee. I uninstalled McAfee and everything ran perfectly. Thank you.
-- Keith Kratochvil wrote: --
Can you run the appropriate T-SQL (restore database and restore log) commands within Query Analyzer on the target server when connected as sa? Does it work?
You may find some helpful infomation within Tibor Karaszi's post:
http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&oe=UTF-8&threadm=08ea01c18440%249e9828f0%2439ef2ecf%40TKMSFTNGXA08&rnum=1&prev=/groups%3Fhl%3Den%26lr%3D%26ie%3DUTF-8%26oe%3DUTF-8%26q%3DError%2B22029%26btnG%3DGoogle%2BSearch%26meta%3Dgroup%253Dmicrosoft.public.sqlserver.*
or
http://tinyurl.com/3f4e4
--
Keith
"Don" <donolwert@.hotmail.com> wrote in message news:6DF3AC39-C30A-4DBA-9438-C2CA32758BB7@.microsoft.com...
> Thanks for responding. There error message I am getting is as follows:
>> Executed as user: FS-SA\fssaadmin. sqlmaint.exe failed. [SQLSTATE 42000] (Error 22029). The step failed.
>> I verified and made sure I restored the DB in Standby mode as well. Permissions should be fine as the user fssaadmin is our Domain Admins account.
>> I also switched the Database to Single-User mode and then ran the restore job but am still getting the error. Thanks for any help.
>> Don
>> -- Keith Kratochvil wrote: --
>> What error do you receive?
>> For log shipping to work properly you have to first restore the database WITH STANDBY
>> You then restore your logs
>> The (destination) database cannot be in use when the log is applied.
> Refer to http://sqlguy.home.comcast.net/logship.htm for more information.
>> --
> Keith
>> "Don" <donolwert@.hotmail.com> wrote in message news:5A8317ED-4B10-41B5-981E-A35F6008C319@.microsoft.com...
>> I have log shipping setup b/t 2 servers and everything is working fine except for one thing. The T-Log Restore to the Standby server fails everytime. Everyone has full permissions to it and I am using the Network Admin account to transfer and restore. Has anyone had any similar issues and might have any solutions? Thank you.
>
For log shipping to work properly you have to first restore the database =WITH STANDBY
You then restore your logs
The (destination) database cannot be in use when the log is applied.
Refer to http://sqlguy.home.comcast.net/logship.htm for more =information.
-- Keith
"Don" <donolwert@.hotmail.com> wrote in message =news:5A8317ED-4B10-41B5-981E-A35F6008C319@.microsoft.com...
> I have log shipping setup b/t 2 servers and everything is working fine =except for one thing. The T-Log Restore to the Standby server fails =everytime. Everyone has full permissions to it and I am using the =Network Admin account to transfer and restore. Has anyone had any =similar issues and might have any solutions? Thank you.|||Thanks for responding. There error message I am getting is as follows
Executed as user: FS-SA\fssaadmin. sqlmaint.exe failed. [SQLSTATE 42000] (Error 22029). The step failed
I verified and made sure I restored the DB in Standby mode as well. Permissions should be fine as the user fssaadmin is our Domain Admins account
I also switched the Database to Single-User mode and then ran the restore job but am still getting the error. Thanks for any help
Do
-- Keith Kratochvil wrote: --
What error do you receive
For log shipping to work properly you have to first restore the database WITH STANDB
You then restore your log
The (destination) database cannot be in use when the log is applied
Refer to http://sqlguy.home.comcast.net/logship.htm for more information
--
Keit
"Don" <donolwert@.hotmail.com> wrote in message news:5A8317ED-4B10-41B5-981E-A35F6008C319@.microsoft.com..
> I have log shipping setup b/t 2 servers and everything is working fine except for one thing. The T-Log Restore to the Standby server fails everytime. Everyone has full permissions to it and I am using the Network Admin account to transfer and restore. Has anyone had any similar issues and might have any solutions? Thank you|||Can you run the appropriate T-SQL (restore database and restore log) =commands within Query Analyzer on the target server when connected as =sa? Does it work?
You may find some helpful infomation within Tibor Karaszi's post:
http://groups.google.com/groups?hl=3Den&lr=3D&ie=3DUTF-8&oe=3DUTF-8&threa=
dm=3D08ea01c18440%249e9828f0%2439ef2ecf%40TKMSFTNGXA08&rnum=3D1&prev=3D/g=roups%3Fhl%3Den%26lr%3D%26ie%3DUTF-8%26oe%3DUTF-8%26q%3DError%2B22029%26b=tnG%3DGoogle%2BSearch%26meta%3Dgroup%253Dmicrosoft.public.sqlserver.*
or
http://tinyurl.com/3f4e4
-- Keith
"Don" <donolwert@.hotmail.com> wrote in message =news:6DF3AC39-C30A-4DBA-9438-C2CA32758BB7@.microsoft.com...
> Thanks for responding. There error message I am getting is as =follows:
> > Executed as user: FS-SA\fssaadmin. sqlmaint.exe failed. =[SQLSTATE 42000] (Error 22029). The step failed.
> > I verified and made sure I restored the DB in Standby mode as well. =Permissions should be fine as the user fssaadmin is our Domain Admins =account.
> > I also switched the Database to Single-User mode and then ran the =restore job but am still getting the error. Thanks for any help.
> > Don
> > > -- Keith Kratochvil wrote: --
> > What error do you receive?
> > For log shipping to work properly you have to first restore the =database WITH STANDBY
> > You then restore your logs
> > The (destination) database cannot be in use when the log is =applied.
> Refer to http://sqlguy.home.comcast.net/logship.htm for more =information.
> > -- > Keith
> > > "Don" <donolwert@.hotmail.com> wrote in message =news:5A8317ED-4B10-41B5-981E-A35F6008C319@.microsoft.com...
> > I have log shipping setup b/t 2 servers and everything is =working fine except for one thing. The T-Log Restore to the Standby =server fails everytime. Everyone has full permissions to it and I am =using the Network Admin account to transfer and restore. Has anyone had =any similar issues and might have any solutions? Thank you.
>|||Keith, Thank you for all your help. I discovered what the issue is...McAfee. I uninstalled McAfee and everything ran perfectly. Thank you.
-- Keith Kratochvil wrote: --
Can you run the appropriate T-SQL (restore database and restore log) commands within Query Analyzer on the target server when connected as sa? Does it work?
You may find some helpful infomation within Tibor Karaszi's post:
http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&oe=UTF-8&threadm=08ea01c18440%249e9828f0%2439ef2ecf%40TKMSFTNGXA08&rnum=1&prev=/groups%3Fhl%3Den%26lr%3D%26ie%3DUTF-8%26oe%3DUTF-8%26q%3DError%2B22029%26btnG%3DGoogle%2BSearch%26meta%3Dgroup%253Dmicrosoft.public.sqlserver.*
or
http://tinyurl.com/3f4e4
--
Keith
"Don" <donolwert@.hotmail.com> wrote in message news:6DF3AC39-C30A-4DBA-9438-C2CA32758BB7@.microsoft.com...
> Thanks for responding. There error message I am getting is as follows:
>> Executed as user: FS-SA\fssaadmin. sqlmaint.exe failed. [SQLSTATE 42000] (Error 22029). The step failed.
>> I verified and made sure I restored the DB in Standby mode as well. Permissions should be fine as the user fssaadmin is our Domain Admins account.
>> I also switched the Database to Single-User mode and then ran the restore job but am still getting the error. Thanks for any help.
>> Don
>> -- Keith Kratochvil wrote: --
>> What error do you receive?
>> For log shipping to work properly you have to first restore the database WITH STANDBY
>> You then restore your logs
>> The (destination) database cannot be in use when the log is applied.
> Refer to http://sqlguy.home.comcast.net/logship.htm for more information.
>> --
> Keith
>> "Don" <donolwert@.hotmail.com> wrote in message news:5A8317ED-4B10-41B5-981E-A35F6008C319@.microsoft.com...
>> I have log shipping setup b/t 2 servers and everything is working fine except for one thing. The T-Log Restore to the Standby server fails everytime. Everyone has full permissions to it and I am using the Network Admin account to transfer and restore. Has anyone had any similar issues and might have any solutions? Thank you.
>
Log Shipping Issue
I have log shipping setup b/t 2 servers and everything is working fine excep
t for one thing. The T-Log Restore to the Standby server fails everytime.
Everyone has full permissions to it and I am using the Network Admin account
to transfer and restore.
Has anyone had any similar issues and might have any solutions? Thank you.What error do you receive?
For log shipping to work properly you have to first restore the database =
WITH STANDBY
You then restore your logs
The (destination) database cannot be in use when the log is applied.
Refer to http://sqlguy.home.comcast.net/logship.htm for more =
information.
--=20
Keith
"Don" <donolwert@.hotmail.com> wrote in message =
news:5A8317ED-4B10-41B5-981E-A35F6008C319@.microsoft.com...
except for one thing. The T-Log Restore to the Standby server fails =
everytime. Everyone has full permissions to it and I am using the =
Network Admin account to transfer and restore. Has anyone had any =
similar issues and might have any solutions? Thank you.|||Thanks for responding. There error message I am getting is as follows:
Executed as user: FS-SA\fssaadmin. sqlmaint.exe failed. [SQLSTATE 42000] (Er
ror 22029). The step failed.
I verified and made sure I restored the DB in Standby mode as well. Permiss
ions should be fine as the user fssaadmin is our Domain Admins account.
I also switched the Database to Single-User mode and then ran the restore jo
b but am still getting the error. Thanks for any help.
Don
-- Keith Kratochvil wrote: --
What error do you receive?
For log shipping to work properly you have to first restore the database WIT
H STANDBY
You then restore your logs
The (destination) database cannot be in use when the log is applied.
Refer to http://sqlguy.home.comcast.net/logship.htm for more information.
Keith
"Don" <donolwert@.hotmail.com> wrote in message news:5A8317ED-4B10-41B5-981E-A35F6008C319@.microsoft
.com...
tore. Has anyone had any similar issues and might have any solutions? Than
k you.|||Can you run the appropriate T-SQL (restore database and restore log) =
commands within Query Analyzer on the target server when connected as =
sa? Does it work?
You may find some helpful infomation within Tibor Karaszi's post:
http://groups.google.com/groups?hl=...=3DUTF-8&threa=
dm=3D08ea01c18440%249e9828f0%2439ef2ecf%
40TKMSFTNGXA08&rnum=3D1&prev=3D/g=
roups%3Fhl%3Den%26lr%3D%26ie%3DUTF-8%26oe%3DUTF-8%26q%3DError%2B22029%26b=
tnG%3DGoogle%2BSearch%26meta%3Dgroup%253
Dmicrosoft.public.sqlserver.*
or
http://tinyurl.com/3f4e4
--=20
Keith
"Don" <donolwert@.hotmail.com> wrote in message =
news:6DF3AC39-C30A-4DBA-9438-C2CA32758BB7@.microsoft.com...
follows:
[SQLSTATE 42000] (Error 22029). The step failed.
Permissions should be fine as the user fssaadmin is our Domain Admins =
account.
restore job but am still getting the error. Thanks for any help.
database WITH STANDBY
applied.
information.
news:5A8317ED-4B10-41B5-981E-A35F6008C319@.microsoft.com...
. I uninstalled McAfee and everything ran perfectly. Thank you.
-- Keith Kratochvil wrote: --
Can you run the appropriate T-SQL (restore database and restore log) command
s within Query Analyzer on the target server when connected as sa? Does it
work?
You may find some helpful infomation within Tibor Karaszi's post:
http://groups.google.com/groups?hl=...53D
micr
osoft.public.sqlserver.*
or
http://tinyurl.com/3f4e4
Keith
"Don" <donolwert@.hotmail.com> wrote in message news:6DF3AC39-C30A-4DBA-9438-C2CA32758BB7@.microsoft
.com...
t for one thing. The T-Log Restore to the Standby server fails everytime.
Everyone has full permissions to it and I am using the Network Admin account
to transfer and restore.
Has anyone had any similar issues and might have any solutions? Thank you.What error do you receive?
For log shipping to work properly you have to first restore the database =
WITH STANDBY
You then restore your logs
The (destination) database cannot be in use when the log is applied.
Refer to http://sqlguy.home.comcast.net/logship.htm for more =
information.
--=20
Keith
"Don" <donolwert@.hotmail.com> wrote in message =
news:5A8317ED-4B10-41B5-981E-A35F6008C319@.microsoft.com...
quote:
> I have log shipping setup b/t 2 servers and everything is working fine =
except for one thing. The T-Log Restore to the Standby server fails =
everytime. Everyone has full permissions to it and I am using the =
Network Admin account to transfer and restore. Has anyone had any =
similar issues and might have any solutions? Thank you.|||Thanks for responding. There error message I am getting is as follows:
Executed as user: FS-SA\fssaadmin. sqlmaint.exe failed. [SQLSTATE 42000] (Er
ror 22029). The step failed.
I verified and made sure I restored the DB in Standby mode as well. Permiss
ions should be fine as the user fssaadmin is our Domain Admins account.
I also switched the Database to Single-User mode and then ran the restore jo
b but am still getting the error. Thanks for any help.
Don
-- Keith Kratochvil wrote: --
What error do you receive?
For log shipping to work properly you have to first restore the database WIT
H STANDBY
You then restore your logs
The (destination) database cannot be in use when the log is applied.
Refer to http://sqlguy.home.comcast.net/logship.htm for more information.
Keith
"Don" <donolwert@.hotmail.com> wrote in message news:5A8317ED-4B10-41B5-981E-A35F6008C319@.microsoft
.com...
quote:
> I have log shipping setup b/t 2 servers and everything is working fine except for one thin
g. The T-Log Restore to the Standby server fails everytime. Everyone has full permissions
to it and I am using the Network Admin account to transfer and res
tore. Has anyone had any similar issues and might have any solutions? Than
k you.|||Can you run the appropriate T-SQL (restore database and restore log) =
commands within Query Analyzer on the target server when connected as =
sa? Does it work?
You may find some helpful infomation within Tibor Karaszi's post:
http://groups.google.com/groups?hl=...=3DUTF-8&threa=
dm=3D08ea01c18440%249e9828f0%2439ef2ecf%
40TKMSFTNGXA08&rnum=3D1&prev=3D/g=
roups%3Fhl%3Den%26lr%3D%26ie%3DUTF-8%26oe%3DUTF-8%26q%3DError%2B22029%26b=
tnG%3DGoogle%2BSearch%26meta%3Dgroup%253
Dmicrosoft.public.sqlserver.*
or
http://tinyurl.com/3f4e4
--=20
Keith
"Don" <donolwert@.hotmail.com> wrote in message =
news:6DF3AC39-C30A-4DBA-9438-C2CA32758BB7@.microsoft.com...
quote:
> Thanks for responding. There error message I am getting is as =
follows:
quote:
> =20
> Executed as user: FS-SA\fssaadmin. sqlmaint.exe failed. =
[SQLSTATE 42000] (Error 22029). The step failed.
quote:
>=20
> I verified and made sure I restored the DB in Standby mode as well. =
Permissions should be fine as the user fssaadmin is our Domain Admins =
account.
quote:
>=20
> I also switched the Database to Single-User mode and then ran the =
restore job but am still getting the error. Thanks for any help.
quote:
>=20
> Don
>=20
> =20
> -- Keith Kratochvil wrote: --
> =20
> What error do you receive?
> =20
> For log shipping to work properly you have to first restore the =
database WITH STANDBY
quote:
> =20
> You then restore your logs
> =20
> The (destination) database cannot be in use when the log is =
applied.
quote:
> Refer to http://sqlguy.home.comcast.net/logship.htm for more =
information.
quote:
> =20
> --=20
> Keith
> =20
> =20
> "Don" <donolwert@.hotmail.com> wrote in message =
news:5A8317ED-4B10-41B5-981E-A35F6008C319@.microsoft.com...
quote:|||Keith, Thank you for all your help. I discovered what the issue is...McAfee
working fine except for one thing. The T-Log Restore to the Standby =
server fails everytime. Everyone has full permissions to it and I am =
using the Network Admin account to transfer and restore. Has anyone had =
any similar issues and might have any solutions? Thank you.[QUOTE]
>
. I uninstalled McAfee and everything ran perfectly. Thank you.
-- Keith Kratochvil wrote: --
Can you run the appropriate T-SQL (restore database and restore log) command
s within Query Analyzer on the target server when connected as sa? Does it
work?
You may find some helpful infomation within Tibor Karaszi's post:
http://groups.google.com/groups?hl=...53D
micr
osoft.public.sqlserver.*
or
http://tinyurl.com/3f4e4
Keith
"Don" <donolwert@.hotmail.com> wrote in message news:6DF3AC39-C30A-4DBA-9438-C2CA32758BB7@.microsoft
.com...
quote:
> Thanks for responding. There error message I am getting is as follows:
> Refer to http://sqlguy.home.comcast.net/logship.htm for more informat
ion.
> Keith
store. Has anyone had any similar issues and might have any solutions? Thank you.[QUOTE][color=d
arkred]
>
Monday, March 12, 2012
Log shipping fails the second time.
Log shipping fails the second time to restore 5Gb transactional log backup with the following error.
Error 823: [Microsoft][ODBC SQL Server Driver][SQL Server]I/O error (bad page ID)
detected during read at offset 0x000001f340e000 in file 'e:\program files\microsoft sql server\DBName.mdf'.
There is no hardware problem. The restore failed in a test server on the same step with the same error message.
The DBCC CHECKDB does not give any error message.
What it might be?
My guess is that the transaction log backup is corrupt and is laying down a full-page format log record (which contains a full page image) that has a corrupt page ID. Is the source database clean as far as CHECKDB is concerned?|||
CHECKDB does not give any error. The transactional backup got corrupted after indexes rebuild operation. It does not happen every time. Is there any way to check transactional backup integrity?
|||yes its possible to check the integrity of a backup file.just refer this command......
Restore verifyonly from disk='Full path of your tran log file'.........it will check whether all the pages in the trn file are readable and also if the backup set is complete........
Log shipping fails the second time.
Log shipping fails the second time to restore 5Gb transactional log backup with the following error.
Error 823: [Microsoft][ODBC SQL Server Driver][SQL Server]I/O error (bad page ID)
detected during read at offset 0x000001f340e000 in file 'e:\program files\microsoft sql server\DBName.mdf'.
There is no hardware problem. The restore failed in a test server on the same step with the same error message.
The DBCC CHECKDB does not give any error message.
What it might be?
My guess is that the transaction log backup is corrupt and is laying down a full-page format log record (which contains a full page image) that has a corrupt page ID. Is the source database clean as far as CHECKDB is concerned?|||
CHECKDB does not give any error. The transactional backup got corrupted after indexes rebuild operation. It does not happen every time. Is there any way to check transactional backup integrity?
|||yes its possible to check the integrity of a backup file.just refer this command......
Restore verifyonly from disk='Full path of your tran log file'.........it will check whether all the pages in the trn file are readable and also if the backup set is complete........
Log Shipping Fails Once a Week
Hi
I have log shipping setup on 2 servers - A and B. Both are SQL Server
2000 and the size of the database is 95Gb. The average transaction log
is around 100Mb
A ships to B and B is also the monitoring server.
The schedule is set to ship every 15 minutes.
Everything works fine, however every Sunday at 23:00 without fail the
log ship fails due to the LSN counter being out of sync. The error
reports an ealier backup is available but any attempt to restore fails
and the log ship schedule must be deleted and re-created.
There are no other backups/restores or any other scheduled jobs that
occur at this time.
Does anyone have any suggestions?
Thanks.
What is the exact error message you receive? Please can you post it up for
us...
Cheers,
Paul Ibison
I have log shipping setup on 2 servers - A and B. Both are SQL Server
2000 and the size of the database is 95Gb. The average transaction log
is around 100Mb
A ships to B and B is also the monitoring server.
The schedule is set to ship every 15 minutes.
Everything works fine, however every Sunday at 23:00 without fail the
log ship fails due to the LSN counter being out of sync. The error
reports an ealier backup is available but any attempt to restore fails
and the log ship schedule must be deleted and re-created.
There are no other backups/restores or any other scheduled jobs that
occur at this time.
Does anyone have any suggestions?
Thanks.
What is the exact error message you receive? Please can you post it up for
us...
Cheers,
Paul Ibison
Log Shipping fails after DB Reindex.
Can anyone help.
I have set up log shipping between two SQL 2000 servers, with no issues. A
job runs on the Primary server to reindex the databases. At this point Log
Shipping Fails, the error massage says that the servers are out of sync.
The log file shows the error
The log in this backup set begins at LSN 202000000017000001, which is too
late to apply to the database. An earlier log backup that includes LSN
20200000
0016800001 can be restored.
Is there a way to reindex the database that does not affect log shipping?
Many thanks in advance
Andy McDonald
MCSA
"Andy McDonald" <Andy McDonald@.discussions.microsoft.com> wrote in message
news:7ED44ADD-C2FF-4E2F-B371-CC3180FC8B8A@.microsoft.com...
> Can anyone help.
> I have set up log shipping between two SQL 2000 servers, with no issues. A
> job runs on the Primary server to reindex the databases. At this point Log
> Shipping Fails, the error massage says that the servers are out of sync.
> The log file shows the error
> The log in this backup set begins at LSN 202000000017000001, which is too
> late to apply to the database. An earlier log backup that includes LSN
> 20200000
> 0016800001 can be restored.
> Is there a way to reindex the database that does not affect log shipping?
It sounds more like somehow you're losing a log backup somewhere along the
line.
reindexing doesn't (or at least shouldn't) affect log-shipping (having just
done this lately).
> Many thanks in advance
> Andy McDonald
> MCSA
|||Greg
The data base is a large one, (about 25 GB) dont know if this helps. but we
only receive the error when re-indexing takes place.
Andy McDonald
MCSA
"Greg D. Moore (Strider)" wrote:
> "Andy McDonald" <Andy McDonald@.discussions.microsoft.com> wrote in message
> news:7ED44ADD-C2FF-4E2F-B371-CC3180FC8B8A@.microsoft.com...
> It sounds more like somehow you're losing a log backup somewhere along the
> line.
> reindexing doesn't (or at least shouldn't) affect log-shipping (having just
> done this lately).
>
>
>
|||Are you 100% certain that you don't set the database to simple recovery mode during reindex?
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://www.solidqualitylearning.com/
"Andy McDonald" <AndyMcDonald@.discussions.microsoft.com> wrote in message
news:695642A8-9954-472D-9C90-ECC295BAB791@.microsoft.com...[vbcol=seagreen]
> Greg
> The data base is a large one, (about 25 GB) dont know if this helps. but we
> only receive the error when re-indexing takes place.
> Andy McDonald
> MCSA
> "Greg D. Moore (Strider)" wrote:
|||Hello
Yes I am sure.
"Tibor Karaszi" wrote:
> Are you 100% certain that you don't set the database to simple recovery mode during reindex?
> --
> Tibor Karaszi, SQL Server MVP
> http://www.karaszi.com/sqlserver/default.asp
> http://www.solidqualitylearning.com/
>
> "Andy McDonald" <AndyMcDonald@.discussions.microsoft.com> wrote in message
> news:695642A8-9954-472D-9C90-ECC295BAB791@.microsoft.com...
>
>
|||"Andy McDonald" <AndyMcDonald@.discussions.microsoft.com> wrote in message
news:695642A8-9954-472D-9C90-ECC295BAB791@.microsoft.com...
> Greg
> The data base is a large one, (about 25 GB) dont know if this helps. but
we
> only receive the error when re-indexing takes place.
Very weird. Really sounds like a log is benig lost somewhere along the
line.
Which I had a better answer.
[vbcol=seagreen]
> Andy McDonald
> MCSA
> "Greg D. Moore (Strider)" wrote:
message[vbcol=seagreen]
issues. A[vbcol=seagreen]
Log[vbcol=seagreen]
sync.[vbcol=seagreen]
too[vbcol=seagreen]
shipping?[vbcol=seagreen]
the[vbcol=seagreen]
just[vbcol=seagreen]
I have set up log shipping between two SQL 2000 servers, with no issues. A
job runs on the Primary server to reindex the databases. At this point Log
Shipping Fails, the error massage says that the servers are out of sync.
The log file shows the error
The log in this backup set begins at LSN 202000000017000001, which is too
late to apply to the database. An earlier log backup that includes LSN
20200000
0016800001 can be restored.
Is there a way to reindex the database that does not affect log shipping?
Many thanks in advance
Andy McDonald
MCSA
"Andy McDonald" <Andy McDonald@.discussions.microsoft.com> wrote in message
news:7ED44ADD-C2FF-4E2F-B371-CC3180FC8B8A@.microsoft.com...
> Can anyone help.
> I have set up log shipping between two SQL 2000 servers, with no issues. A
> job runs on the Primary server to reindex the databases. At this point Log
> Shipping Fails, the error massage says that the servers are out of sync.
> The log file shows the error
> The log in this backup set begins at LSN 202000000017000001, which is too
> late to apply to the database. An earlier log backup that includes LSN
> 20200000
> 0016800001 can be restored.
> Is there a way to reindex the database that does not affect log shipping?
It sounds more like somehow you're losing a log backup somewhere along the
line.
reindexing doesn't (or at least shouldn't) affect log-shipping (having just
done this lately).
> Many thanks in advance
> Andy McDonald
> MCSA
|||Greg
The data base is a large one, (about 25 GB) dont know if this helps. but we
only receive the error when re-indexing takes place.
Andy McDonald
MCSA
"Greg D. Moore (Strider)" wrote:
> "Andy McDonald" <Andy McDonald@.discussions.microsoft.com> wrote in message
> news:7ED44ADD-C2FF-4E2F-B371-CC3180FC8B8A@.microsoft.com...
> It sounds more like somehow you're losing a log backup somewhere along the
> line.
> reindexing doesn't (or at least shouldn't) affect log-shipping (having just
> done this lately).
>
>
>
|||Are you 100% certain that you don't set the database to simple recovery mode during reindex?
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://www.solidqualitylearning.com/
"Andy McDonald" <AndyMcDonald@.discussions.microsoft.com> wrote in message
news:695642A8-9954-472D-9C90-ECC295BAB791@.microsoft.com...[vbcol=seagreen]
> Greg
> The data base is a large one, (about 25 GB) dont know if this helps. but we
> only receive the error when re-indexing takes place.
> Andy McDonald
> MCSA
> "Greg D. Moore (Strider)" wrote:
|||Hello
Yes I am sure.
"Tibor Karaszi" wrote:
> Are you 100% certain that you don't set the database to simple recovery mode during reindex?
> --
> Tibor Karaszi, SQL Server MVP
> http://www.karaszi.com/sqlserver/default.asp
> http://www.solidqualitylearning.com/
>
> "Andy McDonald" <AndyMcDonald@.discussions.microsoft.com> wrote in message
> news:695642A8-9954-472D-9C90-ECC295BAB791@.microsoft.com...
>
>
|||"Andy McDonald" <AndyMcDonald@.discussions.microsoft.com> wrote in message
news:695642A8-9954-472D-9C90-ECC295BAB791@.microsoft.com...
> Greg
> The data base is a large one, (about 25 GB) dont know if this helps. but
we
> only receive the error when re-indexing takes place.
Very weird. Really sounds like a log is benig lost somewhere along the
line.
Which I had a better answer.
[vbcol=seagreen]
> Andy McDonald
> MCSA
> "Greg D. Moore (Strider)" wrote:
message[vbcol=seagreen]
issues. A[vbcol=seagreen]
Log[vbcol=seagreen]
sync.[vbcol=seagreen]
too[vbcol=seagreen]
shipping?[vbcol=seagreen]
the[vbcol=seagreen]
just[vbcol=seagreen]
Log Shipping fails after DB Reindex.
Can anyone help.
I have set up log shipping between two SQL 2000 servers, with no issues. A
job runs on the Primary server to reindex the databases. At this point Log
Shipping Fails, the error massage says that the servers are out of sync.
The log file shows the error
The log in this backup set begins at LSN 202000000017000001, which is too
late to apply to the database. An earlier log backup that includes LSN
20200000
0016800001 can be restored.
Is there a way to reindex the database that does not affect log shipping?
Many thanks in advance
Andy McDonald
MCSA"Andy McDonald" <Andy McDonald@.discussions.microsoft.com> wrote in message
news:7ED44ADD-C2FF-4E2F-B371-CC3180FC8B8A@.microsoft.com...
> Can anyone help.
> I have set up log shipping between two SQL 2000 servers, with no issues. A
> job runs on the Primary server to reindex the databases. At this point Log
> Shipping Fails, the error massage says that the servers are out of sync.
> The log file shows the error
> The log in this backup set begins at LSN 202000000017000001, which is too
> late to apply to the database. An earlier log backup that includes LSN
> 20200000
> 0016800001 can be restored.
> Is there a way to reindex the database that does not affect log shipping?
It sounds more like somehow you're losing a log backup somewhere along the
line.
reindexing doesn't (or at least shouldn't) affect log-shipping (having just
done this lately).
> Many thanks in advance
> Andy McDonald
> MCSA|||Greg
The data base is a large one, (about 25 GB) dont know if this helps. but we
only receive the error when re-indexing takes place.
Andy McDonald
MCSA
"Greg D. Moore (Strider)" wrote:
> "Andy McDonald" <Andy McDonald@.discussions.microsoft.com> wrote in message
> news:7ED44ADD-C2FF-4E2F-B371-CC3180FC8B8A@.microsoft.com...
> > Can anyone help.
> >
> > I have set up log shipping between two SQL 2000 servers, with no issues. A
> > job runs on the Primary server to reindex the databases. At this point Log
> > Shipping Fails, the error massage says that the servers are out of sync.
> >
> > The log file shows the error
> > The log in this backup set begins at LSN 202000000017000001, which is too
> > late to apply to the database. An earlier log backup that includes LSN
> > 20200000
> > 0016800001 can be restored.
> >
> > Is there a way to reindex the database that does not affect log shipping?
> It sounds more like somehow you're losing a log backup somewhere along the
> line.
> reindexing doesn't (or at least shouldn't) affect log-shipping (having just
> done this lately).
>
> >
> > Many thanks in advance
> > Andy McDonald
> > MCSA
>
>|||Are you 100% certain that you don't set the database to simple recovery mode during reindex?
--
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://www.solidqualitylearning.com/
"Andy McDonald" <AndyMcDonald@.discussions.microsoft.com> wrote in message
news:695642A8-9954-472D-9C90-ECC295BAB791@.microsoft.com...
> Greg
> The data base is a large one, (about 25 GB) dont know if this helps. but we
> only receive the error when re-indexing takes place.
> Andy McDonald
> MCSA
> "Greg D. Moore (Strider)" wrote:
>> "Andy McDonald" <Andy McDonald@.discussions.microsoft.com> wrote in message
>> news:7ED44ADD-C2FF-4E2F-B371-CC3180FC8B8A@.microsoft.com...
>> > Can anyone help.
>> >
>> > I have set up log shipping between two SQL 2000 servers, with no issues. A
>> > job runs on the Primary server to reindex the databases. At this point Log
>> > Shipping Fails, the error massage says that the servers are out of sync.
>> >
>> > The log file shows the error
>> > The log in this backup set begins at LSN 202000000017000001, which is too
>> > late to apply to the database. An earlier log backup that includes LSN
>> > 20200000
>> > 0016800001 can be restored.
>> >
>> > Is there a way to reindex the database that does not affect log shipping?
>> It sounds more like somehow you're losing a log backup somewhere along the
>> line.
>> reindexing doesn't (or at least shouldn't) affect log-shipping (having just
>> done this lately).
>>
>> >
>> > Many thanks in advance
>> > Andy McDonald
>> > MCSA
>>|||Hello
Yes I am sure.
"Tibor Karaszi" wrote:
> Are you 100% certain that you don't set the database to simple recovery mode during reindex?
> --
> Tibor Karaszi, SQL Server MVP
> http://www.karaszi.com/sqlserver/default.asp
> http://www.solidqualitylearning.com/
>
> "Andy McDonald" <AndyMcDonald@.discussions.microsoft.com> wrote in message
> news:695642A8-9954-472D-9C90-ECC295BAB791@.microsoft.com...
> > Greg
> >
> > The data base is a large one, (about 25 GB) dont know if this helps. but we
> > only receive the error when re-indexing takes place.
> >
> > Andy McDonald
> > MCSA
> >
> > "Greg D. Moore (Strider)" wrote:
> >
> >>
> >> "Andy McDonald" <Andy McDonald@.discussions.microsoft.com> wrote in message
> >> news:7ED44ADD-C2FF-4E2F-B371-CC3180FC8B8A@.microsoft.com...
> >> > Can anyone help.
> >> >
> >> > I have set up log shipping between two SQL 2000 servers, with no issues. A
> >> > job runs on the Primary server to reindex the databases. At this point Log
> >> > Shipping Fails, the error massage says that the servers are out of sync.
> >> >
> >> > The log file shows the error
> >> > The log in this backup set begins at LSN 202000000017000001, which is too
> >> > late to apply to the database. An earlier log backup that includes LSN
> >> > 20200000
> >> > 0016800001 can be restored.
> >> >
> >> > Is there a way to reindex the database that does not affect log shipping?
> >>
> >> It sounds more like somehow you're losing a log backup somewhere along the
> >> line.
> >>
> >> reindexing doesn't (or at least shouldn't) affect log-shipping (having just
> >> done this lately).
> >>
> >>
> >> >
> >> > Many thanks in advance
> >> > Andy McDonald
> >> > MCSA
> >>
> >>
> >>
>
>|||"Andy McDonald" <AndyMcDonald@.discussions.microsoft.com> wrote in message
news:695642A8-9954-472D-9C90-ECC295BAB791@.microsoft.com...
> Greg
> The data base is a large one, (about 25 GB) dont know if this helps. but
we
> only receive the error when re-indexing takes place.
Very weird. Really sounds like a log is benig lost somewhere along the
line.
Which I had a better answer.
> Andy McDonald
> MCSA
> "Greg D. Moore (Strider)" wrote:
> >
> > "Andy McDonald" <Andy McDonald@.discussions.microsoft.com> wrote in
message
> > news:7ED44ADD-C2FF-4E2F-B371-CC3180FC8B8A@.microsoft.com...
> > > Can anyone help.
> > >
> > > I have set up log shipping between two SQL 2000 servers, with no
issues. A
> > > job runs on the Primary server to reindex the databases. At this point
Log
> > > Shipping Fails, the error massage says that the servers are out of
sync.
> > >
> > > The log file shows the error
> > > The log in this backup set begins at LSN 202000000017000001, which is
too
> > > late to apply to the database. An earlier log backup that includes LSN
> > > 20200000
> > > 0016800001 can be restored.
> > >
> > > Is there a way to reindex the database that does not affect log
shipping?
> >
> > It sounds more like somehow you're losing a log backup somewhere along
the
> > line.
> >
> > reindexing doesn't (or at least shouldn't) affect log-shipping (having
just
> > done this lately).
> >
> >
> > >
> > > Many thanks in advance
> > > Andy McDonald
> > > MCSA
> >
> >
> >
I have set up log shipping between two SQL 2000 servers, with no issues. A
job runs on the Primary server to reindex the databases. At this point Log
Shipping Fails, the error massage says that the servers are out of sync.
The log file shows the error
The log in this backup set begins at LSN 202000000017000001, which is too
late to apply to the database. An earlier log backup that includes LSN
20200000
0016800001 can be restored.
Is there a way to reindex the database that does not affect log shipping?
Many thanks in advance
Andy McDonald
MCSA"Andy McDonald" <Andy McDonald@.discussions.microsoft.com> wrote in message
news:7ED44ADD-C2FF-4E2F-B371-CC3180FC8B8A@.microsoft.com...
> Can anyone help.
> I have set up log shipping between two SQL 2000 servers, with no issues. A
> job runs on the Primary server to reindex the databases. At this point Log
> Shipping Fails, the error massage says that the servers are out of sync.
> The log file shows the error
> The log in this backup set begins at LSN 202000000017000001, which is too
> late to apply to the database. An earlier log backup that includes LSN
> 20200000
> 0016800001 can be restored.
> Is there a way to reindex the database that does not affect log shipping?
It sounds more like somehow you're losing a log backup somewhere along the
line.
reindexing doesn't (or at least shouldn't) affect log-shipping (having just
done this lately).
> Many thanks in advance
> Andy McDonald
> MCSA|||Greg
The data base is a large one, (about 25 GB) dont know if this helps. but we
only receive the error when re-indexing takes place.
Andy McDonald
MCSA
"Greg D. Moore (Strider)" wrote:
> "Andy McDonald" <Andy McDonald@.discussions.microsoft.com> wrote in message
> news:7ED44ADD-C2FF-4E2F-B371-CC3180FC8B8A@.microsoft.com...
> > Can anyone help.
> >
> > I have set up log shipping between two SQL 2000 servers, with no issues. A
> > job runs on the Primary server to reindex the databases. At this point Log
> > Shipping Fails, the error massage says that the servers are out of sync.
> >
> > The log file shows the error
> > The log in this backup set begins at LSN 202000000017000001, which is too
> > late to apply to the database. An earlier log backup that includes LSN
> > 20200000
> > 0016800001 can be restored.
> >
> > Is there a way to reindex the database that does not affect log shipping?
> It sounds more like somehow you're losing a log backup somewhere along the
> line.
> reindexing doesn't (or at least shouldn't) affect log-shipping (having just
> done this lately).
>
> >
> > Many thanks in advance
> > Andy McDonald
> > MCSA
>
>|||Are you 100% certain that you don't set the database to simple recovery mode during reindex?
--
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://www.solidqualitylearning.com/
"Andy McDonald" <AndyMcDonald@.discussions.microsoft.com> wrote in message
news:695642A8-9954-472D-9C90-ECC295BAB791@.microsoft.com...
> Greg
> The data base is a large one, (about 25 GB) dont know if this helps. but we
> only receive the error when re-indexing takes place.
> Andy McDonald
> MCSA
> "Greg D. Moore (Strider)" wrote:
>> "Andy McDonald" <Andy McDonald@.discussions.microsoft.com> wrote in message
>> news:7ED44ADD-C2FF-4E2F-B371-CC3180FC8B8A@.microsoft.com...
>> > Can anyone help.
>> >
>> > I have set up log shipping between two SQL 2000 servers, with no issues. A
>> > job runs on the Primary server to reindex the databases. At this point Log
>> > Shipping Fails, the error massage says that the servers are out of sync.
>> >
>> > The log file shows the error
>> > The log in this backup set begins at LSN 202000000017000001, which is too
>> > late to apply to the database. An earlier log backup that includes LSN
>> > 20200000
>> > 0016800001 can be restored.
>> >
>> > Is there a way to reindex the database that does not affect log shipping?
>> It sounds more like somehow you're losing a log backup somewhere along the
>> line.
>> reindexing doesn't (or at least shouldn't) affect log-shipping (having just
>> done this lately).
>>
>> >
>> > Many thanks in advance
>> > Andy McDonald
>> > MCSA
>>|||Hello
Yes I am sure.
"Tibor Karaszi" wrote:
> Are you 100% certain that you don't set the database to simple recovery mode during reindex?
> --
> Tibor Karaszi, SQL Server MVP
> http://www.karaszi.com/sqlserver/default.asp
> http://www.solidqualitylearning.com/
>
> "Andy McDonald" <AndyMcDonald@.discussions.microsoft.com> wrote in message
> news:695642A8-9954-472D-9C90-ECC295BAB791@.microsoft.com...
> > Greg
> >
> > The data base is a large one, (about 25 GB) dont know if this helps. but we
> > only receive the error when re-indexing takes place.
> >
> > Andy McDonald
> > MCSA
> >
> > "Greg D. Moore (Strider)" wrote:
> >
> >>
> >> "Andy McDonald" <Andy McDonald@.discussions.microsoft.com> wrote in message
> >> news:7ED44ADD-C2FF-4E2F-B371-CC3180FC8B8A@.microsoft.com...
> >> > Can anyone help.
> >> >
> >> > I have set up log shipping between two SQL 2000 servers, with no issues. A
> >> > job runs on the Primary server to reindex the databases. At this point Log
> >> > Shipping Fails, the error massage says that the servers are out of sync.
> >> >
> >> > The log file shows the error
> >> > The log in this backup set begins at LSN 202000000017000001, which is too
> >> > late to apply to the database. An earlier log backup that includes LSN
> >> > 20200000
> >> > 0016800001 can be restored.
> >> >
> >> > Is there a way to reindex the database that does not affect log shipping?
> >>
> >> It sounds more like somehow you're losing a log backup somewhere along the
> >> line.
> >>
> >> reindexing doesn't (or at least shouldn't) affect log-shipping (having just
> >> done this lately).
> >>
> >>
> >> >
> >> > Many thanks in advance
> >> > Andy McDonald
> >> > MCSA
> >>
> >>
> >>
>
>|||"Andy McDonald" <AndyMcDonald@.discussions.microsoft.com> wrote in message
news:695642A8-9954-472D-9C90-ECC295BAB791@.microsoft.com...
> Greg
> The data base is a large one, (about 25 GB) dont know if this helps. but
we
> only receive the error when re-indexing takes place.
Very weird. Really sounds like a log is benig lost somewhere along the
line.
Which I had a better answer.
> Andy McDonald
> MCSA
> "Greg D. Moore (Strider)" wrote:
> >
> > "Andy McDonald" <Andy McDonald@.discussions.microsoft.com> wrote in
message
> > news:7ED44ADD-C2FF-4E2F-B371-CC3180FC8B8A@.microsoft.com...
> > > Can anyone help.
> > >
> > > I have set up log shipping between two SQL 2000 servers, with no
issues. A
> > > job runs on the Primary server to reindex the databases. At this point
Log
> > > Shipping Fails, the error massage says that the servers are out of
sync.
> > >
> > > The log file shows the error
> > > The log in this backup set begins at LSN 202000000017000001, which is
too
> > > late to apply to the database. An earlier log backup that includes LSN
> > > 20200000
> > > 0016800001 can be restored.
> > >
> > > Is there a way to reindex the database that does not affect log
shipping?
> >
> > It sounds more like somehow you're losing a log backup somewhere along
the
> > line.
> >
> > reindexing doesn't (or at least shouldn't) affect log-shipping (having
just
> > done this lately).
> >
> >
> > >
> > > Many thanks in advance
> > > Andy McDonald
> > > MCSA
> >
> >
> >
Log Shipping Fails after 45 minutes of Success
Greetings:
I have spent the past coupleof weeks investigating, testing, and now
deploying Log Shipping on our SQL server(s). I thought I had the
implementation process down, and had it working (well it was working fine on
the test environment), but I have run into something 'painful'...
I have configured several databases to 'Log Ship' from our primary server (a
Windows 2000 Advanced Server running SQL 2000 Enterprise w/ SP3a) to our
secondary server (a Windows 2003 Enterprise Ed. running SQL 2000 Enterprise
Ed. w/SP3a). At this point, I have successfully configured 7 databases to
'Log Ship' under this configuration, with different copy & load schedules.
Unfortunately, one of these databases, specifically the one called dbGlobal
that is configured to replicate the most frequently (every 5 minutes) has
displayed the following behavior BOTH times I attempted to configure it from
scratch using the EM Wizard.
The initial configuration, creation of the destination database, restoration
of data and initial transaction logs run no problem. As a matter of fact,
configured to run every 5 minutes, this database appears to do what it is
expected to for 45 minutes. After 45 minutes, the Maintenance Plan suddenly
fails to load additional transaction logs to the destination database. I
have noticed the following symptoms:
In the SQL Server logs, I continually see this sequence of messages, all in
the same second the Maintenance Plan is activated (both before and after the
failure):
Starting up database 'dbGlobal'
Bypassing Recovery for database 'dbGlobal' because it is marked IN LOAD.
Bypassing Recovery for database 'dbGlobal' because it is marked IN LOAD.
Starting up database 'dbGlobal'
Recovery is checkpointing database 'dbGlobal' (7)
Log Restored: Database dbGlobal....
Note that when I view the list of databases on the secondary server in EM,
it lists all Log Shipped databases, including dbGlobal, as Read-Only.
Secondly, and I think this is much more informative, is the information from
the Job history and SQL command. When reviewing the job history for the Log
Shipping Restore of this database on the secondary server, as I said, they
all appear successful for the first 45 minutes, and then suddenly just start
failing. When I copy the SQL command from the maintenance plan step to SQL
Query Analyzer, I get the following series of errors:
"[Microsoft SQL-DMO (ODBC SQLState: 42000)] Error 4305: [Microsoft
][ODBC
SQL Server Driver][SQL Server]The log in this backup set begins at LSN
xxxxxxxxxxxxxxxx, which is too late to apply to the database. An earlier
log backup that includes LSN yyyyyyyyyyyyyyy can be restored."
In the above error message, there is a series of these. In each one,
xxxxx... and yyyyy... are different and not equal.
Finally, when viewing the Log Shipping Monitor (on a separate Windows 2000
box running SQL 2000 Standard Edition), the status indicates:
"Secondary out of sync"
And finally, one more anomaly I have noticed. Each database has its
transaction logs backed up to a separate directory. In the directory for
the dbGlobal transaction logs, a file with an extension of .tuf was created
each time I configured the Log Shipping Maintenance Plan. This was not
created in any of the other directories for the other databases. Could this
have something to do with it? And yes, it is very likely this database is
being modified during the initial Log Shipping configuration.
I was supposed to have this running and working by the beginning of
November, so needless to say I need some assistance as quickly as possible.
If anyone can help me identify why I can get this going, but not keep it
going on only this one database, I would be very appreciative. Thanks in
advance for your help, and I hope I provided enough but not too much info.
Sincerely,
Keith C. Jakobs, MCPKeith,
It looks to me like there is another transaction log backup that is
"stepping on" your log shipping process. Your log shipping setup
expects all transaction logs from a given database, and if a backup of
the log is done outside of that log-shipping system, it essentially
leaves a gap that the log-shipping hangs on.
In my situation, I set up log-shipping on a 15-minute schedule, but
forgot that I also had a general maintenance plan set up for all user
databases that included a log backup. So, log-shipping worked until my
general maint plan took a log backup, and then it hung.
Remove any other jobs that are taking backups of the log in question,
re-build log-shipping, and you should be good to go.
Hope this helps.
Keith Jakobs, MCP wrote:
> Greetings:
> I have spent the past coupleof weeks investigating, testing, and now
> deploying Log Shipping on our SQL server(s). I thought I had the
> implementation process down, and had it working (well it was working fine
on
> the test environment), but I have run into something 'painful'...
> I have configured several databases to 'Log Ship' from our primary server
(a
> Windows 2000 Advanced Server running SQL 2000 Enterprise w/ SP3a) to our
> secondary server (a Windows 2003 Enterprise Ed. running SQL 2000 Enterpris
e
> Ed. w/SP3a). At this point, I have successfully configured 7 databases to
> 'Log Ship' under this configuration, with different copy & load schedules.
> Unfortunately, one of these databases, specifically the one called dbGloba
l
> that is configured to replicate the most frequently (every 5 minutes) has
> displayed the following behavior BOTH times I attempted to configure it fr
om
> scratch using the EM Wizard.
> The initial configuration, creation of the destination database, restorati
on
> of data and initial transaction logs run no problem. As a matter of fact,
> configured to run every 5 minutes, this database appears to do what it is
> expected to for 45 minutes. After 45 minutes, the Maintenance Plan sudden
ly
> fails to load additional transaction logs to the destination database. I
> have noticed the following symptoms:
> In the SQL Server logs, I continually see this sequence of messages, all
in
> the same second the Maintenance Plan is activated (both before and after t
he
> failure):
> Starting up database 'dbGlobal'
> Bypassing Recovery for database 'dbGlobal' because it is marked IN LOAD.
> Bypassing Recovery for database 'dbGlobal' because it is marked IN LOAD.
> Starting up database 'dbGlobal'
> Recovery is checkpointing database 'dbGlobal' (7)
> Log Restored: Database dbGlobal....
> Note that when I view the list of databases on the secondary server in EM,
> it lists all Log Shipped databases, including dbGlobal, as Read-Only.
> Secondly, and I think this is much more informative, is the information fr
om
> the Job history and SQL command. When reviewing the job history for the L
og
> Shipping Restore of this database on the secondary server, as I said, they
> all appear successful for the first 45 minutes, and then suddenly just sta
rt
> failing. When I copy the SQL command from the maintenance plan step to SQ
L
> Query Analyzer, I get the following series of errors:
> "[Microsoft SQL-DMO (ODBC SQLState: 42000)] Error 4305: [Microso
ft][ODBC
> SQL Server Driver][SQL Server]The log in this backup set begins at LSN
> xxxxxxxxxxxxxxxx, which is too late to apply to the database. An earlier
> log backup that includes LSN yyyyyyyyyyyyyyy can be restored."
> In the above error message, there is a series of these. In each one,
> xxxxx... and yyyyy... are different and not equal.
> Finally, when viewing the Log Shipping Monitor (on a separate Windows 2000
> box running SQL 2000 Standard Edition), the status indicates:
> "Secondary out of sync"
> And finally, one more anomaly I have noticed. Each database has its
> transaction logs backed up to a separate directory. In the directory for
> the dbGlobal transaction logs, a file with an extension of .tuf was create
d
> each time I configured the Log Shipping Maintenance Plan. This was not
> created in any of the other directories for the other databases. Could th
is
> have something to do with it? And yes, it is very likely this database is
> being modified during the initial Log Shipping configuration.
> I was supposed to have this running and working by the beginning of
> November, so needless to say I need some assistance as quickly as possible
.
> If anyone can help me identify why I can get this going, but not keep it
> going on only this one database, I would be very appreciative. Thanks in
> advance for your help, and I hope I provided enough but not too much info.
> Sincerely,
> Keith C. Jakobs, MCP
I have spent the past coupleof weeks investigating, testing, and now
deploying Log Shipping on our SQL server(s). I thought I had the
implementation process down, and had it working (well it was working fine on
the test environment), but I have run into something 'painful'...
I have configured several databases to 'Log Ship' from our primary server (a
Windows 2000 Advanced Server running SQL 2000 Enterprise w/ SP3a) to our
secondary server (a Windows 2003 Enterprise Ed. running SQL 2000 Enterprise
Ed. w/SP3a). At this point, I have successfully configured 7 databases to
'Log Ship' under this configuration, with different copy & load schedules.
Unfortunately, one of these databases, specifically the one called dbGlobal
that is configured to replicate the most frequently (every 5 minutes) has
displayed the following behavior BOTH times I attempted to configure it from
scratch using the EM Wizard.
The initial configuration, creation of the destination database, restoration
of data and initial transaction logs run no problem. As a matter of fact,
configured to run every 5 minutes, this database appears to do what it is
expected to for 45 minutes. After 45 minutes, the Maintenance Plan suddenly
fails to load additional transaction logs to the destination database. I
have noticed the following symptoms:
In the SQL Server logs, I continually see this sequence of messages, all in
the same second the Maintenance Plan is activated (both before and after the
failure):
Starting up database 'dbGlobal'
Bypassing Recovery for database 'dbGlobal' because it is marked IN LOAD.
Bypassing Recovery for database 'dbGlobal' because it is marked IN LOAD.
Starting up database 'dbGlobal'
Recovery is checkpointing database 'dbGlobal' (7)
Log Restored: Database dbGlobal....
Note that when I view the list of databases on the secondary server in EM,
it lists all Log Shipped databases, including dbGlobal, as Read-Only.
Secondly, and I think this is much more informative, is the information from
the Job history and SQL command. When reviewing the job history for the Log
Shipping Restore of this database on the secondary server, as I said, they
all appear successful for the first 45 minutes, and then suddenly just start
failing. When I copy the SQL command from the maintenance plan step to SQL
Query Analyzer, I get the following series of errors:
"[Microsoft SQL-DMO (ODBC SQLState: 42000)] Error 4305: [Microsoft
][ODBC
SQL Server Driver][SQL Server]The log in this backup set begins at LSN
xxxxxxxxxxxxxxxx, which is too late to apply to the database. An earlier
log backup that includes LSN yyyyyyyyyyyyyyy can be restored."
In the above error message, there is a series of these. In each one,
xxxxx... and yyyyy... are different and not equal.
Finally, when viewing the Log Shipping Monitor (on a separate Windows 2000
box running SQL 2000 Standard Edition), the status indicates:
"Secondary out of sync"
And finally, one more anomaly I have noticed. Each database has its
transaction logs backed up to a separate directory. In the directory for
the dbGlobal transaction logs, a file with an extension of .tuf was created
each time I configured the Log Shipping Maintenance Plan. This was not
created in any of the other directories for the other databases. Could this
have something to do with it? And yes, it is very likely this database is
being modified during the initial Log Shipping configuration.
I was supposed to have this running and working by the beginning of
November, so needless to say I need some assistance as quickly as possible.
If anyone can help me identify why I can get this going, but not keep it
going on only this one database, I would be very appreciative. Thanks in
advance for your help, and I hope I provided enough but not too much info.
Sincerely,
Keith C. Jakobs, MCPKeith,
It looks to me like there is another transaction log backup that is
"stepping on" your log shipping process. Your log shipping setup
expects all transaction logs from a given database, and if a backup of
the log is done outside of that log-shipping system, it essentially
leaves a gap that the log-shipping hangs on.
In my situation, I set up log-shipping on a 15-minute schedule, but
forgot that I also had a general maintenance plan set up for all user
databases that included a log backup. So, log-shipping worked until my
general maint plan took a log backup, and then it hung.
Remove any other jobs that are taking backups of the log in question,
re-build log-shipping, and you should be good to go.
Hope this helps.
Keith Jakobs, MCP wrote:
> Greetings:
> I have spent the past coupleof weeks investigating, testing, and now
> deploying Log Shipping on our SQL server(s). I thought I had the
> implementation process down, and had it working (well it was working fine
on
> the test environment), but I have run into something 'painful'...
> I have configured several databases to 'Log Ship' from our primary server
(a
> Windows 2000 Advanced Server running SQL 2000 Enterprise w/ SP3a) to our
> secondary server (a Windows 2003 Enterprise Ed. running SQL 2000 Enterpris
e
> Ed. w/SP3a). At this point, I have successfully configured 7 databases to
> 'Log Ship' under this configuration, with different copy & load schedules.
> Unfortunately, one of these databases, specifically the one called dbGloba
l
> that is configured to replicate the most frequently (every 5 minutes) has
> displayed the following behavior BOTH times I attempted to configure it fr
om
> scratch using the EM Wizard.
> The initial configuration, creation of the destination database, restorati
on
> of data and initial transaction logs run no problem. As a matter of fact,
> configured to run every 5 minutes, this database appears to do what it is
> expected to for 45 minutes. After 45 minutes, the Maintenance Plan sudden
ly
> fails to load additional transaction logs to the destination database. I
> have noticed the following symptoms:
> In the SQL Server logs, I continually see this sequence of messages, all
in
> the same second the Maintenance Plan is activated (both before and after t
he
> failure):
> Starting up database 'dbGlobal'
> Bypassing Recovery for database 'dbGlobal' because it is marked IN LOAD.
> Bypassing Recovery for database 'dbGlobal' because it is marked IN LOAD.
> Starting up database 'dbGlobal'
> Recovery is checkpointing database 'dbGlobal' (7)
> Log Restored: Database dbGlobal....
> Note that when I view the list of databases on the secondary server in EM,
> it lists all Log Shipped databases, including dbGlobal, as Read-Only.
> Secondly, and I think this is much more informative, is the information fr
om
> the Job history and SQL command. When reviewing the job history for the L
og
> Shipping Restore of this database on the secondary server, as I said, they
> all appear successful for the first 45 minutes, and then suddenly just sta
rt
> failing. When I copy the SQL command from the maintenance plan step to SQ
L
> Query Analyzer, I get the following series of errors:
> "[Microsoft SQL-DMO (ODBC SQLState: 42000)] Error 4305: [Microso
ft][ODBC
> SQL Server Driver][SQL Server]The log in this backup set begins at LSN
> xxxxxxxxxxxxxxxx, which is too late to apply to the database. An earlier
> log backup that includes LSN yyyyyyyyyyyyyyy can be restored."
> In the above error message, there is a series of these. In each one,
> xxxxx... and yyyyy... are different and not equal.
> Finally, when viewing the Log Shipping Monitor (on a separate Windows 2000
> box running SQL 2000 Standard Edition), the status indicates:
> "Secondary out of sync"
> And finally, one more anomaly I have noticed. Each database has its
> transaction logs backed up to a separate directory. In the directory for
> the dbGlobal transaction logs, a file with an extension of .tuf was create
d
> each time I configured the Log Shipping Maintenance Plan. This was not
> created in any of the other directories for the other databases. Could th
is
> have something to do with it? And yes, it is very likely this database is
> being modified during the initial Log Shipping configuration.
> I was supposed to have this running and working by the beginning of
> November, so needless to say I need some assistance as quickly as possible
.
> If anyone can help me identify why I can get this going, but not keep it
> going on only this one database, I would be very appreciative. Thanks in
> advance for your help, and I hope I provided enough but not too much info.
> Sincerely,
> Keith C. Jakobs, MCP
Log Shipping Fails after 45 minutes of Success
Greetings:
I have spent the past coupleof weeks investigating, testing, and now
deploying Log Shipping on our SQL server(s). I thought I had the
implementation process down, and had it working (well it was working fine on
the test environment), but I have run into something 'painful'...
I have configured several databases to 'Log Ship' from our primary server (a
Windows 2000 Advanced Server running SQL 2000 Enterprise w/ SP3a) to our
secondary server (a Windows 2003 Enterprise Ed. running SQL 2000 Enterprise
Ed. w/SP3a). At this point, I have successfully configured 7 databases to
'Log Ship' under this configuration, with different copy & load schedules.
Unfortunately, one of these databases, specifically the one called dbGlobal
that is configured to replicate the most frequently (every 5 minutes) has
displayed the following behavior BOTH times I attempted to configure it from
scratch using the EM Wizard.
The initial configuration, creation of the destination database, restoration
of data and initial transaction logs run no problem. As a matter of fact,
configured to run every 5 minutes, this database appears to do what it is
expected to for 45 minutes. After 45 minutes, the Maintenance Plan suddenly
fails to load additional transaction logs to the destination database. I
have noticed the following symptoms:
In the SQL Server logs, I continually see this sequence of messages, all in
the same second the Maintenance Plan is activated (both before and after the
failure):
Starting up database 'dbGlobal'
Bypassing Recovery for database 'dbGlobal' because it is marked IN LOAD.
Bypassing Recovery for database 'dbGlobal' because it is marked IN LOAD.
Starting up database 'dbGlobal'
Recovery is checkpointing database 'dbGlobal' (7)
Log Restored: Database dbGlobal....
Note that when I view the list of databases on the secondary server in EM,
it lists all Log Shipped databases, including dbGlobal, as Read-Only.
Secondly, and I think this is much more informative, is the information from
the Job history and SQL command. When reviewing the job history for the Log
Shipping Restore of this database on the secondary server, as I said, they
all appear successful for the first 45 minutes, and then suddenly just start
failing. When I copy the SQL command from the maintenance plan step to SQL
Query Analyzer, I get the following series of errors:
"[Microsoft SQL-DMO (ODBC SQLState: 42000)] Error 4305: [Microsoft][ODBC
SQL Server Driver][SQL Server]The log in this backup set begins at LSN
xxxxxxxxxxxxxxxx, which is too late to apply to the database. An earlier
log backup that includes LSN yyyyyyyyyyyyyyy can be restored."
In the above error message, there is a series of these. In each one,
xxxxx... and yyyyy... are different and not equal.
Finally, when viewing the Log Shipping Monitor (on a separate Windows 2000
box running SQL 2000 Standard Edition), the status indicates:
"Secondary out of sync"
And finally, one more anomaly I have noticed. Each database has its
transaction logs backed up to a separate directory. In the directory for
the dbGlobal transaction logs, a file with an extension of .tuf was created
each time I configured the Log Shipping Maintenance Plan. This was not
created in any of the other directories for the other databases. Could this
have something to do with it? And yes, it is very likely this database is
being modified during the initial Log Shipping configuration.
I was supposed to have this running and working by the beginning of
November, so needless to say I need some assistance as quickly as possible.
If anyone can help me identify why I can get this going, but not keep it
going on only this one database, I would be very appreciative. Thanks in
advance for your help, and I hope I provided enough but not too much info.
Sincerely,
Keith C. Jakobs, MCP
Keith,
It looks to me like there is another transaction log backup that is
"stepping on" your log shipping process. Your log shipping setup
expects all transaction logs from a given database, and if a backup of
the log is done outside of that log-shipping system, it essentially
leaves a gap that the log-shipping hangs on.
In my situation, I set up log-shipping on a 15-minute schedule, but
forgot that I also had a general maintenance plan set up for all user
databases that included a log backup. So, log-shipping worked until my
general maint plan took a log backup, and then it hung.
Remove any other jobs that are taking backups of the log in question,
re-build log-shipping, and you should be good to go.
Hope this helps.
Keith Jakobs, MCP wrote:
> Greetings:
> I have spent the past coupleof weeks investigating, testing, and now
> deploying Log Shipping on our SQL server(s). I thought I had the
> implementation process down, and had it working (well it was working fine on
> the test environment), but I have run into something 'painful'...
> I have configured several databases to 'Log Ship' from our primary server (a
> Windows 2000 Advanced Server running SQL 2000 Enterprise w/ SP3a) to our
> secondary server (a Windows 2003 Enterprise Ed. running SQL 2000 Enterprise
> Ed. w/SP3a). At this point, I have successfully configured 7 databases to
> 'Log Ship' under this configuration, with different copy & load schedules.
> Unfortunately, one of these databases, specifically the one called dbGlobal
> that is configured to replicate the most frequently (every 5 minutes) has
> displayed the following behavior BOTH times I attempted to configure it from
> scratch using the EM Wizard.
> The initial configuration, creation of the destination database, restoration
> of data and initial transaction logs run no problem. As a matter of fact,
> configured to run every 5 minutes, this database appears to do what it is
> expected to for 45 minutes. After 45 minutes, the Maintenance Plan suddenly
> fails to load additional transaction logs to the destination database. I
> have noticed the following symptoms:
> In the SQL Server logs, I continually see this sequence of messages, all in
> the same second the Maintenance Plan is activated (both before and after the
> failure):
> Starting up database 'dbGlobal'
> Bypassing Recovery for database 'dbGlobal' because it is marked IN LOAD.
> Bypassing Recovery for database 'dbGlobal' because it is marked IN LOAD.
> Starting up database 'dbGlobal'
> Recovery is checkpointing database 'dbGlobal' (7)
> Log Restored: Database dbGlobal....
> Note that when I view the list of databases on the secondary server in EM,
> it lists all Log Shipped databases, including dbGlobal, as Read-Only.
> Secondly, and I think this is much more informative, is the information from
> the Job history and SQL command. When reviewing the job history for the Log
> Shipping Restore of this database on the secondary server, as I said, they
> all appear successful for the first 45 minutes, and then suddenly just start
> failing. When I copy the SQL command from the maintenance plan step to SQL
> Query Analyzer, I get the following series of errors:
> "[Microsoft SQL-DMO (ODBC SQLState: 42000)] Error 4305: [Microsoft][ODBC
> SQL Server Driver][SQL Server]The log in this backup set begins at LSN
> xxxxxxxxxxxxxxxx, which is too late to apply to the database. An earlier
> log backup that includes LSN yyyyyyyyyyyyyyy can be restored."
> In the above error message, there is a series of these. In each one,
> xxxxx... and yyyyy... are different and not equal.
> Finally, when viewing the Log Shipping Monitor (on a separate Windows 2000
> box running SQL 2000 Standard Edition), the status indicates:
> "Secondary out of sync"
> And finally, one more anomaly I have noticed. Each database has its
> transaction logs backed up to a separate directory. In the directory for
> the dbGlobal transaction logs, a file with an extension of .tuf was created
> each time I configured the Log Shipping Maintenance Plan. This was not
> created in any of the other directories for the other databases. Could this
> have something to do with it? And yes, it is very likely this database is
> being modified during the initial Log Shipping configuration.
> I was supposed to have this running and working by the beginning of
> November, so needless to say I need some assistance as quickly as possible.
> If anyone can help me identify why I can get this going, but not keep it
> going on only this one database, I would be very appreciative. Thanks in
> advance for your help, and I hope I provided enough but not too much info.
> Sincerely,
> Keith C. Jakobs, MCP
I have spent the past coupleof weeks investigating, testing, and now
deploying Log Shipping on our SQL server(s). I thought I had the
implementation process down, and had it working (well it was working fine on
the test environment), but I have run into something 'painful'...
I have configured several databases to 'Log Ship' from our primary server (a
Windows 2000 Advanced Server running SQL 2000 Enterprise w/ SP3a) to our
secondary server (a Windows 2003 Enterprise Ed. running SQL 2000 Enterprise
Ed. w/SP3a). At this point, I have successfully configured 7 databases to
'Log Ship' under this configuration, with different copy & load schedules.
Unfortunately, one of these databases, specifically the one called dbGlobal
that is configured to replicate the most frequently (every 5 minutes) has
displayed the following behavior BOTH times I attempted to configure it from
scratch using the EM Wizard.
The initial configuration, creation of the destination database, restoration
of data and initial transaction logs run no problem. As a matter of fact,
configured to run every 5 minutes, this database appears to do what it is
expected to for 45 minutes. After 45 minutes, the Maintenance Plan suddenly
fails to load additional transaction logs to the destination database. I
have noticed the following symptoms:
In the SQL Server logs, I continually see this sequence of messages, all in
the same second the Maintenance Plan is activated (both before and after the
failure):
Starting up database 'dbGlobal'
Bypassing Recovery for database 'dbGlobal' because it is marked IN LOAD.
Bypassing Recovery for database 'dbGlobal' because it is marked IN LOAD.
Starting up database 'dbGlobal'
Recovery is checkpointing database 'dbGlobal' (7)
Log Restored: Database dbGlobal....
Note that when I view the list of databases on the secondary server in EM,
it lists all Log Shipped databases, including dbGlobal, as Read-Only.
Secondly, and I think this is much more informative, is the information from
the Job history and SQL command. When reviewing the job history for the Log
Shipping Restore of this database on the secondary server, as I said, they
all appear successful for the first 45 minutes, and then suddenly just start
failing. When I copy the SQL command from the maintenance plan step to SQL
Query Analyzer, I get the following series of errors:
"[Microsoft SQL-DMO (ODBC SQLState: 42000)] Error 4305: [Microsoft][ODBC
SQL Server Driver][SQL Server]The log in this backup set begins at LSN
xxxxxxxxxxxxxxxx, which is too late to apply to the database. An earlier
log backup that includes LSN yyyyyyyyyyyyyyy can be restored."
In the above error message, there is a series of these. In each one,
xxxxx... and yyyyy... are different and not equal.
Finally, when viewing the Log Shipping Monitor (on a separate Windows 2000
box running SQL 2000 Standard Edition), the status indicates:
"Secondary out of sync"
And finally, one more anomaly I have noticed. Each database has its
transaction logs backed up to a separate directory. In the directory for
the dbGlobal transaction logs, a file with an extension of .tuf was created
each time I configured the Log Shipping Maintenance Plan. This was not
created in any of the other directories for the other databases. Could this
have something to do with it? And yes, it is very likely this database is
being modified during the initial Log Shipping configuration.
I was supposed to have this running and working by the beginning of
November, so needless to say I need some assistance as quickly as possible.
If anyone can help me identify why I can get this going, but not keep it
going on only this one database, I would be very appreciative. Thanks in
advance for your help, and I hope I provided enough but not too much info.
Sincerely,
Keith C. Jakobs, MCP
Keith,
It looks to me like there is another transaction log backup that is
"stepping on" your log shipping process. Your log shipping setup
expects all transaction logs from a given database, and if a backup of
the log is done outside of that log-shipping system, it essentially
leaves a gap that the log-shipping hangs on.
In my situation, I set up log-shipping on a 15-minute schedule, but
forgot that I also had a general maintenance plan set up for all user
databases that included a log backup. So, log-shipping worked until my
general maint plan took a log backup, and then it hung.
Remove any other jobs that are taking backups of the log in question,
re-build log-shipping, and you should be good to go.
Hope this helps.
Keith Jakobs, MCP wrote:
> Greetings:
> I have spent the past coupleof weeks investigating, testing, and now
> deploying Log Shipping on our SQL server(s). I thought I had the
> implementation process down, and had it working (well it was working fine on
> the test environment), but I have run into something 'painful'...
> I have configured several databases to 'Log Ship' from our primary server (a
> Windows 2000 Advanced Server running SQL 2000 Enterprise w/ SP3a) to our
> secondary server (a Windows 2003 Enterprise Ed. running SQL 2000 Enterprise
> Ed. w/SP3a). At this point, I have successfully configured 7 databases to
> 'Log Ship' under this configuration, with different copy & load schedules.
> Unfortunately, one of these databases, specifically the one called dbGlobal
> that is configured to replicate the most frequently (every 5 minutes) has
> displayed the following behavior BOTH times I attempted to configure it from
> scratch using the EM Wizard.
> The initial configuration, creation of the destination database, restoration
> of data and initial transaction logs run no problem. As a matter of fact,
> configured to run every 5 minutes, this database appears to do what it is
> expected to for 45 minutes. After 45 minutes, the Maintenance Plan suddenly
> fails to load additional transaction logs to the destination database. I
> have noticed the following symptoms:
> In the SQL Server logs, I continually see this sequence of messages, all in
> the same second the Maintenance Plan is activated (both before and after the
> failure):
> Starting up database 'dbGlobal'
> Bypassing Recovery for database 'dbGlobal' because it is marked IN LOAD.
> Bypassing Recovery for database 'dbGlobal' because it is marked IN LOAD.
> Starting up database 'dbGlobal'
> Recovery is checkpointing database 'dbGlobal' (7)
> Log Restored: Database dbGlobal....
> Note that when I view the list of databases on the secondary server in EM,
> it lists all Log Shipped databases, including dbGlobal, as Read-Only.
> Secondly, and I think this is much more informative, is the information from
> the Job history and SQL command. When reviewing the job history for the Log
> Shipping Restore of this database on the secondary server, as I said, they
> all appear successful for the first 45 minutes, and then suddenly just start
> failing. When I copy the SQL command from the maintenance plan step to SQL
> Query Analyzer, I get the following series of errors:
> "[Microsoft SQL-DMO (ODBC SQLState: 42000)] Error 4305: [Microsoft][ODBC
> SQL Server Driver][SQL Server]The log in this backup set begins at LSN
> xxxxxxxxxxxxxxxx, which is too late to apply to the database. An earlier
> log backup that includes LSN yyyyyyyyyyyyyyy can be restored."
> In the above error message, there is a series of these. In each one,
> xxxxx... and yyyyy... are different and not equal.
> Finally, when viewing the Log Shipping Monitor (on a separate Windows 2000
> box running SQL 2000 Standard Edition), the status indicates:
> "Secondary out of sync"
> And finally, one more anomaly I have noticed. Each database has its
> transaction logs backed up to a separate directory. In the directory for
> the dbGlobal transaction logs, a file with an extension of .tuf was created
> each time I configured the Log Shipping Maintenance Plan. This was not
> created in any of the other directories for the other databases. Could this
> have something to do with it? And yes, it is very likely this database is
> being modified during the initial Log Shipping configuration.
> I was supposed to have this running and working by the beginning of
> November, so needless to say I need some assistance as quickly as possible.
> If anyone can help me identify why I can get this going, but not keep it
> going on only this one database, I would be very appreciative. Thanks in
> advance for your help, and I hope I provided enough but not too much info.
> Sincerely,
> Keith C. Jakobs, MCP
Log Shipping Fails after 45 minutes of Success
Greetings:
I have spent the past coupleof weeks investigating, testing, and now
deploying Log Shipping on our SQL server(s). I thought I had the
implementation process down, and had it working (well it was working fine on
the test environment), but I have run into something 'painful'...
I have configured several databases to 'Log Ship' from our primary server (a
Windows 2000 Advanced Server running SQL 2000 Enterprise w/ SP3a) to our
secondary server (a Windows 2003 Enterprise Ed. running SQL 2000 Enterprise
Ed. w/SP3a). At this point, I have successfully configured 7 databases to
'Log Ship' under this configuration, with different copy & load schedules.
Unfortunately, one of these databases, specifically the one called dbGlobal
that is configured to replicate the most frequently (every 5 minutes) has
displayed the following behavior BOTH times I attempted to configure it from
scratch using the EM Wizard.
The initial configuration, creation of the destination database, restoration
of data and initial transaction logs run no problem. As a matter of fact,
configured to run every 5 minutes, this database appears to do what it is
expected to for 45 minutes. After 45 minutes, the Maintenance Plan suddenly
fails to load additional transaction logs to the destination database. I
have noticed the following symptoms:
In the SQL Server logs, I continually see this sequence of messages, all in
the same second the Maintenance Plan is activated (both before and after the
failure):
Starting up database 'dbGlobal'
Bypassing Recovery for database 'dbGlobal' because it is marked IN LOAD.
Bypassing Recovery for database 'dbGlobal' because it is marked IN LOAD.
Starting up database 'dbGlobal'
Recovery is checkpointing database 'dbGlobal' (7)
Log Restored: Database dbGlobal....
Note that when I view the list of databases on the secondary server in EM,
it lists all Log Shipped databases, including dbGlobal, as Read-Only.
Secondly, and I think this is much more informative, is the information from
the Job history and SQL command. When reviewing the job history for the Log
Shipping Restore of this database on the secondary server, as I said, they
all appear successful for the first 45 minutes, and then suddenly just start
failing. When I copy the SQL command from the maintenance plan step to SQL
Query Analyzer, I get the following series of errors:
"[Microsoft SQL-DMO (ODBC SQLState: 42000)] Error 4305: [Microsoft][ODBC
SQL Server Driver][SQL Server]The log in this backup set begins at LSN
xxxxxxxxxxxxxxxx, which is too late to apply to the database. An earlier
log backup that includes LSN yyyyyyyyyyyyyyy can be restored."
In the above error message, there is a series of these. In each one,
xxxxx... and yyyyy... are different and not equal.
Finally, when viewing the Log Shipping Monitor (on a separate Windows 2000
box running SQL 2000 Standard Edition), the status indicates:
"Secondary out of sync"
And finally, one more anomaly I have noticed. Each database has its
transaction logs backed up to a separate directory. In the directory for
the dbGlobal transaction logs, a file with an extension of .tuf was created
each time I configured the Log Shipping Maintenance Plan. This was not
created in any of the other directories for the other databases. Could this
have something to do with it? And yes, it is very likely this database is
being modified during the initial Log Shipping configuration.
I was supposed to have this running and working by the beginning of
November, so needless to say I need some assistance as quickly as possible.
If anyone can help me identify why I can get this going, but not keep it
going on only this one database, I would be very appreciative. Thanks in
advance for your help, and I hope I provided enough but not too much info.
Sincerely,
Keith C. Jakobs, MCPKeith,
It looks to me like there is another transaction log backup that is
"stepping on" your log shipping process. Your log shipping setup
expects all transaction logs from a given database, and if a backup of
the log is done outside of that log-shipping system, it essentially
leaves a gap that the log-shipping hangs on.
In my situation, I set up log-shipping on a 15-minute schedule, but
forgot that I also had a general maintenance plan set up for all user
databases that included a log backup. So, log-shipping worked until my
general maint plan took a log backup, and then it hung.
Remove any other jobs that are taking backups of the log in question,
re-build log-shipping, and you should be good to go.
Hope this helps.
Keith Jakobs, MCP wrote:
> Greetings:
> I have spent the past coupleof weeks investigating, testing, and now
> deploying Log Shipping on our SQL server(s). I thought I had the
> implementation process down, and had it working (well it was working fine on
> the test environment), but I have run into something 'painful'...
> I have configured several databases to 'Log Ship' from our primary server (a
> Windows 2000 Advanced Server running SQL 2000 Enterprise w/ SP3a) to our
> secondary server (a Windows 2003 Enterprise Ed. running SQL 2000 Enterprise
> Ed. w/SP3a). At this point, I have successfully configured 7 databases to
> 'Log Ship' under this configuration, with different copy & load schedules.
> Unfortunately, one of these databases, specifically the one called dbGlobal
> that is configured to replicate the most frequently (every 5 minutes) has
> displayed the following behavior BOTH times I attempted to configure it from
> scratch using the EM Wizard.
> The initial configuration, creation of the destination database, restoration
> of data and initial transaction logs run no problem. As a matter of fact,
> configured to run every 5 minutes, this database appears to do what it is
> expected to for 45 minutes. After 45 minutes, the Maintenance Plan suddenly
> fails to load additional transaction logs to the destination database. I
> have noticed the following symptoms:
> In the SQL Server logs, I continually see this sequence of messages, all in
> the same second the Maintenance Plan is activated (both before and after the
> failure):
> Starting up database 'dbGlobal'
> Bypassing Recovery for database 'dbGlobal' because it is marked IN LOAD.
> Bypassing Recovery for database 'dbGlobal' because it is marked IN LOAD.
> Starting up database 'dbGlobal'
> Recovery is checkpointing database 'dbGlobal' (7)
> Log Restored: Database dbGlobal....
> Note that when I view the list of databases on the secondary server in EM,
> it lists all Log Shipped databases, including dbGlobal, as Read-Only.
> Secondly, and I think this is much more informative, is the information from
> the Job history and SQL command. When reviewing the job history for the Log
> Shipping Restore of this database on the secondary server, as I said, they
> all appear successful for the first 45 minutes, and then suddenly just start
> failing. When I copy the SQL command from the maintenance plan step to SQL
> Query Analyzer, I get the following series of errors:
> "[Microsoft SQL-DMO (ODBC SQLState: 42000)] Error 4305: [Microsoft][ODBC
> SQL Server Driver][SQL Server]The log in this backup set begins at LSN
> xxxxxxxxxxxxxxxx, which is too late to apply to the database. An earlier
> log backup that includes LSN yyyyyyyyyyyyyyy can be restored."
> In the above error message, there is a series of these. In each one,
> xxxxx... and yyyyy... are different and not equal.
> Finally, when viewing the Log Shipping Monitor (on a separate Windows 2000
> box running SQL 2000 Standard Edition), the status indicates:
> "Secondary out of sync"
> And finally, one more anomaly I have noticed. Each database has its
> transaction logs backed up to a separate directory. In the directory for
> the dbGlobal transaction logs, a file with an extension of .tuf was created
> each time I configured the Log Shipping Maintenance Plan. This was not
> created in any of the other directories for the other databases. Could this
> have something to do with it? And yes, it is very likely this database is
> being modified during the initial Log Shipping configuration.
> I was supposed to have this running and working by the beginning of
> November, so needless to say I need some assistance as quickly as possible.
> If anyone can help me identify why I can get this going, but not keep it
> going on only this one database, I would be very appreciative. Thanks in
> advance for your help, and I hope I provided enough but not too much info.
> Sincerely,
> Keith C. Jakobs, MCP
I have spent the past coupleof weeks investigating, testing, and now
deploying Log Shipping on our SQL server(s). I thought I had the
implementation process down, and had it working (well it was working fine on
the test environment), but I have run into something 'painful'...
I have configured several databases to 'Log Ship' from our primary server (a
Windows 2000 Advanced Server running SQL 2000 Enterprise w/ SP3a) to our
secondary server (a Windows 2003 Enterprise Ed. running SQL 2000 Enterprise
Ed. w/SP3a). At this point, I have successfully configured 7 databases to
'Log Ship' under this configuration, with different copy & load schedules.
Unfortunately, one of these databases, specifically the one called dbGlobal
that is configured to replicate the most frequently (every 5 minutes) has
displayed the following behavior BOTH times I attempted to configure it from
scratch using the EM Wizard.
The initial configuration, creation of the destination database, restoration
of data and initial transaction logs run no problem. As a matter of fact,
configured to run every 5 minutes, this database appears to do what it is
expected to for 45 minutes. After 45 minutes, the Maintenance Plan suddenly
fails to load additional transaction logs to the destination database. I
have noticed the following symptoms:
In the SQL Server logs, I continually see this sequence of messages, all in
the same second the Maintenance Plan is activated (both before and after the
failure):
Starting up database 'dbGlobal'
Bypassing Recovery for database 'dbGlobal' because it is marked IN LOAD.
Bypassing Recovery for database 'dbGlobal' because it is marked IN LOAD.
Starting up database 'dbGlobal'
Recovery is checkpointing database 'dbGlobal' (7)
Log Restored: Database dbGlobal....
Note that when I view the list of databases on the secondary server in EM,
it lists all Log Shipped databases, including dbGlobal, as Read-Only.
Secondly, and I think this is much more informative, is the information from
the Job history and SQL command. When reviewing the job history for the Log
Shipping Restore of this database on the secondary server, as I said, they
all appear successful for the first 45 minutes, and then suddenly just start
failing. When I copy the SQL command from the maintenance plan step to SQL
Query Analyzer, I get the following series of errors:
"[Microsoft SQL-DMO (ODBC SQLState: 42000)] Error 4305: [Microsoft][ODBC
SQL Server Driver][SQL Server]The log in this backup set begins at LSN
xxxxxxxxxxxxxxxx, which is too late to apply to the database. An earlier
log backup that includes LSN yyyyyyyyyyyyyyy can be restored."
In the above error message, there is a series of these. In each one,
xxxxx... and yyyyy... are different and not equal.
Finally, when viewing the Log Shipping Monitor (on a separate Windows 2000
box running SQL 2000 Standard Edition), the status indicates:
"Secondary out of sync"
And finally, one more anomaly I have noticed. Each database has its
transaction logs backed up to a separate directory. In the directory for
the dbGlobal transaction logs, a file with an extension of .tuf was created
each time I configured the Log Shipping Maintenance Plan. This was not
created in any of the other directories for the other databases. Could this
have something to do with it? And yes, it is very likely this database is
being modified during the initial Log Shipping configuration.
I was supposed to have this running and working by the beginning of
November, so needless to say I need some assistance as quickly as possible.
If anyone can help me identify why I can get this going, but not keep it
going on only this one database, I would be very appreciative. Thanks in
advance for your help, and I hope I provided enough but not too much info.
Sincerely,
Keith C. Jakobs, MCPKeith,
It looks to me like there is another transaction log backup that is
"stepping on" your log shipping process. Your log shipping setup
expects all transaction logs from a given database, and if a backup of
the log is done outside of that log-shipping system, it essentially
leaves a gap that the log-shipping hangs on.
In my situation, I set up log-shipping on a 15-minute schedule, but
forgot that I also had a general maintenance plan set up for all user
databases that included a log backup. So, log-shipping worked until my
general maint plan took a log backup, and then it hung.
Remove any other jobs that are taking backups of the log in question,
re-build log-shipping, and you should be good to go.
Hope this helps.
Keith Jakobs, MCP wrote:
> Greetings:
> I have spent the past coupleof weeks investigating, testing, and now
> deploying Log Shipping on our SQL server(s). I thought I had the
> implementation process down, and had it working (well it was working fine on
> the test environment), but I have run into something 'painful'...
> I have configured several databases to 'Log Ship' from our primary server (a
> Windows 2000 Advanced Server running SQL 2000 Enterprise w/ SP3a) to our
> secondary server (a Windows 2003 Enterprise Ed. running SQL 2000 Enterprise
> Ed. w/SP3a). At this point, I have successfully configured 7 databases to
> 'Log Ship' under this configuration, with different copy & load schedules.
> Unfortunately, one of these databases, specifically the one called dbGlobal
> that is configured to replicate the most frequently (every 5 minutes) has
> displayed the following behavior BOTH times I attempted to configure it from
> scratch using the EM Wizard.
> The initial configuration, creation of the destination database, restoration
> of data and initial transaction logs run no problem. As a matter of fact,
> configured to run every 5 minutes, this database appears to do what it is
> expected to for 45 minutes. After 45 minutes, the Maintenance Plan suddenly
> fails to load additional transaction logs to the destination database. I
> have noticed the following symptoms:
> In the SQL Server logs, I continually see this sequence of messages, all in
> the same second the Maintenance Plan is activated (both before and after the
> failure):
> Starting up database 'dbGlobal'
> Bypassing Recovery for database 'dbGlobal' because it is marked IN LOAD.
> Bypassing Recovery for database 'dbGlobal' because it is marked IN LOAD.
> Starting up database 'dbGlobal'
> Recovery is checkpointing database 'dbGlobal' (7)
> Log Restored: Database dbGlobal....
> Note that when I view the list of databases on the secondary server in EM,
> it lists all Log Shipped databases, including dbGlobal, as Read-Only.
> Secondly, and I think this is much more informative, is the information from
> the Job history and SQL command. When reviewing the job history for the Log
> Shipping Restore of this database on the secondary server, as I said, they
> all appear successful for the first 45 minutes, and then suddenly just start
> failing. When I copy the SQL command from the maintenance plan step to SQL
> Query Analyzer, I get the following series of errors:
> "[Microsoft SQL-DMO (ODBC SQLState: 42000)] Error 4305: [Microsoft][ODBC
> SQL Server Driver][SQL Server]The log in this backup set begins at LSN
> xxxxxxxxxxxxxxxx, which is too late to apply to the database. An earlier
> log backup that includes LSN yyyyyyyyyyyyyyy can be restored."
> In the above error message, there is a series of these. In each one,
> xxxxx... and yyyyy... are different and not equal.
> Finally, when viewing the Log Shipping Monitor (on a separate Windows 2000
> box running SQL 2000 Standard Edition), the status indicates:
> "Secondary out of sync"
> And finally, one more anomaly I have noticed. Each database has its
> transaction logs backed up to a separate directory. In the directory for
> the dbGlobal transaction logs, a file with an extension of .tuf was created
> each time I configured the Log Shipping Maintenance Plan. This was not
> created in any of the other directories for the other databases. Could this
> have something to do with it? And yes, it is very likely this database is
> being modified during the initial Log Shipping configuration.
> I was supposed to have this running and working by the beginning of
> November, so needless to say I need some assistance as quickly as possible.
> If anyone can help me identify why I can get this going, but not keep it
> going on only this one database, I would be very appreciative. Thanks in
> advance for your help, and I hope I provided enough but not too much info.
> Sincerely,
> Keith C. Jakobs, MCP
Subscribe to:
Comments (Atom)