Log Shipping Question

Hi,
I would like to implement Log Shipping to my company and I have everything
set up and work fine. However, I am not sure how to ship the database backu
p
file to the destination server after the first time. Since the log shipping
function only ships the log file, if I want to also ship the backup file,
what i need to do?
I have log shipping set up every 15 mins from 8:30 a.m. to 5:30 p.m.
(regular working hour). However, I would like to restore the database backu
p
at night 3:00 a.m. but the log shipping doesn't provide the database copy an
d
restore... I need to write the script by myself? like copy //... ... and
write the Retore command?
Please advise.
Thanks
EdIf you are using the built-in log shipping mechanism in SQL Server ( which
is a part of the Database Maintenance Plan wizard ), it allows you to ship
the initial snap shot of the database and the subsequent logs. Once the
initial snap shot ( full database backup file ) is copied and restored at
the destination server, the log backup shipping starts.
Alternatively, you can write up your own backup/ copy/ restore scripts with
a table or two maintaining the log file names and history of actions, which
many DBAs find very easy and simple to manage. It also allows them to have
customized alerting mechanisms and provides for easy recovery/reapply
options in case of out of sync issues between the source and destinations.
Anith

Log shipping question

My company is embarking on a DRP project where we will move our production
servers to a less geographically insecure area. We'll need to perform log
shipping back to our DRP site.
I know that SQL Server logs index rebuilds or index defragmentation and that
we perform rebuilds regularly so I have a few questions if anyone can help:
1.. Can we stop index builds from being logged?
2.. If we cannot stop index logging, are there any different practices we
can follow to do index maintenance that will not require logging (e.g.
defrag)
Does anyone have any experience of this?
If we were to ship index rebuilds or defragmentation, we'll be shipping
gigabytes of unnecessary data, but apparently SQL Server will not let this
be switched off?
Thanks.
Bill
If you don't log operations, the forth coming log backup would not be useful. You cannot eat the
cake and have it. :-)
You could look into bulk logged recovery mode, but a log backup in this mode will include data (not
log records) modified by minimally logged operations. I doubt you will gain much, if anything.
Your best bet is to only rebuild if you need to. A start is to use the code in Books Online, DBCC
SHOWCONTIG which only do rebuild if frag level is > a certain level. You can customize this further
and rebuild different indexes at different times.
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://www.solidqualitylearning.com/
"Bill Wang" <wdw2130833@.hotmail.com> wrote in message
news:9fTle.28354$Ot6.1561166@.news20.bellglobal.com ...
> My company is embarking on a DRP project where we will move our production
> servers to a less geographically insecure area. We'll need to perform log
> shipping back to our DRP site.
> I know that SQL Server logs index rebuilds or index defragmentation and that
> we perform rebuilds regularly so I have a few questions if anyone can help:
> 1.. Can we stop index builds from being logged?
> 2.. If we cannot stop index logging, are there any different practices we
> can follow to do index maintenance that will not require logging (e.g.
> defrag)
> Does anyone have any experience of this?
> If we were to ship index rebuilds or defragmentation, we'll be shipping
> gigabytes of unnecessary data, but apparently SQL Server will not let this
> be switched off?
> Thanks.
>
> Bill
>

Log shipping question

My company is embarking on a DRP project where we will move our production
servers to a less geographically insecure area. We'll need to perform log
shipping back to our DRP site.
I know that SQL Server logs index rebuilds or index defragmentation and that
we perform rebuilds regularly so I have a few questions if anyone can help:
1.. Can we stop index builds from being logged?
2.. If we cannot stop index logging, are there any different practices we
can follow to do index maintenance that will not require logging (e.g.
defrag)
Does anyone have any experience of this?
If we were to ship index rebuilds or defragmentation, we'll be shipping
gigabytes of unnecessary data, but apparently SQL Server will not let this
be switched off?
Thanks.
BillIf you don't log operations, the forth coming log backup would not be useful
. You cannot eat the
cake and have it. :-)
You could look into bulk logged recovery mode, but a log backup in this mode
will include data (not
log records) modified by minimally logged operations. I doubt you will gain
much, if anything.
Your best bet is to only rebuild if you need to. A start is to use the code
in Books Online, DBCC
SHOWCONTIG which only do rebuild if frag level is > a certain level. You can
customize this further
and rebuild different indexes at different times.
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://www.solidqualitylearning.com/
"Bill Wang" <wdw2130833@.hotmail.com> wrote in message
news:9fTle.28354$Ot6.1561166@.news20.bellglobal.com...
> My company is embarking on a DRP project where we will move our production
> servers to a less geographically insecure area. We'll need to perform log
> shipping back to our DRP site.
> I know that SQL Server logs index rebuilds or index defragmentation and th
at
> we perform rebuilds regularly so I have a few questions if anyone can help
:
> 1.. Can we stop index builds from being logged?
> 2.. If we cannot stop index logging, are there any different practices we
> can follow to do index maintenance that will not require logging (e.g.
> defrag)
> Does anyone have any experience of this?
> If we were to ship index rebuilds or defragmentation, we'll be shipping
> gigabytes of unnecessary data, but apparently SQL Server will not let this
> be switched off?
> Thanks.
>
> Bill
>

Log shipping question

My company is embarking on a DRP project where we will move our production
servers to a less geographically insecure area. We'll need to perform log
shipping back to our DRP site.
I know that SQL Server logs index rebuilds or index defragmentation and that
we perform rebuilds regularly so I have a few questions if anyone can help:
1.. Can we stop index builds from being logged?
2.. If we cannot stop index logging, are there any different practices we
can follow to do index maintenance that will not require logging (e.g.
defrag)
Does anyone have any experience of this?
If we were to ship index rebuilds or defragmentation, we'll be shipping
gigabytes of unnecessary data, but apparently SQL Server will not let this
be switched off?
Thanks.
BillIf you don't log operations, the forth coming log backup would not be useful. You cannot eat the
cake and have it. :-)
You could look into bulk logged recovery mode, but a log backup in this mode will include data (not
log records) modified by minimally logged operations. I doubt you will gain much, if anything.
Your best bet is to only rebuild if you need to. A start is to use the code in Books Online, DBCC
SHOWCONTIG which only do rebuild if frag level is > a certain level. You can customize this further
and rebuild different indexes at different times.
--
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://www.solidqualitylearning.com/
"Bill Wang" <wdw2130833@.hotmail.com> wrote in message
news:9fTle.28354$Ot6.1561166@.news20.bellglobal.com...
> My company is embarking on a DRP project where we will move our production
> servers to a less geographically insecure area. We'll need to perform log
> shipping back to our DRP site.
> I know that SQL Server logs index rebuilds or index defragmentation and that
> we perform rebuilds regularly so I have a few questions if anyone can help:
> 1.. Can we stop index builds from being logged?
> 2.. If we cannot stop index logging, are there any different practices we
> can follow to do index maintenance that will not require logging (e.g.
> defrag)
> Does anyone have any experience of this?
> If we were to ship index rebuilds or defragmentation, we'll be shipping
> gigabytes of unnecessary data, but apparently SQL Server will not let this
> be switched off?
> Thanks.
>
> Bill
>

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

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
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

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

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.comNever tried it yet but it should work as far as I know. You can take a 32 b
it 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 st
ructures do not change.
--
Andrew J. Kelly SQL MVP
"Mike Hodgson" <mike.hodgson@.mallesons.nospam.com> wrote in message news:uH9
URVImFHA.1148@.TK2MSFTNGP12.phx.gbl...
My company is considering a new Itanium cluster in our production environmen
t. 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 instanc
es to our 32-bit DR SQL instances. After a little thought I said it would p
robably 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 of
f 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 lik
e 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 Mic
rosoft? Can the log shipping monitor run on a 32-bit instance?
mike hodgson
blog: http://sqlnerd.blogspot.com

Log shipping and index rebuilds

Hi everyone.
My company is embarking on a DRP project where we will move our production s
ervers to a less geographically insecure area. We'll need to perform log shi
pping back to our DRP site here in Vancouver Canada.
I just learned today that SQL Server logs index rebuilds and that we perform
rebuilds regularly so I have a few questions if anyone can help:
Can we stop index builds from being logged?
If we cannot stop index logging, are there any different practices we can fo
llow to do index maintenance that will not require logging (e.g. defrag)
Are there best practices around log shipping for MS-SQL that will maximize o
ur use of bandwidth?
Does anyone have any experience of this?
If we were to ship index rebuilds, we'll be shipping gigabytes of unnecessar
y data, but apparently SQL Server will not let this be switched off?
Thanks.
David.David,
I have implemented LogShipping at my site and understand your questions. For
the most indepth information on LogShipping and High Availability, check ou
t this book. You will find that it answers all of your questions and way mor
e.
SQL Server 2000 High Availability.
It's from Microsoft Press and it discusses everything you may want to know.
This may be not the answer you were expecting, but I am sure once you pick u
p the book that you will have answers to questions you didn't know you had.
Lisa
"davidbailie" wrote:

> Hi everyone.
> My company is embarking on a DRP project where we will move our production
servers to a less geographically insecure area. We'll need to perform log s
hipping back to our DRP site here in Vancouver Canada.
> I just learned today that SQL Server logs index rebuilds and that we perfo
rm rebuilds regularly so I have a few questions if anyone can help:
> Can we stop index builds from being logged?
> If we cannot stop index logging, are there any different practices we can
follow to do index maintenance that will not require logging (e.g. defrag)
> Are there best practices around log shipping for MS-SQL that will maximize
our use of bandwidth?
> Does anyone have any experience of this?
> If we were to ship index rebuilds, we'll be shipping gigabytes of unnecess
ary data, but apparently SQL Server will not let this be switched off?
> Thanks.
> David.
>|||Lisa, thanks very much for your reply. I happen to have that book (one of th
e many I haven't even opened yet). But I'll take a look through it.
Thanks again,
David.
--
David Bailie
Ernex
Vancouver, BC.
Canada
"Ora/SQL DBA" wrote:
[vbcol=seagreen]
> David,
> I have implemented LogShipping at my site and understand your questions. F
or the most indepth information on LogShipping and High Availability, check
out this book. You will find that it answers all of your questions and way m
ore.
> SQL Server 2000 High Availability.
> It's from Microsoft Press and it discusses everything you may want to know
.
> This may be not the answer you were expecting, but I am sure once you pick
up the book that you will have answers to questions you didn't know you had
.
> Lisa
> "davidbailie" wrote:
>

Log shipping and index rebuilds

Hi everyone.
My company is embarking on a DRP project where we will move our production servers to a less geographically insecure area. We'll need to perform log shipping back to our DRP site here in Vancouver Canada.
I just learned today that SQL Server logs index rebuilds and that we perform rebuilds regularly so I have a few questions if anyone can help:
Can we stop index builds from being logged?
If we cannot stop index logging, are there any different practices we can follow to do index maintenance that will not require logging (e.g. defrag)
Are there best practices around log shipping for MS-SQL that will maximize our use of bandwidth?
Does anyone have any experience of this?
If we were to ship index rebuilds, we'll be shipping gigabytes of unnecessary data, but apparently SQL Server will not let this be switched off?
Thanks.
David.
David,
I have implemented LogShipping at my site and understand your questions. For the most indepth information on LogShipping and High Availability, check out this book. You will find that it answers all of your questions and way more.
SQL Server 2000 High Availability.
It's from Microsoft Press and it discusses everything you may want to know.
This may be not the answer you were expecting, but I am sure once you pick up the book that you will have answers to questions you didn't know you had.
Lisa
"davidbailie" wrote:

> Hi everyone.
> My company is embarking on a DRP project where we will move our production servers to a less geographically insecure area. We'll need to perform log shipping back to our DRP site here in Vancouver Canada.
> I just learned today that SQL Server logs index rebuilds and that we perform rebuilds regularly so I have a few questions if anyone can help:
> Can we stop index builds from being logged?
> If we cannot stop index logging, are there any different practices we can follow to do index maintenance that will not require logging (e.g. defrag)
> Are there best practices around log shipping for MS-SQL that will maximize our use of bandwidth?
> Does anyone have any experience of this?
> If we were to ship index rebuilds, we'll be shipping gigabytes of unnecessary data, but apparently SQL Server will not let this be switched off?
> Thanks.
> David.
>
|||Lisa, thanks very much for your reply. I happen to have that book (one of the many I haven't even opened yet). But I'll take a look through it.
Thanks again,
David.
David Bailie
Ernex
Vancouver, BC.
Canada
"Ora/SQL DBA" wrote:
[vbcol=seagreen]
> David,
> I have implemented LogShipping at my site and understand your questions. For the most indepth information on LogShipping and High Availability, check out this book. You will find that it answers all of your questions and way more.
> SQL Server 2000 High Availability.
> It's from Microsoft Press and it discusses everything you may want to know.
> This may be not the answer you were expecting, but I am sure once you pick up the book that you will have answers to questions you didn't know you had.
> Lisa
> "davidbailie" wrote:

Log shipping and index rebuilds

Hi everyone.
My company is embarking on a DRP project where we will move our production servers to a less geographically insecure area. We'll need to perform log shipping back to our DRP site here in Vancouver Canada.
I just learned today that SQL Server logs index rebuilds and that we perform rebuilds regularly so I have a few questions if anyone can help:
Can we stop index builds from being logged?
If we cannot stop index logging, are there any different practices we can follow to do index maintenance that will not require logging (e.g. defrag)
Are there best practices around log shipping for MS-SQL that will maximize our use of bandwidth?
Does anyone have any experience of this?
If we were to ship index rebuilds, we'll be shipping gigabytes of unnecessary data, but apparently SQL Server will not let this be switched off?
Thanks.
David.David,
I have implemented LogShipping at my site and understand your questions. For the most indepth information on LogShipping and High Availability, check out this book. You will find that it answers all of your questions and way more.
SQL Server 2000 High Availability.
It's from Microsoft Press and it discusses everything you may want to know.
This may be not the answer you were expecting, but I am sure once you pick up the book that you will have answers to questions you didn't know you had.
Lisa
"davidbailie" wrote:
> Hi everyone.
> My company is embarking on a DRP project where we will move our production servers to a less geographically insecure area. We'll need to perform log shipping back to our DRP site here in Vancouver Canada.
> I just learned today that SQL Server logs index rebuilds and that we perform rebuilds regularly so I have a few questions if anyone can help:
> Can we stop index builds from being logged?
> If we cannot stop index logging, are there any different practices we can follow to do index maintenance that will not require logging (e.g. defrag)
> Are there best practices around log shipping for MS-SQL that will maximize our use of bandwidth?
> Does anyone have any experience of this?
> If we were to ship index rebuilds, we'll be shipping gigabytes of unnecessary data, but apparently SQL Server will not let this be switched off?
> Thanks.
> David.
>