Showing posts with label target. Show all posts
Showing posts with label target. Show all posts

Wednesday, March 21, 2012

Log Shipping NTFS compressed files WAN

If the compression attribute is set on both the source SQL Server directory
and the target SQL Server directory for a log shipping configuration, will
the log files be uncompressed and then recompressed when the copy is made?
Or will the files remain compressed while the copy is taking place? If
WIN2K and SS are smart enough to handle the latter, it will speed up the
transfer of files across a WAN link.This is purely an OS thing, nothing to do with SQL.
See the quote from the following KB article
http://support.microsoft.com/?kbid=251186
When you copy or move a compressed NTFS file to a different folder, NTFS
decompresses the file, copies or moves the file to the new location, and
then recompresses the file. This behavior occurs even when the file is
copied or moved between folders on the same computer. Compressed files are
also expanded before copying over the network, so NTFS compression does not
save network bandwidth
--
HTH
Jasper Smith (SQL Server MVP)
I support PASS - the definitive, global
community for SQL Server professionals -
http://www.sqlpass.org
"Don Ferguson" <don@.nospamplease> wrote in message
news:eVy5m1wRDHA.1552@.TK2MSFTNGP10.phx.gbl...
If the compression attribute is set on both the source SQL Server directory
and the target SQL Server directory for a log shipping configuration, will
the log files be uncompressed and then recompressed when the copy is made?
Or will the files remain compressed while the copy is taking place? If
WIN2K and SS are smart enough to handle the latter, it will speed up the
transfer of files across a WAN link.|||Thanks Jasper!
Your response and the KB link answers my question even if this has nothing
to do with SQL Server.
I guess I need to look into SQL LiteSpeed or SQLZIP for a possible solution.
"Jasper Smith" <jasper_smith9@.hotmail.com> wrote in message
news:OZtmZexRDHA.2128@.TK2MSFTNGP12.phx.gbl...
> This is purely an OS thing, nothing to do with SQL.
> See the quote from the following KB article
> http://support.microsoft.com/?kbid=251186
> When you copy or move a compressed NTFS file to a different folder, NTFS
> decompresses the file, copies or moves the file to the new location, and
> then recompresses the file. This behavior occurs even when the file is
> copied or moved between folders on the same computer. Compressed files are
> also expanded before copying over the network, so NTFS compression does
not
> save network bandwidth
> --
> HTH
> Jasper Smith (SQL Server MVP)
> I support PASS - the definitive, global
> community for SQL Server professionals -
> http://www.sqlpass.org
> "Don Ferguson" <don@.nospamplease> wrote in message
> news:eVy5m1wRDHA.1552@.TK2MSFTNGP10.phx.gbl...
> If the compression attribute is set on both the source SQL Server
directory
> and the target SQL Server directory for a log shipping configuration, will
> the log files be uncompressed and then recompressed when the copy is made?
> Or will the files remain compressed while the copy is taking place? If
> WIN2K and SS are smart enough to handle the latter, it will speed up the
> transfer of files across a WAN link.
>
>|||I'm a big fan of SQL Litespeed, does exactly what it says on the tin :-)
--
HTH
Jasper Smith (SQL Server MVP)
I support PASS - the definitive, global
community for SQL Server professionals -
http://www.sqlpass.org
"Don Ferguson" <don@.nospamplease> wrote in message
news:evh15xxRDHA.2316@.tk2msftngp13.phx.gbl...
Thanks Jasper!
Your response and the KB link answers my question even if this has nothing
to do with SQL Server.
I guess I need to look into SQL LiteSpeed or SQLZIP for a possible solution.
"Jasper Smith" <jasper_smith9@.hotmail.com> wrote in message
news:OZtmZexRDHA.2128@.TK2MSFTNGP12.phx.gbl...
> This is purely an OS thing, nothing to do with SQL.
> See the quote from the following KB article
> http://support.microsoft.com/?kbid=251186
> When you copy or move a compressed NTFS file to a different folder, NTFS
> decompresses the file, copies or moves the file to the new location, and
> then recompresses the file. This behavior occurs even when the file is
> copied or moved between folders on the same computer. Compressed files are
> also expanded before copying over the network, so NTFS compression does
not
> save network bandwidth
> --
> HTH
> Jasper Smith (SQL Server MVP)
> I support PASS - the definitive, global
> community for SQL Server professionals -
> http://www.sqlpass.org
> "Don Ferguson" <don@.nospamplease> wrote in message
> news:eVy5m1wRDHA.1552@.TK2MSFTNGP10.phx.gbl...
> If the compression attribute is set on both the source SQL Server
directory
> and the target SQL Server directory for a log shipping configuration, will
> the log files be uncompressed and then recompressed when the copy is made?
> Or will the files remain compressed while the copy is taking place? If
> WIN2K and SS are smart enough to handle the latter, it will speed up the
> transfer of files across a WAN link.
>
>

Monday, March 12, 2012

Log shipping from SQL2000EE SP3 to SP4

Hi,
Source ==> SQL Server 2000 EE SP3
Target ==> SQL Server 2000 EE SP4
Does automated log shipping work for this configuration? Or log
shipping requires same service pack levels?
Thanks,
zrbThis is a multi-part message in MIME format.
--090403030908040509010200
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
That config should work (although it is preferable to have the same
service pack level on both servers so that if you have to point your
client code at the secondary server there are no post-SP3 bug surprises).
--
*mike hodgson*
blog: http://sqlnerd.blogspot.com
zrajbun@.hotmail.com wrote:
>Hi,
>Source ==> SQL Server 2000 EE SP3
>Target ==> SQL Server 2000 EE SP4
>Does automated log shipping work for this configuration? Or log
>shipping requires same service pack levels?
>Thanks,
>zrb
>
>
--090403030908040509010200
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>That config should work (although it is preferable to have the same
service pack level on both servers so that if you have to point your
client code at the secondary server there are no post-SP3 bug
surprises).</tt><br>
<div class="moz-signature">
<title></title>
<meta http-equiv="Content-Type" content="text/html; ">
<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</a></font></span>">http://sqlnerd.blogspot.com">http://sqlnerd.blogspot.com</a></font></span>
</p>
</div>
<br>
<br>
<a class="moz-txt-link-abbreviated" href="http://links.10026.com/?link=mailto:zrajbun@.hotmail.com">zrajbun@.hotmail.com</a> wrote:
<blockquote
cite="mid1124169030.671658.100080@.g49g2000cwa.googlegroups.com"
type="cite">
<pre wrap="">Hi,
Source ==> SQL Server 2000 EE SP3
Target ==> SQL Server 2000 EE SP4
Does automated log shipping work for this configuration? Or log
shipping requires same service pack levels?
Thanks,
zrb
</pre>
</blockquote>
</body>
</html>
--090403030908040509010200--|||Thank you Mike. I think I'll go with the same service pack levels,
keeping SP3.
b4n
zrb

Log shipping from SQL 2000 to SQL 2005

Is it possible to implement log shipping from SQL Server 2000 to SQL
Server 2005 where 2000 is the source and 2005 is the target. Can the
DB maintenance wizard be used, or does it need to be configured
manually?
Is log shipping possible where the source was 32 bit SQL 2000 and the
target is 64 bit SQL Server 2005?
Hi
SQL Server 2000 can be the source, SQL Server 2005 can be the target, but
not the other way around. As long as the DB remains in the loading state
this will work.
Once you issue the RESTORE <db> WITH RECOVERY command, the DB on the target
server gets upgraded.
32 or 64 bit does not play a role as the file formats are the same for all
the processor editions.
There is a bit of work to do after you bring the DB online due to some
tables no longer being used in SQL Server 2005.
The log shipping jobs on SQL Server 2000 need to be removed and replaced by
SQL Server 2005 log shipping. In effect, you need to re-configure log
shipping as soon as SQL Server 2005 gets involved.
There is a good set of instructions in BOL "Upgrading a SQL Server 2000 Log
Shipping Configuration"
ms-help://MS.SQLCC.v9/MS.SQLSVR.v9.en/udb9/html/70612059-b0d2-45a6-b74c-8cb3b9bdc921.htm
Mike Epprecht, Microsoft SQL Server MVP
Zurich, Switzerland
IM: mike@.epprecht.net
MVP Program: http://www.microsoft.com/mvp
Blog: http://www.msmvps.com/epprecht/
<luke.embree@.gmail.com> wrote in message
news:1131852208.603161.273030@.g14g2000cwa.googlegr oups.com...
> Is it possible to implement log shipping from SQL Server 2000 to SQL
> Server 2005 where 2000 is the source and 2005 is the target. Can the
> DB maintenance wizard be used, or does it need to be configured
> manually?
> Is log shipping possible where the source was 32 bit SQL 2000 and the
> target is 64 bit SQL Server 2005?
>

Log shipping from SQL 2000 to SQL 2005

Is it possible to implement log shipping from SQL Server 2000 to SQL
Server 2005 where 2000 is the source and 2005 is the target. Can the
DB maintenance wizard be used, or does it need to be configured
manually?
Is log shipping possible where the source was 32 bit SQL 2000 and the
target is 64 bit SQL Server 2005?Hi
SQL Server 2000 can be the source, SQL Server 2005 can be the target, but
not the other way around. As long as the DB remains in the loading state
this will work.
Once you issue the RESTORE <db> WITH RECOVERY command, the DB on the target
server gets upgraded.
32 or 64 bit does not play a role as the file formats are the same for all
the processor editions.
There is a bit of work to do after you bring the DB online due to some
tables no longer being used in SQL Server 2005.
The log shipping jobs on SQL Server 2000 need to be removed and replaced by
SQL Server 2005 log shipping. In effect, you need to re-configure log
shipping as soon as SQL Server 2005 gets involved.
There is a good set of instructions in BOL "Upgrading a SQL Server 2000 Log
Shipping Configuration"
ms-help://MS.SQLCC.v9/MS.SQLSVR.v9.en/udb9/html/70612059-b0d2-45a6-b74c-8cb3b9bdc921.htm
--
Mike Epprecht, Microsoft SQL Server MVP
Zurich, Switzerland
IM: mike@.epprecht.net
MVP Program: http://www.microsoft.com/mvp
Blog: http://www.msmvps.com/epprecht/
<luke.embree@.gmail.com> wrote in message
news:1131852208.603161.273030@.g14g2000cwa.googlegroups.com...
> Is it possible to implement log shipping from SQL Server 2000 to SQL
> Server 2005 where 2000 is the source and 2005 is the target. Can the
> DB maintenance wizard be used, or does it need to be configured
> manually?
> Is log shipping possible where the source was 32 bit SQL 2000 and the
> target is 64 bit SQL Server 2005?
>

Log shipping from SQL 2000 to SQL 2005

Is it possible to implement log shipping from SQL Server 2000 to SQL
Server 2005 where 2000 is the source and 2005 is the target. Can the
DB maintenance wizard be used, or does it need to be configured
manually?
Is log shipping possible where the source was 32 bit SQL 2000 and the
target is 64 bit SQL Server 2005?Hi
SQL Server 2000 can be the source, SQL Server 2005 can be the target, but
not the other way around. As long as the DB remains in the loading state
this will work.
Once you issue the RESTORE <db> WITH RECOVERY command, the DB on the target
server gets upgraded.
32 or 64 bit does not play a role as the file formats are the same for all
the processor editions.
There is a bit of work to do after you bring the DB online due to some
tables no longer being used in SQL Server 2005.
The log shipping jobs on SQL Server 2000 need to be removed and replaced by
SQL Server 2005 log shipping. In effect, you need to re-configure log
shipping as soon as SQL Server 2005 gets involved.
There is a good set of instructions in BOL "Upgrading a SQL Server 2000 Log
Shipping Configuration"
ms-help://MS.SQLCC.v9/MS.SQLSVR.v9.en/udb9/html/70612059-b0d2-45a6-b74c-8cb3
b9bdc921.htm
Mike Epprecht, Microsoft SQL Server MVP
Zurich, Switzerland
IM: mike@.epprecht.net
MVP Program: http://www.microsoft.com/mvp
Blog: http://www.msmvps.com/epprecht/
<luke.embree@.gmail.com> wrote in message
news:1131852208.603161.273030@.g14g2000cwa.googlegroups.com...
> Is it possible to implement log shipping from SQL Server 2000 to SQL
> Server 2005 where 2000 is the source and 2005 is the target. Can the
> DB maintenance wizard be used, or does it need to be configured
> manually?
> Is log shipping possible where the source was 32 bit SQL 2000 and the
> target is 64 bit SQL Server 2005?
>

Friday, February 24, 2012

Log shipping and database snapshots

SQL Server 2005
Can a database snapshot be created on a log ship target standby database so
that read-only reports and/or datamarts be ran' I know this is fully
supported when using Database Mirroring but Microsoft isn't supporting this
in production environments yet Didn't know what the limitations were with a
database in standby and snapshots.
Thanks"Kevin Jackson" <kjackson@.powerwayinc.com> wrote in message
news:u1gEwo3YGHA.1348@.TK2MSFTNGP05.phx.gbl...
> SQL Server 2005
> Can a database snapshot be created on a log ship target standby database
so
> that read-only reports and/or datamarts be ran'
Sort of.
If you use RESTORE with STANDBY (check BOL for exact syntax) you can turn
the DB into a read-only mode.
Then later logs can be applied to it.
However, note that when those logs apply there can't be any users in the
database or else they will fail to be restored.
In addition, while they are being restored, you won't be able to read from
the database.
These limitations may or may not be a problem. A typical scenario is to do
something like from 5:00 PM -9:00 AM apply log files as normal. At 9:00 AM
stop applying log files and allow reports to be run. At 5:00 PM kick all
users from the database and start applying logs again.

> I know this is fully
> supported when using Database Mirroring but Microsoft isn't supporting
this
> in production environments yet Didn't know what the limitations were with
a
> database in standby and snapshots.
> Thanks
>|||A Database Snapshot can be created against a Mirror or against a source
database. It can NOT be created against a database that is the target for
Log Shipping. The database has to either be online and accessible or in a
mirroring role to have a Database Snapshot created against it.
Mike
http://www.solidqualitylearning.com
Disclaimer: This communication is an original work and represents my sole
views on the subject. It does not represent the views of any other person
or entity either by inference or direct reference.
"Kevin Jackson" <kjackson@.powerwayinc.com> wrote in message
news:u1gEwo3YGHA.1348@.TK2MSFTNGP05.phx.gbl...
> SQL Server 2005
> Can a database snapshot be created on a log ship target standby database
> so that read-only reports and/or datamarts be ran' I know this is
> fully supported when using Database Mirroring but Microsoft isn't
> supporting this in production environments yet Didn't know what the
> limitations were with a database in standby and snapshots.
> Thanks
>

Log shipping and database snapshots

SQL Server 2005
Can a database snapshot be created on a log ship target standby database so
that read-only reports and/or datamarts be ran' I know this is fully
supported when using Database Mirroring but Microsoft isn't supporting this
in production environments yet Didn't know what the limitations were with a
database in standby and snapshots.
Thanks"Kevin Jackson" <kjackson@.powerwayinc.com> wrote in message
news:u1gEwo3YGHA.1348@.TK2MSFTNGP05.phx.gbl...
> SQL Server 2005
> Can a database snapshot be created on a log ship target standby database
so
> that read-only reports and/or datamarts be ran'
Sort of.
If you use RESTORE with STANDBY (check BOL for exact syntax) you can turn
the DB into a read-only mode.
Then later logs can be applied to it.
However, note that when those logs apply there can't be any users in the
database or else they will fail to be restored.
In addition, while they are being restored, you won't be able to read from
the database.
These limitations may or may not be a problem. A typical scenario is to do
something like from 5:00 PM -9:00 AM apply log files as normal. At 9:00 AM
stop applying log files and allow reports to be run. At 5:00 PM kick all
users from the database and start applying logs again.
> I know this is fully
> supported when using Database Mirroring but Microsoft isn't supporting
this
> in production environments yet Didn't know what the limitations were with
a
> database in standby and snapshots.
> Thanks
>|||A Database Snapshot can be created against a Mirror or against a source
database. It can NOT be created against a database that is the target for
Log Shipping. The database has to either be online and accessible or in a
mirroring role to have a Database Snapshot created against it.
--
Mike
http://www.solidqualitylearning.com
Disclaimer: This communication is an original work and represents my sole
views on the subject. It does not represent the views of any other person
or entity either by inference or direct reference.
"Kevin Jackson" <kjackson@.powerwayinc.com> wrote in message
news:u1gEwo3YGHA.1348@.TK2MSFTNGP05.phx.gbl...
> SQL Server 2005
> Can a database snapshot be created on a log ship target standby database
> so that read-only reports and/or datamarts be ran' I know this is
> fully supported when using Database Mirroring but Microsoft isn't
> supporting this in production environments yet Didn't know what the
> limitations were with a database in standby and snapshots.
> Thanks
>