While playing with log shipping it appears that the restore is timing out, without errors. The shipper is successfully backing up to disk, xcopying the backup to the receiver, calling the restore SP on the receiver. The restore runs for exactly 10 minutes
and 1 second then ends with a success. Any ideas on what I missed?
Denny,
I'm not sure about this. How do you know it has timed out - do any of the
transactions get applied on the standby server at all?
Regards,
Paul Ibison
|||I am not sure it is timing out, it was only a guess. When it tries to apply the first log it says that database was only partially restored.
If I manually run the retore SP on the receiver, rather than having the shipper call it, it successfully restores the entire backup file then I can ship the logs with no errors.
|||I ran the restore SP via Query Analyzer on the shipping server and I was correct. The error was (OLE/DB provider returned message: Timeout Expired)..
Did I do my linked server incorrectly?
|||Denny,
your setup is sound, as there is no timeout property in log shipping. I
suspect this is something peripheral - it could be network lag, or
alternatively (and possibly more likely) your database is expanding. I have
a KB article that explains this as a potential cause of this issue:
http://support.microsoft.com/default...;EN-US;Q305635
HTH,
Paul Ibison
|||I was able to narrow it down to a timeout setting with the Linked Servers. Both the connection timeout and query timeout had a value of zero entered, which is supposed to be no timeout (assuming I understood the documentation correctly). As soon as I set
the query timeout to 1200 seconds everything works fine. I will probably set it to 1800 seconds, I'd imagine 30 minutes would be more than enough time to restore from a file.
|||Denny,
but log-shipping doesn't use linked servers. Is this perhaps a custom
inplementation?
Regards,
Paul Ibison
|||Yes it is. I followed the directions from a doc on SQL-Server-Performance. The scheduled task on the production box dumps to disk, copies it to the warm standby server using xcopy, then calls an SP on the warm standby server that restores that file.
|||Denny this makes sense now. If the query timeout is zero, it uses the value
in sp_configure. I thing that you'll find that that is the problem as it is
set too low. Setting the value at the lower level as you have done overrides
the sp_configure value, so that explains why it works now.
Regards,
Paul Ibison
Showing posts with label successfully. Show all posts
Showing posts with label successfully. Show all posts
Monday, March 26, 2012
Friday, March 23, 2012
Log Shipping Question
I have successfully setup log shipping between my production SQL 2000 Server
(setup in a Cluster) and my Disaster Recovery SQL 2000 Server (across a WAN)
What is the best way if any to stop the log shipping for a extended period
of time and re-enable it without setting up the entire maintenance plan
again. Is this possible? What happened is I needed to shut down my
production server due to hurricane Wilma as a precaution. I disabled the log
shipping jobs on both servers but didn't actually physicall shut down the
Disaster Recovery SQL 2000 Server.
The servers got out of synch...although it said the logs were being shipped
and they were working correctly after I turned the production server back on.
However, the log were not being copied to the Disaster Recovery Server.
Any help would be appreciated. Thanks!!
Hello mate,
The way I understand it is you could have just shut down your production
server without changing/stopping/disabling the log shipping jobs and just
bring it back online when your happy (the hurricane has passed!) and the
backup/copy and restores should resume as normal?
The shipping jobs seems very automated once started and syncronised - think
of it like a 'long reboot' of your production boxes. Your boxes aer fine
after bouncing them right - so whats the difference if they are down for a
few days?
I'm in the middle of documenting a similar setup with my production box (non
clustered) getting logs sent to the backup SQL box accross a WAN - the most
complex part of the exercise seems to be getting the backup DB up and running
post failure/disaster of the production box.
Hope this helps you mate.
Paul.
"foghorn69@.news.postalias" wrote:
> I have successfully setup log shipping between my production SQL 2000 Server
> (setup in a Cluster) and my Disaster Recovery SQL 2000 Server (across a WAN)
> What is the best way if any to stop the log shipping for a extended period
> of time and re-enable it without setting up the entire maintenance plan
> again. Is this possible? What happened is I needed to shut down my
> production server due to hurricane Wilma as a precaution. I disabled the log
> shipping jobs on both servers but didn't actually physicall shut down the
> Disaster Recovery SQL 2000 Server.
> The servers got out of synch...although it said the logs were being shipped
> and they were working correctly after I turned the production server back on.
> However, the log were not being copied to the Disaster Recovery Server.
> Any help would be appreciated. Thanks!!
(setup in a Cluster) and my Disaster Recovery SQL 2000 Server (across a WAN)
What is the best way if any to stop the log shipping for a extended period
of time and re-enable it without setting up the entire maintenance plan
again. Is this possible? What happened is I needed to shut down my
production server due to hurricane Wilma as a precaution. I disabled the log
shipping jobs on both servers but didn't actually physicall shut down the
Disaster Recovery SQL 2000 Server.
The servers got out of synch...although it said the logs were being shipped
and they were working correctly after I turned the production server back on.
However, the log were not being copied to the Disaster Recovery Server.
Any help would be appreciated. Thanks!!
Hello mate,
The way I understand it is you could have just shut down your production
server without changing/stopping/disabling the log shipping jobs and just
bring it back online when your happy (the hurricane has passed!) and the
backup/copy and restores should resume as normal?
The shipping jobs seems very automated once started and syncronised - think
of it like a 'long reboot' of your production boxes. Your boxes aer fine
after bouncing them right - so whats the difference if they are down for a
few days?
I'm in the middle of documenting a similar setup with my production box (non
clustered) getting logs sent to the backup SQL box accross a WAN - the most
complex part of the exercise seems to be getting the backup DB up and running
post failure/disaster of the production box.
Hope this helps you mate.
Paul.
"foghorn69@.news.postalias" wrote:
> I have successfully setup log shipping between my production SQL 2000 Server
> (setup in a Cluster) and my Disaster Recovery SQL 2000 Server (across a WAN)
> What is the best way if any to stop the log shipping for a extended period
> of time and re-enable it without setting up the entire maintenance plan
> again. Is this possible? What happened is I needed to shut down my
> production server due to hurricane Wilma as a precaution. I disabled the log
> shipping jobs on both servers but didn't actually physicall shut down the
> Disaster Recovery SQL 2000 Server.
> The servers got out of synch...although it said the logs were being shipped
> and they were working correctly after I turned the production server back on.
> However, the log were not being copied to the Disaster Recovery Server.
> Any help would be appreciated. Thanks!!
Log Shipping Question
I have successfully setup log shipping between my production SQL 2000 Server
(setup in a Cluster) and my Disaster Recovery SQL 2000 Server (across a WAN)
What is the best way if any to stop the log shipping for a extended period
of time and re-enable it without setting up the entire maintenance plan
again. Is this possible? What happened is I needed to shut down my
production server due to hurricane Wilma as a precaution. I disabled the log
shipping jobs on both servers but didn't actually physicall shut down the
Disaster Recovery SQL 2000 Server.
The servers got out of synch...although it said the logs were being shipped
and they were working correctly after I turned the production server back on.
However, the log were not being copied to the Disaster Recovery Server.
Any help would be appreciated. Thanks!!
Hello,
Based on my experience, you shall remove and recreate log shipping for this
situation becaseu the expected backup on the primary servers were not
properly created due to server shutdown.
More related information:
329133.KB.EN-US INF: Troubleshooting SQL Server 2000 Log Shipping "Out of
Sync" Errors
http://support.microsoft.com/default...B;EN-US;329133
314515.KB.EN-US INF: Frequently Asked Questions - SQL Server 2000 - Log
Shipping
http://support.microsoft.com/default...B;EN-US;314515
SQL Server 2000 How To Setup Log Shipping
http://www.microsoft.com/downloads/d...&familyid=7395
ec1b-199f-42bc-a31b-2056adf73f94
http://www.microsoft.com/technet/tre...hnet/prodtechn
ol/sql/deploy/prodspecs/logship1.asp
Best Regards,
Peter Yang
MCSE2000/2003, MCSA, MCDBA
Microsoft Online Partner Support
When responding to posts, please "Reply to Group" via your newsreader so
that others may learn and benefit from your issue.
================================================== ===
This posting is provided "AS IS" with no warranties, and confers no rights.
| Thread-Topic: Log Shipping Question
| thread-index: AcXmR7EoN/OMKH5UTPqRcRbKocEcOg==
| X-WBNR-Posting-Host: 66.20.1.9
| From: "=?Utf-8?B?Rm9naG9ybkxlZ2hvcm4=?=" <foghornleghorn@.nospam.postalias>
| Subject: Log Shipping Question
| Date: Thu, 10 Nov 2005 14:40:03 -0800
| Lines: 17
| Message-ID: <E1996FA4-68BA-4906-9886-D05F65119C1A@.microsoft.com>
| MIME-Version: 1.0
| Content-Type: text/plain;
| charset="Utf-8"
| Content-Transfer-Encoding: 7bit
| X-Newsreader: Microsoft CDO for Windows 2000
| Content-Class: urn:content-classes:message
| Importance: normal
| Priority: normal
| X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.0
| Newsgroups: microsoft.public.sqlserver.replication
| NNTP-Posting-Host: TK2MSFTNGXA03.phx.gbl 10.40.2.250
| Path: TK2MSFTNGXA02.phx.gbl!TK2MSFTNGXA03.phx.gbl
| Xref: TK2MSFTNGXA02.phx.gbl microsoft.public.sqlserver.replication:66533
| X-Tomcat-NG: microsoft.public.sqlserver.replication
|
| I have successfully setup log shipping between my production SQL 2000
Server
| (setup in a Cluster) and my Disaster Recovery SQL 2000 Server (across a
WAN)
|
| What is the best way if any to stop the log shipping for a extended
period
| of time and re-enable it without setting up the entire maintenance plan
| again. Is this possible? What happened is I needed to shut down my
| production server due to hurricane Wilma as a precaution. I disabled the
log
| shipping jobs on both servers but didn't actually physicall shut down the
| Disaster Recovery SQL 2000 Server.
|
| The servers got out of synch...although it said the logs were being
shipped
| and they were working correctly after I turned the production server back
on.
| However, the log were not being copied to the Disaster Recovery Server.
|
| Any help would be appreciated. Thanks!!
|
|
|
(setup in a Cluster) and my Disaster Recovery SQL 2000 Server (across a WAN)
What is the best way if any to stop the log shipping for a extended period
of time and re-enable it without setting up the entire maintenance plan
again. Is this possible? What happened is I needed to shut down my
production server due to hurricane Wilma as a precaution. I disabled the log
shipping jobs on both servers but didn't actually physicall shut down the
Disaster Recovery SQL 2000 Server.
The servers got out of synch...although it said the logs were being shipped
and they were working correctly after I turned the production server back on.
However, the log were not being copied to the Disaster Recovery Server.
Any help would be appreciated. Thanks!!
Hello,
Based on my experience, you shall remove and recreate log shipping for this
situation becaseu the expected backup on the primary servers were not
properly created due to server shutdown.
More related information:
329133.KB.EN-US INF: Troubleshooting SQL Server 2000 Log Shipping "Out of
Sync" Errors
http://support.microsoft.com/default...B;EN-US;329133
314515.KB.EN-US INF: Frequently Asked Questions - SQL Server 2000 - Log
Shipping
http://support.microsoft.com/default...B;EN-US;314515
SQL Server 2000 How To Setup Log Shipping
http://www.microsoft.com/downloads/d...&familyid=7395
ec1b-199f-42bc-a31b-2056adf73f94
http://www.microsoft.com/technet/tre...hnet/prodtechn
ol/sql/deploy/prodspecs/logship1.asp
Best Regards,
Peter Yang
MCSE2000/2003, MCSA, MCDBA
Microsoft Online Partner Support
When responding to posts, please "Reply to Group" via your newsreader so
that others may learn and benefit from your issue.
================================================== ===
This posting is provided "AS IS" with no warranties, and confers no rights.
| Thread-Topic: Log Shipping Question
| thread-index: AcXmR7EoN/OMKH5UTPqRcRbKocEcOg==
| X-WBNR-Posting-Host: 66.20.1.9
| From: "=?Utf-8?B?Rm9naG9ybkxlZ2hvcm4=?=" <foghornleghorn@.nospam.postalias>
| Subject: Log Shipping Question
| Date: Thu, 10 Nov 2005 14:40:03 -0800
| Lines: 17
| Message-ID: <E1996FA4-68BA-4906-9886-D05F65119C1A@.microsoft.com>
| MIME-Version: 1.0
| Content-Type: text/plain;
| charset="Utf-8"
| Content-Transfer-Encoding: 7bit
| X-Newsreader: Microsoft CDO for Windows 2000
| Content-Class: urn:content-classes:message
| Importance: normal
| Priority: normal
| X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.0
| Newsgroups: microsoft.public.sqlserver.replication
| NNTP-Posting-Host: TK2MSFTNGXA03.phx.gbl 10.40.2.250
| Path: TK2MSFTNGXA02.phx.gbl!TK2MSFTNGXA03.phx.gbl
| Xref: TK2MSFTNGXA02.phx.gbl microsoft.public.sqlserver.replication:66533
| X-Tomcat-NG: microsoft.public.sqlserver.replication
|
| I have successfully setup log shipping between my production SQL 2000
Server
| (setup in a Cluster) and my Disaster Recovery SQL 2000 Server (across a
WAN)
|
| What is the best way if any to stop the log shipping for a extended
period
| of time and re-enable it without setting up the entire maintenance plan
| again. Is this possible? What happened is I needed to shut down my
| production server due to hurricane Wilma as a precaution. I disabled the
log
| shipping jobs on both servers but didn't actually physicall shut down the
| Disaster Recovery SQL 2000 Server.
|
| The servers got out of synch...although it said the logs were being
shipped
| and they were working correctly after I turned the production server back
on.
| However, the log were not being copied to the Disaster Recovery Server.
|
| Any help would be appreciated. Thanks!!
|
|
|
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
Log shipping over a T1, best pratices
I successfully implemented log shipping but am questioning the xcopy function over a point to point T1. Would it be better to use FTP? The database file is currently 6 gigs in size and takes awhile to copy over. We are doing this with SQL Server 2000 sta
ndard, so we don't get the extra features that Enterprise Edition would give us, whatever they may be. Any suggestions are appreciated.
Thanks,
Denny
ftp is considered to be unsecure. Its performance is much the same as an
xcopy.
"Denny" <anonymous@.discussions.microsoft.com> wrote in message
news:6E15A90F-AB52-4268-B379-B7FE73EA5EED@.microsoft.com...
> I successfully implemented log shipping but am questioning the xcopy
function over a point to point T1. Would it be better to use FTP? The
database file is currently 6 gigs in size and takes awhile to copy over. We
are doing this with SQL Server 2000 standard, so we don't get the extra
features that Enterprise Edition would give us, whatever they may be. Any
suggestions are appreciated.
> Thanks,
> Denny
ndard, so we don't get the extra features that Enterprise Edition would give us, whatever they may be. Any suggestions are appreciated.
Thanks,
Denny
ftp is considered to be unsecure. Its performance is much the same as an
xcopy.
"Denny" <anonymous@.discussions.microsoft.com> wrote in message
news:6E15A90F-AB52-4268-B379-B7FE73EA5EED@.microsoft.com...
> I successfully implemented log shipping but am questioning the xcopy
function over a point to point T1. Would it be better to use FTP? The
database file is currently 6 gigs in size and takes awhile to copy over. We
are doing this with SQL Server 2000 standard, so we don't get the extra
features that Enterprise Edition would give us, whatever they may be. Any
suggestions are appreciated.
> Thanks,
> Denny
Monday, March 19, 2012
Log shipping issue
Hi,
I have tried to set up Log shipping on SQL Server 2000. After I had
successfully finished all the steps the log shipping ran well for about 45
minutes when it got out of sync.
I have deleted all the metadata about logshipping from primary,
secondary and from the monitoring server. (I had to do it from Query Analyzer
as from EM it wasn`t possible - i suppose something was stucked).
Now all the info about the old log shipping plan is gone. The problem
that I have is that when I try to set up a new log shipping plan, when I
chose the database for which I want to ship logs -> the log shipping checkbox
grayes out. If i select first the log shipping checkbox and then the
database, the checkbox also grays out but checked and I`m able to go further
and to set the rest of the options -> at the step at which I am suppose to
chose the secondary server, although it appears in the list, when I select it
nothing happens (the selection remains like there is no server selected)
The primary server uses Full Recovery model
I have manually restored all the backups from the primary to the
secondary to bring the secondary db uptodate.
Any ideas?
Thank you
--
Razvan Dragomir,
MCSA / MCSE / MCDB / MCITPI managed to solve the thing with log shipping check box being grayed out -
there was still some info in the log_shipping_databases.
But I still have the problem with the secondary server - i`m not able to
select it in the log shipping wizard. I have also create another test
database and it`s the same. .. looks like I can`t ship on that secondary
server.
All servers are Enterprise edition, having for services same users and
passwords (domain user)
Any ideas?
Thank you
--
Razvan Dragomir,
MCSA / MCSE / MCDB / MCITP
"Razvan Dragomir" wrote:
> Hi,
> I have tried to set up Log shipping on SQL Server 2000. After I had
> successfully finished all the steps the log shipping ran well for about 45
> minutes when it got out of sync.
> I have deleted all the metadata about logshipping from primary,
> secondary and from the monitoring server. (I had to do it from Query Analyzer
> as from EM it wasn`t possible - i suppose something was stucked).
> Now all the info about the old log shipping plan is gone. The problem
> that I have is that when I try to set up a new log shipping plan, when I
> chose the database for which I want to ship logs -> the log shipping checkbox
> grayes out. If i select first the log shipping checkbox and then the
> database, the checkbox also grays out but checked and I`m able to go further
> and to set the rest of the options -> at the step at which I am suppose to
> chose the secondary server, although it appears in the list, when I select it
> nothing happens (the selection remains like there is no server selected)
> The primary server uses Full Recovery model
> I have manually restored all the backups from the primary to the
> secondary to bring the secondary db uptodate.
> Any ideas?
> Thank you
> --
> Razvan Dragomir,
> MCSA / MCSE / MCDB / MCITP
>
I have tried to set up Log shipping on SQL Server 2000. After I had
successfully finished all the steps the log shipping ran well for about 45
minutes when it got out of sync.
I have deleted all the metadata about logshipping from primary,
secondary and from the monitoring server. (I had to do it from Query Analyzer
as from EM it wasn`t possible - i suppose something was stucked).
Now all the info about the old log shipping plan is gone. The problem
that I have is that when I try to set up a new log shipping plan, when I
chose the database for which I want to ship logs -> the log shipping checkbox
grayes out. If i select first the log shipping checkbox and then the
database, the checkbox also grays out but checked and I`m able to go further
and to set the rest of the options -> at the step at which I am suppose to
chose the secondary server, although it appears in the list, when I select it
nothing happens (the selection remains like there is no server selected)
The primary server uses Full Recovery model
I have manually restored all the backups from the primary to the
secondary to bring the secondary db uptodate.
Any ideas?
Thank you
--
Razvan Dragomir,
MCSA / MCSE / MCDB / MCITPI managed to solve the thing with log shipping check box being grayed out -
there was still some info in the log_shipping_databases.
But I still have the problem with the secondary server - i`m not able to
select it in the log shipping wizard. I have also create another test
database and it`s the same. .. looks like I can`t ship on that secondary
server.
All servers are Enterprise edition, having for services same users and
passwords (domain user)
Any ideas?
Thank you
--
Razvan Dragomir,
MCSA / MCSE / MCDB / MCITP
"Razvan Dragomir" wrote:
> Hi,
> I have tried to set up Log shipping on SQL Server 2000. After I had
> successfully finished all the steps the log shipping ran well for about 45
> minutes when it got out of sync.
> I have deleted all the metadata about logshipping from primary,
> secondary and from the monitoring server. (I had to do it from Query Analyzer
> as from EM it wasn`t possible - i suppose something was stucked).
> Now all the info about the old log shipping plan is gone. The problem
> that I have is that when I try to set up a new log shipping plan, when I
> chose the database for which I want to ship logs -> the log shipping checkbox
> grayes out. If i select first the log shipping checkbox and then the
> database, the checkbox also grays out but checked and I`m able to go further
> and to set the rest of the options -> at the step at which I am suppose to
> chose the secondary server, although it appears in the list, when I select it
> nothing happens (the selection remains like there is no server selected)
> The primary server uses Full Recovery model
> I have manually restored all the backups from the primary to the
> secondary to bring the secondary db uptodate.
> Any ideas?
> Thank you
> --
> Razvan Dragomir,
> MCSA / MCSE / MCDB / MCITP
>
Friday, March 9, 2012
Log Shipping Error 4323
Hi all,
Scenario : MS Windows 2003 SP1 - MS SQL Server 2000 EE SP4
Log Shipping
My secondary server was restoring backup logs successfully, but suddenly i got the following error:
[Microsoft SQL-DMO (ODBC SQLState: 42000)] Error 4323: [Microsoft][ODBC SQL Server Driver][SQL Server]The database is marked suspect. Transaction logs cannot be restored. Use RESTORE DATABASE to recover the database.
[Microsoft][ODBC SQL Server Driver][SQL Server]RESTORE LOG is terminating abnormally.
How can I fix this situation without re create the maintenance plan ?
We had the same issue some time ago, this was related to a new file being created in a filegroup on the source. Don't know if this applies to your case, but restoring a backup of this new file on the secondary server solved the pb (unless we had to restore the whole db, sorry I can't remember, my memory is gone... together with the customer :o).
HTH,
Vincent
Log Shipping Error 4323
Hi all,
Scenario : MS Windows 2003 SP1 - MS SQL Server 2000 EE SP4
Log Shipping
My secondary server was restoring backup logs successfully, but suddenly i got the following error:
[Microsoft SQL-DMO (ODBC SQLState: 42000)] Error 4323: [Microsoft][ODBC SQL Server Driver][SQL Server]The database is marked suspect. Transaction logs cannot be restored. Use RESTORE DATABASE to recover the database.
[Microsoft][ODBC SQL Server Driver][SQL Server]RESTORE LOG is terminating abnormally.
How can I fix this situation without re create the maintenance plan ?
We had the same issue some time ago, this was related to a new file being created in a filegroup on the source. Don't know if this applies to your case, but restoring a backup of this new file on the secondary server solved the pb (unless we had to restore the whole db, sorry I can't remember, my memory is gone... together with the customer :o).
HTH,
Vincent
log shipping error
I have successfully configured log shipping, and verified that the standby
server is being updated correctly.
There is one job named "Log Shipping Alert Job - Backup" which fails every
minute.
In the job history, it says:
'The job shipping source SERVERNAME.DATABASE has not backed up for 190
minutes. [SQLSTATE 42000] [Error 14420] The step failed.'
I guess that this can be disregarded, but supervisors get nervous about
errors, and suspect that the log shipping is not reliable.
How can I make this job succeed?
Thanks
Bill
It looks like the 'last_updated' field in 'log_shipping_primaries' in MSDB
isn't getting updated.
Whey would that be the case?
Thanks
Bill
"bill" <belgie@.datamti.com> wrote in message
news:e$lobJOeFHA.2128@.TK2MSFTNGP14.phx.gbl...
> I have successfully configured log shipping, and verified that the standby
> server is being updated correctly.
> There is one job named "Log Shipping Alert Job - Backup" which fails every
> minute.
> In the job history, it says:
> 'The job shipping source SERVERNAME.DATABASE has not backed up for 190
> minutes. [SQLSTATE 42000] [Error 14420] The step failed.'
> I guess that this can be disregarded, but supervisors get nervous about
> errors, and suspect that the log shipping is not reliable.
> How can I make this job succeed?
> Thanks
> Bill
>
>
|||Microsoft say:
"Thresholds
The DBA maintaining the SQL Server environment needs to know if log shipping becomes too far out of sync and/or may be failing. The two parameters to configure are: backup alert threshold and out of sync alert threshold. The alerts are triggered by error messages 14420 and 14421, respectively, and can be changed. After log shipping is installed, access the parameters by selecting the properties of the log shipping pair listed under the Log Shipping Monitor. "
Regards,
Milovan
server is being updated correctly.
There is one job named "Log Shipping Alert Job - Backup" which fails every
minute.
In the job history, it says:
'The job shipping source SERVERNAME.DATABASE has not backed up for 190
minutes. [SQLSTATE 42000] [Error 14420] The step failed.'
I guess that this can be disregarded, but supervisors get nervous about
errors, and suspect that the log shipping is not reliable.
How can I make this job succeed?
Thanks
Bill
It looks like the 'last_updated' field in 'log_shipping_primaries' in MSDB
isn't getting updated.
Whey would that be the case?
Thanks
Bill
"bill" <belgie@.datamti.com> wrote in message
news:e$lobJOeFHA.2128@.TK2MSFTNGP14.phx.gbl...
> I have successfully configured log shipping, and verified that the standby
> server is being updated correctly.
> There is one job named "Log Shipping Alert Job - Backup" which fails every
> minute.
> In the job history, it says:
> 'The job shipping source SERVERNAME.DATABASE has not backed up for 190
> minutes. [SQLSTATE 42000] [Error 14420] The step failed.'
> I guess that this can be disregarded, but supervisors get nervous about
> errors, and suspect that the log shipping is not reliable.
> How can I make this job succeed?
> Thanks
> Bill
>
>
|||Microsoft say:
"Thresholds
The DBA maintaining the SQL Server environment needs to know if log shipping becomes too far out of sync and/or may be failing. The two parameters to configure are: backup alert threshold and out of sync alert threshold. The alerts are triggered by error messages 14420 and 14421, respectively, and can be changed. After log shipping is installed, access the parameters by selecting the properties of the log shipping pair listed under the Log Shipping Monitor. "
Regards,
Milovan
Wednesday, March 7, 2012
log shipping barfing
sql2k sp2
Log Shipping gets set up successfully. The db gets created
on the secondary box. All the TLog backups get transferred
to the secondary box. But then after some time it gets out
of sync. In the reporting file there is the message:
(snippet)
(SQL Server does not exist or access is denied)
How could this be since it was able to intialize the new
db? If it never did that and I got this message it would
make more sense than creating the db but not baing able to
connect after that.
TIA, ChrisChris,
Which job is failing? Sounds like the restore job on the secondary. Are you
sure SQL Agent on the secondary can connect to the secondary SQL Server?
Ron
--
Ron Talmage
SQL Server MVP
"chris" <anonymous@.discussions.microsoft.com> wrote in message
news:05e001c3a4ca$1a848f70$a301280a@.phx.gbl...
> sql2k sp2
> Log Shipping gets set up successfully. The db gets created
> on the secondary box. All the TLog backups get transferred
> to the secondary box. But then after some time it gets out
> of sync. In the reporting file there is the message:
> (snippet)
> (SQL Server does not exist or access is denied)
> How could this be since it was able to intialize the new
> db? If it never did that and I got this message it would
> make more sense than creating the db but not baing able to
> connect after that.
> TIA, Chris
>|||Are you
>sure SQL Agent on the secondary can connect to the
secondary SQL Server?
Not sure Im following on this one.
>--Original Message--
>Chris,
>Which job is failing? Sounds like the restore job on the
secondary. Are you
>sure SQL Agent on the secondary can connect to the
secondary SQL Server?
>Ron
>--
>Ron Talmage
>SQL Server MVP
>"chris" <anonymous@.discussions.microsoft.com> wrote in
message
>news:05e001c3a4ca$1a848f70$a301280a@.phx.gbl...
>> sql2k sp2
>> Log Shipping gets set up successfully. The db gets
created
>> on the secondary box. All the TLog backups get
transferred
>> to the secondary box. But then after some time it gets
out
>> of sync. In the reporting file there is the message:
>> (snippet)
>> (SQL Server does not exist or access is denied)
>> How could this be since it was able to intialize the new
>> db? If it never did that and I got this message it would
>> make more sense than creating the db but not baing able
to
>> connect after that.
>> TIA, Chris
>
>.
>
Log Shipping gets set up successfully. The db gets created
on the secondary box. All the TLog backups get transferred
to the secondary box. But then after some time it gets out
of sync. In the reporting file there is the message:
(snippet)
(SQL Server does not exist or access is denied)
How could this be since it was able to intialize the new
db? If it never did that and I got this message it would
make more sense than creating the db but not baing able to
connect after that.
TIA, ChrisChris,
Which job is failing? Sounds like the restore job on the secondary. Are you
sure SQL Agent on the secondary can connect to the secondary SQL Server?
Ron
--
Ron Talmage
SQL Server MVP
"chris" <anonymous@.discussions.microsoft.com> wrote in message
news:05e001c3a4ca$1a848f70$a301280a@.phx.gbl...
> sql2k sp2
> Log Shipping gets set up successfully. The db gets created
> on the secondary box. All the TLog backups get transferred
> to the secondary box. But then after some time it gets out
> of sync. In the reporting file there is the message:
> (snippet)
> (SQL Server does not exist or access is denied)
> How could this be since it was able to intialize the new
> db? If it never did that and I got this message it would
> make more sense than creating the db but not baing able to
> connect after that.
> TIA, Chris
>|||Are you
>sure SQL Agent on the secondary can connect to the
secondary SQL Server?
Not sure Im following on this one.
>--Original Message--
>Chris,
>Which job is failing? Sounds like the restore job on the
secondary. Are you
>sure SQL Agent on the secondary can connect to the
secondary SQL Server?
>Ron
>--
>Ron Talmage
>SQL Server MVP
>"chris" <anonymous@.discussions.microsoft.com> wrote in
message
>news:05e001c3a4ca$1a848f70$a301280a@.phx.gbl...
>> sql2k sp2
>> Log Shipping gets set up successfully. The db gets
created
>> on the secondary box. All the TLog backups get
transferred
>> to the secondary box. But then after some time it gets
out
>> of sync. In the reporting file there is the message:
>> (snippet)
>> (SQL Server does not exist or access is denied)
>> How could this be since it was able to intialize the new
>> db? If it never did that and I got this message it would
>> make more sense than creating the db but not baing able
to
>> connect after that.
>> TIA, Chris
>
>.
>
Subscribe to:
Posts (Atom)