Showing posts with label message. Show all posts
Showing posts with label message. Show all posts

Monday, March 12, 2012

Log shipping from 64-bit to 32-bit boxes?

This is a multi-part message in MIME format.
--070303010507090703040805
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
My company is considering a new Itanium cluster in our production
environment. Our DR boxes are still 32-bit with no plans to replace
them with 64-bit boxes. We currently log ship our production DBs from
our 32-bit production clusters to our 32-bit DR cluster.
My boss asked me this week (as part of the Itanium considerations) if
we'll be able to still log ship the production DBs from our new 64-bit
SQL instances to our 32-bit DR SQL instances. After a little thought I
said it would probably work but I've never done it myself or read
anything from someone who had done it so I couldn't say definitively
that it would work. (I fired off the question to my TAM but haven't
heard back from him.)
The only potential problem I can think of would be during the restore
phase of the sync - will a backup from a 64-bit instance restore
properly to a 32-bit instance? Do they have different internal DB
structures like SQL 7.0 vs SQL 2000 for example? If so, will that
conversion happen automagically like SQL 7 -> 2000?
Has anyone done this before (log shipping from a primary 64-bit SQL
instance to a secondary 32-bit SQL instance)? Does it work? Is it
supported by Microsoft? Can the log shipping monitor run on a 32-bit
instance?
--
*mike hodgson*
blog: http://sqlnerd.blogspot.com
--070303010507090703040805
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
<tt>My company is considering a new Itanium cluster in our production
environment. Our DR boxes are still 32-bit with no plans to replace
them with 64-bit boxes. We currently log ship our production DBs from
our 32-bit production clusters to our 32-bit DR cluster.<br>
<br>
My boss asked me this week (as part of the Itanium considerations) if
we'll be able to still log ship the production DBs from our new 64-bit
SQL instances to our 32-bit DR SQL instances. After a little thought I
said it would probably work but I've never done it myself or read
anything from someone who had done it so I couldn't say definitively
that it would work. (I fired off the question to my TAM but haven't
heard back from him.)<br>
<br>
The only potential problem I can think of would be during the restore
phase of the sync - will a backup from a 64-bit instance restore
properly to a 32-bit instance? Do they have different internal DB
structures like SQL 7.0 vs SQL 2000 for example? If so, will that
conversion happen automagically like SQL 7 -> 2000?<br>
<br>
Has anyone done this before (log shipping from a primary 64-bit SQL
instance to a secondary 32-bit SQL instance)? Does it work? Is it
supported by Microsoft? Can the log shipping monitor run on a 32-bit
instance?<br>
</tt><tt></tt>
<div class="moz-signature">
<p><span lang="en-au"><font face="Tahoma" size="2">--<br>
</font></span> <b><span lang="en-au"><font face="Tahoma" size="2">mike
hodgson</font></span></b><span lang="en-au"><br>
<font face="Tahoma" size="2">blog:</font><font face="Tahoma" size="2"> <a
href="http://links.10026.com/?link=http://sqlnerd.blogspot.com">http://sqlnerd.blogspot.com</a></font></span>
</p>
</div>
</body>
</html>
--070303010507090703040805--This is a multi-part message in MIME format.
--=_NextPart_000_004C_01C5986D.BCCBB090
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Never tried it yet but it should work as far as I know. You can take a =32 bit backup or detached file and restore it or attach it to a 64 bit =and visa versa. So I see no reason why log shipping would not work. =The internal structures do not change.
-- Andrew J. Kelly SQL MVP

"Mike Hodgson" <mike.hodgson@.mallesons.nospam.com> wrote in message =news:uH9URVImFHA.1148@.TK2MSFTNGP12.phx.gbl...
My company is considering a new Itanium cluster in our production =environment. Our DR boxes are still 32-bit with no plans to replace =them with 64-bit boxes. We currently log ship our production DBs from =our 32-bit production clusters to our 32-bit DR cluster.
My boss asked me this week (as part of the Itanium considerations) if =we'll be able to still log ship the production DBs from our new 64-bit =SQL instances to our 32-bit DR SQL instances. After a little thought I =said it would probably work but I've never done it myself or read =anything from someone who had done it so I couldn't say definitively =that it would work. (I fired off the question to my TAM but haven't =heard back from him.)
The only potential problem I can think of would be during the restore =phase of the sync - will a backup from a 64-bit instance restore =properly to a 32-bit instance? Do they have different internal DB =structures like SQL 7.0 vs SQL 2000 for example? If so, will that =conversion happen automagically like SQL 7 -> 2000?
Has anyone done this before (log shipping from a primary 64-bit SQL =instance to a secondary 32-bit SQL instance)? Does it work? Is it =supported by Microsoft? Can the log shipping monitor run on a 32-bit =instance?
--
mike hodgson
blog: http://sqlnerd.blogspot.com=20
--=_NextPart_000_004C_01C5986D.BCCBB090
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
&

Never tried it yet but it should work as far as I =know. You can take a 32 bit backup or detached file and restore it or attach =it to a 64 bit and visa versa. So I see no reason why log shipping would =not work. The internal structures do not change.
-- Andrew J. Kelly SQL MVP
"Mike Hodgson" wrote in message news:uH9URVImFHA.1148=@.TK2MSFTNGP12.phx.gbl...My company is considering a new Itanium cluster in our production environment. Our DR boxes are still 32-bit with no plans to =replace them with 64-bit boxes. We currently log ship our production DBs from =our 32-bit production clusters to our 32-bit DR cluster.My boss =asked me this week (as part of the Itanium considerations) if we'll be able to =still log ship the production DBs from our new 64-bit SQL instances to our =32-bit DR SQL instances. After a little thought I said it would probably =work but I've never done it myself or read anything from someone who had done =it so I couldn't say definitively that it would work. (I fired off the =question to my TAM but haven't heard back from him.)The only potential =problem I can think of would be during the restore phase of the sync - will a =backup from a 64-bit instance restore properly to a 32-bit instance? Do =they have different internal DB structures like SQL 7.0 vs SQL 2000 for example? If so, will that conversion happen automagically like =SQL 7 -> 2000?Has anyone done this before (log shipping from a =primary 64-bit SQL instance to a secondary 32-bit SQL instance)? Does it = work? Is it supported by Microsoft? Can the log shipping =monitor run on a 32-bit instance?
--mike =hodgsonblog: http://sqlnerd.blogspot.com

--=_NextPart_000_004C_01C5986D.BCCBB090--

Friday, March 9, 2012

log shipping error message

hi,
We set up a log shipping job on our control server for one
of our sql servers and its fail-over server. We keep
getting these kind of job failures from time to time:
'The job failed. The Job was invoked by Schedule 12 (Log
Shipping Alert Job - Restore). The last step to run was
step 1 (Log Shipping Alert Job - Restore).
Executed as user: domainName\ControlServerName. The log
shipping destination fail_overServerName.databaseName is
out of sync by 30 minutes. [SQLSTATE 42000] (Error 14421)
Associated statement is not prepared [SQLSTATE HY007]
(Error 0). The step failed.'
What does this 'Associated statement is not prepared' mean?
many thanks.
JJJJ,
You might experience these symptoms if you configured primary or secondary
servers (or both) to connect to the monitor server by using SQL Server
Authentication on a computer that is running SQL Server 2000 Service Pack 2
(SP2)
To resolve this problem, obtain the latest service pack for Microsoft SQL
Server 2000.
SQL Server 2000 Service Pack 3a (SP3a) is available from the following
Microsoft Web site: http://www.microsoft.com/sql/downloads/2000/sp3.asp
To work around this problem, click the Use Windows Authentication option in
the Specify the Log Shipping Monitor Server Information dialog box during
log shipping Setup.
Background info for Error 14421 follows:
By definition, message 14421 does not necessarily indicate a problem with
Log Shipping. This message indicates that the difference between the last
backed up file and last restored file is greater than the time selected for
the Out of Sync Alert threshold.
There are serveral reasons why the alert message is raised. The following
list includes some of these reasons:
1.. The date or time (or both) on the primary server is modified such that
the date or time on the primary server is significantly ahead between
consecutive transaction log backups.
2.. The log shipping Restore job that is running on the secondary server
cannot connect to the monitor server msdb database to update the
log_shipping_secondaries table with the correct value. This may be the
result of an authentication problem between the secondary server and the
monitor server.
3.. You may have set an incorrect value for the Out of Sync Alert
threshold. Ideally, you must set this value to at least three times the
frequency of the slower of the Copy and Restore jobs. If the frequency of
the Copy or Restore jobs is modified after log shipping is set up and
functional, you must modify the value of the Out of Sync Alert threshold
accordingly.
4.. Problems either with the Backup job or Copy job are most likely to
result in "out of sync" alert messages. If "out of sync" alert messages are
raised and if there are no problems with the Backup or the Restore job,
check the Copy job for potential problems. Additionally, network
connectivity may cause the Copy job to fail.
5.. It is also possible that the Restore job on the secondary server is
failing. In this case, check the job history for the Restore job because it
may indicate a reason for the failure.
--
Keith Wilson
This posting is provided "AS IS" without express or implied warranty,
guarantee, or rights.
"JJ Wang" <anonymous@.discussions.microsoft.com> wrote in message
news:05b001c3b2f4$44286c10$a501280a@.phx.gbl...
> hi,
> We set up a log shipping job on our control server for one
> of our sql servers and its fail-over server. We keep
> getting these kind of job failures from time to time:
> 'The job failed. The Job was invoked by Schedule 12 (Log
> Shipping Alert Job - Restore). The last step to run was
> step 1 (Log Shipping Alert Job - Restore).
> Executed as user: domainName\ControlServerName. The log
> shipping destination fail_overServerName.databaseName is
> out of sync by 30 minutes. [SQLSTATE 42000] (Error 14421)
> Associated statement is not prepared [SQLSTATE HY007]
> (Error 0). The step failed.'
> What does this 'Associated statement is not prepared' mean?
> many thanks.
> JJ
>