log shipping question on two databases

Hi,
I created 2 log shipping plans at the same time, for database dbA and dbB
respectively, to ship logs to antother database server.
All the log transaction schedule and location are the same.
However, only log shipping plan for dbA succeed.
Is there any restriction on log shipping for 2 databases at the same time?
Thanks for help.
Jason
No, there is no such restriction. You can can configure two databases from
the same instance for log shipping.
Ben Nevarez
Senior Database Administrator
AIG SunAmerica
"Jason Huang" wrote:

> Hi,
> I created 2 log shipping plans at the same time, for database dbA and dbB
> respectively, to ship logs to antother database server.
> All the log transaction schedule and location are the same.
> However, only log shipping plan for dbA succeed.
> Is there any restriction on log shipping for 2 databases at the same time?
> Thanks for help.
>
> Jason
>
>

log shipping question on two databases

Hi,
I created 2 log shipping plans at the same time, for database dbA and dbB
respectively, to ship logs to antother database server.
All the log transaction schedule and location are the same.
However, only log shipping plan for dbA succeed.
Is there any restriction on log shipping for 2 databases at the same time?
Thanks for help.
JasonNo, there is no such restriction. You can can configure two databases from
the same instance for log shipping.
Ben Nevarez
Senior Database Administrator
AIG SunAmerica
"Jason Huang" wrote:

> Hi,
> I created 2 log shipping plans at the same time, for database dbA and dbB
> respectively, to ship logs to antother database server.
> All the log transaction schedule and location are the same.
> However, only log shipping plan for dbA succeed.
> Is there any restriction on log shipping for 2 databases at the same time?
> Thanks for help.
>
> Jason
>
>

log shipping question on two databases

Hi,
I created 2 log shipping plans at the same time, for database dbA and dbB
respectively, to ship logs to antother database server.
All the log transaction schedule and location are the same.
However, only log shipping plan for dbA succeed.
Is there any restriction on log shipping for 2 databases at the same time?
Thanks for help.
JasonNo, there is no such restriction. You can can configure two databases from
the same instance for log shipping.
Ben Nevarez
Senior Database Administrator
AIG SunAmerica
"Jason Huang" wrote:
> Hi,
> I created 2 log shipping plans at the same time, for database dbA and dbB
> respectively, to ship logs to antother database server.
> All the log transaction schedule and location are the same.
> However, only log shipping plan for dbA succeed.
> Is there any restriction on log shipping for 2 databases at the same time?
> Thanks for help.
>
> Jason
>
>

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

While reviewing our log shipping setup, I noticed we backup, ship and restore
logs from 7am-7pm. We also perform a full backup at 9pm.
My question is this: Will the transaction backup at 7am pick up
transactions since the last transaction log backup at 7pm or since the full
backup at 9PM. Are we losing 2 hours of transactions?
SqlServer2005 SP2.
Thanks.
Ron
Full and transaction logs are almost completely independent. Almost means
that you have to have a full backup to initialize the log chain. After
that, a full backup has no impact on the transaction log backups. For
example, if last night's backup was bad, you can go back two days and
restore logs up to today. As a side effect, full backups do not mark any
part of the transaction log as inactive so transaction log backups are
necessary to truncate a log when in full recovery mode.
Each log backup consists of the completed and checkpointed transactions
since the last transaction log backup. Once these transactions are backed
up, the log space is marked inactive and can be reused.
Geoff N. Hiten
Senior SQL Infrastructure Consultant
Microsoft SQL Server MVP
"Ron" <Ron@.discussions.microsoft.com> wrote in message
news:4A35A3CB-E733-4AE5-9780-1DACB82C9ABE@.microsoft.com...
> While reviewing our log shipping setup, I noticed we backup, ship and
> restore
> logs from 7am-7pm. We also perform a full backup at 9pm.
> My question is this: Will the transaction backup at 7am pick up
> transactions since the last transaction log backup at 7pm or since the
> full
> backup at 9PM. Are we losing 2 hours of transactions?
> SqlServer2005 SP2.
> Thanks.
> Ron

Log Shipping Problem

Hello Everyone. I am log shippping on a server that has heavy reads and
writes. The Log Ship process runs every 15 minutes and when it runs, it
tends to significantly slow down all the queries running on the box. Queries
which run 20-100 milliseconds run for over 2-3 seconds. The slowing causes
are webservers to back up which in turn slows are website.
I notice in PerMon that after every transaction log backup a checkpoint is
run immedialty after.
The queries are slow during the checkpoint process.
Is there a reason for this? Also, how can I avoid this slow down.
About the Server:
Windows 2003 Enterprise Edition
Quad processeor with Intel XEON 3.0 Ghz.
SQL 2000 version 8.00.936
Thanks,
George
George
There is no real way to avoid the checkpoint process. The checkpoint process
tells SQL Server to write completed transactions to disk, something you
obviously want to happen. You can make the gap between checkpoints longer by
altering the recovery interval. However if you do that the checkpoints will
last longer when they do happen (they will have more to do) and your
transation logs will probably get bigger, and you system will take longer to
come up following a reboot.
About the only thing you can do is look at your disk configuration, to see
if there is a way to speed up your I/O processes.
Hope this helps
John
"George teVelde" wrote:

> Hello Everyone. I am log shippping on a server that has heavy reads and
> writes. The Log Ship process runs every 15 minutes and when it runs, it
> tends to significantly slow down all the queries running on the box. Queries
> which run 20-100 milliseconds run for over 2-3 seconds. The slowing causes
> are webservers to back up which in turn slows are website.
> I notice in PerMon that after every transaction log backup a checkpoint is
> run immedialty after.
> The queries are slow during the checkpoint process.
> Is there a reason for this? Also, how can I avoid this slow down.
> About the Server:
> Windows 2003 Enterprise Edition
> Quad processeor with Intel XEON 3.0 Ghz.
> SQL 2000 version 8.00.936
> Thanks,
> George
|||Thanks for the reply, I have one more question.
Is there any reason Log Shipping would grab all the availble threads and not
release them?
I realize that it may not be the log shipping doing it, but I am trying to
eliminate as many variables as I can.
Thanks.
|||Hi
No, no reason. If checkpointing affects your performance, the disk layout is
probably not optimal. Basic rule, Logs on a separate set of drive, not on
RAID-5, but on mirrors.
Regards
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/
"George teVelde" <GeorgeteVelde@.discussions.microsoft.com> wrote in message
news:69243841-B076-4990-84E1-4C38A7FA4548@.microsoft.com...
> Thanks for the reply, I have one more question.
> Is there any reason Log Shipping would grab all the availble threads and
not
> release them?
> I realize that it may not be the log shipping doing it, but I am trying to
> eliminate as many variables as I can.
> Thanks.

Log Shipping Problem

Hello Everyone. I am log shippping on a server that has heavy reads and
writes. The Log Ship process runs every 15 minutes and when it runs, it
tends to significantly slow down all the queries running on the box. Querie
s
which run 20-100 milliseconds run for over 2-3 seconds. The slowing causes
are webservers to back up which in turn slows are website.
I notice in PerMon that after every transaction log backup a checkpoint is
run immedialty after.
The queries are slow during the checkpoint process.
Is there a reason for this? Also, how can I avoid this slow down.
About the Server:
Windows 2003 Enterprise Edition
Quad processeor with Intel XEON 3.0 Ghz.
SQL 2000 version 8.00.936
Thanks,
GeorgeGeorge
There is no real way to avoid the checkpoint process. The checkpoint process
tells SQL Server to write completed transactions to disk, something you
obviously want to happen. You can make the gap between checkpoints longer by
altering the recovery interval. However if you do that the checkpoints will
last longer when they do happen (they will have more to do) and your
transation logs will probably get bigger, and you system will take longer to
come up following a reboot.
About the only thing you can do is look at your disk configuration, to see
if there is a way to speed up your I/O processes.
Hope this helps
John
"George teVelde" wrote:

> Hello Everyone. I am log shippping on a server that has heavy reads and
> writes. The Log Ship process runs every 15 minutes and when it runs, it
> tends to significantly slow down all the queries running on the box. Quer
ies
> which run 20-100 milliseconds run for over 2-3 seconds. The slowing cause
s
> are webservers to back up which in turn slows are website.
> I notice in PerMon that after every transaction log backup a checkpoint is
> run immedialty after.
> The queries are slow during the checkpoint process.
> Is there a reason for this? Also, how can I avoid this slow down.
> About the Server:
> Windows 2003 Enterprise Edition
> Quad processeor with Intel XEON 3.0 Ghz.
> SQL 2000 version 8.00.936
> Thanks,
> George|||Thanks for the reply, I have one more question.
Is there any reason Log Shipping would grab all the availble threads and not
release them?
I realize that it may not be the log shipping doing it, but I am trying to
eliminate as many variables as I can.
Thanks.|||Hi
No, no reason. If checkpointing affects your performance, the disk layout is
probably not optimal. Basic rule, Logs on a separate set of drive, not on
RAID-5, but on mirrors.
Regards
--
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/
"George teVelde" <GeorgeteVelde@.discussions.microsoft.com> wrote in message
news:69243841-B076-4990-84E1-4C38A7FA4548@.microsoft.com...
> Thanks for the reply, I have one more question.
> Is there any reason Log Shipping would grab all the availble threads and
not
> release them?
> I realize that it may not be the log shipping doing it, but I am trying to
> eliminate as many variables as I can.
> Thanks.sql

Log Shipping Problem

Hello Everyone. I am log shippping on a server that has heavy reads and
writes. The Log Ship process runs every 15 minutes and when it runs, it
tends to significantly slow down all the queries running on the box. Queries
which run 20-100 milliseconds run for over 2-3 seconds. The slowing causes
are webservers to back up which in turn slows are website.
I notice in PerMon that after every transaction log backup a checkpoint is
run immedialty after.
The queries are slow during the checkpoint process.
Is there a reason for this? Also, how can I avoid this slow down.
About the Server:
Windows 2003 Enterprise Edition
Quad processeor with Intel XEON 3.0 Ghz.
SQL 2000 version 8.00.936
Thanks,
GeorgeGeorge
There is no real way to avoid the checkpoint process. The checkpoint process
tells SQL Server to write completed transactions to disk, something you
obviously want to happen. You can make the gap between checkpoints longer by
altering the recovery interval. However if you do that the checkpoints will
last longer when they do happen (they will have more to do) and your
transation logs will probably get bigger, and you system will take longer to
come up following a reboot.
About the only thing you can do is look at your disk configuration, to see
if there is a way to speed up your I/O processes.
Hope this helps
John
"George teVelde" wrote:
> Hello Everyone. I am log shippping on a server that has heavy reads and
> writes. The Log Ship process runs every 15 minutes and when it runs, it
> tends to significantly slow down all the queries running on the box. Queries
> which run 20-100 milliseconds run for over 2-3 seconds. The slowing causes
> are webservers to back up which in turn slows are website.
> I notice in PerMon that after every transaction log backup a checkpoint is
> run immedialty after.
> The queries are slow during the checkpoint process.
> Is there a reason for this? Also, how can I avoid this slow down.
> About the Server:
> Windows 2003 Enterprise Edition
> Quad processeor with Intel XEON 3.0 Ghz.
> SQL 2000 version 8.00.936
> Thanks,
> George|||Thanks for the reply, I have one more question.
Is there any reason Log Shipping would grab all the availble threads and not
release them?
I realize that it may not be the log shipping doing it, but I am trying to
eliminate as many variables as I can.
Thanks.|||Hi
No, no reason. If checkpointing affects your performance, the disk layout is
probably not optimal. Basic rule, Logs on a separate set of drive, not on
RAID-5, but on mirrors.
Regards
--
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/
"George teVelde" <GeorgeteVelde@.discussions.microsoft.com> wrote in message
news:69243841-B076-4990-84E1-4C38A7FA4548@.microsoft.com...
> Thanks for the reply, I have one more question.
> Is there any reason Log Shipping would grab all the availble threads and
not
> release them?
> I realize that it may not be the log shipping doing it, but I am trying to
> eliminate as many variables as I can.
> Thanks.

Log Shipping Multi Instances

Can you cross log ship across multiple instances using both servers?If I understand you correctly, then yes (Enterprise
edition only)
>--Original Message--
>Can you cross log ship across multiple instances using
both servers?
>.
>|||Cindy, what do you mean by "cross log ship"? Do you mean setting up a log
shipping pair where the primary & secondary servers are two distinct named
SQL instances on a single physical server? If so, then yes (as Jono said)
but why would you want to (I can't think of any good reasons)?
"Jono" <anonymous@.discussions.microsoft.com> wrote in message
news:884201c4d126$ef9e06d0$a601280a@.phx.gbl...
> If I understand you correctly, then yes (Enterprise
> edition only)
>>--Original Message--
>>Can you cross log ship across multiple instances using
> both servers?
>>.

Log Shipping Multi Instances

If I understand you correctly, then yes (Enterprise
edition only)

>--Original Message--
>Can you cross log ship across multiple instances using
both servers?
>.
>
Cindy, what do you mean by "cross log ship"? Do you mean setting up a log
shipping pair where the primary & secondary servers are two distinct named
SQL instances on a single physical server? If so, then yes (as Jono said)
but why would you want to (I can't think of any good reasons)?
"Jono" <anonymous@.discussions.microsoft.com> wrote in message
news:884201c4d126$ef9e06d0$a601280a@.phx.gbl...[vbcol=seagreen]
> If I understand you correctly, then yes (Enterprise
> edition only)
> both servers?
sql

Log Shipping Multi Instances

If I understand you correctly, then yes (Enterprise
edition only)

>--Original Message--
>Can you cross log ship across multiple instances using
both servers?
>.
>Cindy, what do you mean by "cross log ship"? Do you mean setting up a log
shipping pair where the primary & secondary servers are two distinct named
SQL instances on a single physical server? If so, then yes (as Jono said)
but why would you want to (I can't think of any good reasons)?
"Jono" <anonymous@.discussions.microsoft.com> wrote in message
news:884201c4d126$ef9e06d0$a601280a@.phx.gbl...[vbcol=seagreen]
> If I understand you correctly, then yes (Enterprise
> edition only)
>
> both servers?

Log shipping goes out of sync

Hi
I have two SQL 2000 boxes setup to log ship. The box being shipped to
is also the monitor
The size of the db being shipped is around 110GB - so the initial log
ship first creates and copies across the entire db (takes a while)
then begins the transaction logs.
The problem is that the log ship goes out of sync also immediately -
from testing I've managed to get the first shipped transaction log to
load, and sometimes the second, but never further as it gets out of
sync.
Things I've tried:
Changing the schedule from the default 15 minutes to 2 hours (for copy
and load)
Ensuring the log ship process doesn't clash with a routine backup
Any suggestions?
Thanks
Toby
On Feb 19, 7:40 am, "Toby" <tjbeaum...@.gmail.com> wrote:
> Hi
> I have two SQL 2000 boxes setup to log ship. The box being shipped to
> is also the monitor
> The size of the db being shipped is around 110GB - so the initial log
> ship first creates and copies across the entire db (takes a while)
> then begins the transaction logs.
> The problem is that the log ship goes out of sync also immediately -
> from testing I've managed to get the first shipped transaction log to
> load, and sometimes the second, but never further as it gets out of
> sync.
> Things I've tried:
> Changing the schedule from the default 15 minutes to 2 hours (for copy
> and load)
> Ensuring the log ship process doesn't clash with a routine backup
> Any suggestions?
> Thanks
> Toby
Please explain this further:
"Ensuring the log ship process doesn't clash with a routine backup"
Are you running transaction log backups IN ADDITION to the log
shipping process? This will break the log shipping chain. Log
shipping works by taking a backup of the transaction log and restoring
that backup onto another database. If you run your own independent
log backup, you're advancing the LSN pointer, throwing the log
shipping backups out of sync.

Log shipping goes out of sync

Hi
I have two SQL 2000 boxes setup to log ship. The box being shipped to
is also the monitor
The size of the db being shipped is around 110GB - so the initial log
ship first creates and copies across the entire db (takes a while)
then begins the transaction logs.
The problem is that the log ship goes out of sync also immediately -
from testing I've managed to get the first shipped transaction log to
load, and sometimes the second, but never further as it gets out of
sync.
Things I've tried:
Changing the schedule from the default 15 minutes to 2 hours (for copy
and load)
Ensuring the log ship process doesn't clash with a routine backup
Any suggestions?
Thanks
TobyOn Feb 19, 7:40 am, "Toby" <tjbeaum...@.gmail.com> wrote:
> Hi
> I have two SQL 2000 boxes setup to log ship. The box being shipped to
> is also the monitor
> The size of the db being shipped is around 110GB - so the initial log
> ship first creates and copies across the entire db (takes a while)
> then begins the transaction logs.
> The problem is that the log ship goes out of sync also immediately -
> from testing I've managed to get the first shipped transaction log to
> load, and sometimes the second, but never further as it gets out of
> sync.
> Things I've tried:
> Changing the schedule from the default 15 minutes to 2 hours (for copy
> and load)
> Ensuring the log ship process doesn't clash with a routine backup
> Any suggestions?
> Thanks
> Toby
Please explain this further:
"Ensuring the log ship process doesn't clash with a routine backup"
Are you running transaction log backups IN ADDITION to the log
shipping process? This will break the log shipping chain. Log
shipping works by taking a backup of the transaction log and restoring
that backup onto another database. If you run your own independent
log backup, you're advancing the LSN pointer, throwing the log
shipping backups out of sync.|||Hi
In reply to your question "Are you running transaction log backups IN
ADDITION to the log[vbcol=seagreen]
> shipping process? " - the answer is yes I am, so clearly here lies the problem.[/v
bcol]
I'm running a daily log backup, truncate and shrink - which I realise
now is going to cause issues with the log shipping. However, and
forgive me if this appears trivial, but the reason for run a log
backup, truncate and shrink is to prevent the log file getting too
big, as it currently grows at the rate of 20-30gb a day. If I rely on
the log shipping process only, will this provide adequate truncating
of the log?
Thanks|||On Feb 22, 2:48 pm, "Toby" <tjbeaum...@.gmail.com> wrote:
> Hi
> In reply to your question "Are you running transaction log backups IN
> ADDITION to the log
>
> I'm running a daily log backup, truncate and shrink - which I realise
> now is going to cause issues with the log shipping. However, and
> forgive me if this appears trivial, but the reason for run a log
> backup, truncate and shrink is to prevent the log file getting too
> big, as it currently grows at the rate of 20-30gb a day. If I rely on
> the log shipping process only, will this provide adequate truncating
> of the log?
> Thanks
Couple of key things here:
1. Log backups truncate the log - the more frequently that you run a
log backup, the quicker committed transactions will get truncated, and
the less likely your log is to grow. Note that LARGE transactions can
still cause growth, because they can't be truncated until fully
committed.
2. You are hurting your overall performance in one, possibly two,
ways. By repeatedly shrinking the log file, you are forcing SQL
Server to grow it again as needed, which introduces additional
overhead, possibly during a busy period. Also, repeatedly growing/
shrinking/growing/shrinking will lead to disk fragmentation, which
will also ultimately hurt your performance.
My advice would be to not use the log-shipping wizard that is built-
in. You can kill two birds with one stone by writing your own backup
routines. Create a log backup job that runs every hour (we do 5-
minute intervals here), have that job create backup files that contain
a date/time stamp, place these files into some folder, let's say
"FolderX". Write a log-shipping routine that monitors FolderX for new
files. When a new file is detected, your log shipping routine should
restore it and record the file name in a logging table. It then goes
back to monitoring FolderX for new files that aren't in the logging
table.
It's really not as complicated as it seems, and you'll solve all of
these problems...|||On 22 Feb, 21:06, "Tracy McKibben" <tracy.mckib...@.gmail.com> wrote:
> On Feb 22, 2:48 pm, "Toby" <tjbeaum...@.gmail.com> wrote:
>
>
>
>
>
>
> Couple of key things here:
> 1. Log backups truncate the log - the more frequently that you run a
> log backup, the quicker committed transactions will get truncated, and
> the less likely your log is to grow. Note that LARGE transactions can
> still cause growth, because they can't be truncated until fully
> committed.
> 2. You are hurting your overall performance in one, possibly two,
> ways. By repeatedly shrinking the log file, you are forcing SQL
> Server to grow it again as needed, which introduces additional
> overhead, possibly during a busy period. Also, repeatedly growing/
> shrinking/growing/shrinking will lead to disk fragmentation, which
> will also ultimately hurt your performance.
> My advice would be to not use the log-shipping wizard that is built-
> in. You can kill two birds with one stone by writing your own backup
> routines. Create a log backup job that runs every hour (we do 5-
> minute intervals here), have that job create backup files that contain
> a date/time stamp, place these files into some folder, let's say
> "FolderX". Write a log-shipping routine that monitors FolderX for new
> files. When a new file is detected, your log shipping routine should
> restore it and record the file name in a logging table. It then goes
> back to monitoring FolderX for new files that aren't in the logging
> table.
> It's really not as complicated as it seems, and you'll solve all of
> these problems...
OK that's great thanks. I really don't know why I had the task shrink
the log in the first place, given the rate it increases.|||On 22 Feb, 21:06, "Tracy McKibben" <tracy.mckib...@.gmail.com> wrote:
> On Feb 22, 2:48 pm, "Toby" <tjbeaum...@.gmail.com> wrote:
>
>
>
>
>
>
> Couple of key things here:
> 1. Log backups truncate the log - the more frequently that you run a
> log backup, the quicker committed transactions will get truncated, and
> the less likely your log is to grow. Note that LARGE transactions can
> still cause growth, because they can't be truncated until fully
> committed.
> 2. You are hurting your overall performance in one, possibly two,
> ways. By repeatedly shrinking the log file, you are forcing SQL
> Server to grow it again as needed, which introduces additional
> overhead, possibly during a busy period. Also, repeatedly growing/
> shrinking/growing/shrinking will lead to disk fragmentation, which
> will also ultimately hurt your performance.
> My advice would be to not use the log-shipping wizard that is built-
> in. You can kill two birds with one stone by writing your own backup
> routines. Create a log backup job that runs every hour (we do 5-
> minute intervals here), have that job create backup files that contain
> a date/time stamp, place these files into some folder, let's say
> "FolderX". Write a log-shipping routine that monitors FolderX for new
> files. When a new file is detected, your log shipping routine should
> restore it and record the file name in a logging table. It then goes
> back to monitoring FolderX for new files that aren't in the logging
> table.
> It's really not as complicated as it seems, and you'll solve all of
> these problems...
Hi again
I now have the transaction log shipping running fine - I have used the
Wizard for now so I'll see how it goes.
One thing though - having removed the additional process to backup and
truncate the log, the log is now not being truncated.
Any thoughts?
Thanks.|||On Feb 25, 6:44 am, "Toby" <tjbeaum...@.gmail.com> wrote:
> On 22 Feb, 21:06, "Tracy McKibben" <tracy.mckib...@.gmail.com> wrote:
>
>
>
>
>
>
>
>
>
>
>
>
> Hi again
> I now have the transaction log shipping running fine - I have used the
> Wizard for now so I'll see how it goes.
> One thing though - having removed the additional process to backup and
> truncate the log, the log is now not being truncated.
> Any thoughts?
> Thanks.
As I said, I would suggestion NOT using the wizards... I've never
used that log shipping wizard, I have no idea what sort of backup job
it creates. Create your OWN processes, then you know what's going
on...

Log shipping goes out of sync

Hi
I have two SQL 2000 boxes setup to log ship. The box being shipped to
is also the monitor
The size of the db being shipped is around 110GB - so the initial log
ship first creates and copies across the entire db (takes a while)
then begins the transaction logs.
The problem is that the log ship goes out of sync also immediately -
from testing I've managed to get the first shipped transaction log to
load, and sometimes the second, but never further as it gets out of
sync.
Things I've tried:
Changing the schedule from the default 15 minutes to 2 hours (for copy
and load)
Ensuring the log ship process doesn't clash with a routine backup
Any suggestions?
Thanks
TobyOn Feb 19, 7:40 am, "Toby" <tjbeaum...@.gmail.com> wrote:
> Hi
> I have two SQL 2000 boxes setup to log ship. The box being shipped to
> is also the monitor
> The size of the db being shipped is around 110GB - so the initial log
> ship first creates and copies across the entire db (takes a while)
> then begins the transaction logs.
> The problem is that the log ship goes out of sync also immediately -
> from testing I've managed to get the first shipped transaction log to
> load, and sometimes the second, but never further as it gets out of
> sync.
> Things I've tried:
> Changing the schedule from the default 15 minutes to 2 hours (for copy
> and load)
> Ensuring the log ship process doesn't clash with a routine backup
> Any suggestions?
> Thanks
> Toby
Please explain this further:
"Ensuring the log ship process doesn't clash with a routine backup"
Are you running transaction log backups IN ADDITION to the log
shipping process? This will break the log shipping chain. Log
shipping works by taking a backup of the transaction log and restoring
that backup onto another database. If you run your own independent
log backup, you're advancing the LSN pointer, throwing the log
shipping backups out of sync.|||Hi
In reply to your question "Are you running transaction log backups IN
ADDITION to the log
> shipping process? " - the answer is yes I am, so clearly here lies the problem.
I'm running a daily log backup, truncate and shrink - which I realise
now is going to cause issues with the log shipping. However, and
forgive me if this appears trivial, but the reason for run a log
backup, truncate and shrink is to prevent the log file getting too
big, as it currently grows at the rate of 20-30gb a day. If I rely on
the log shipping process only, will this provide adequate truncating
of the log?
Thanks|||On Feb 22, 2:48 pm, "Toby" <tjbeaum...@.gmail.com> wrote:
> Hi
> In reply to your question "Are you running transaction log backups IN
> ADDITION to the log
> > shipping process? " - the answer is yes I am, so clearly here lies the problem.
> I'm running a daily log backup, truncate and shrink - which I realise
> now is going to cause issues with the log shipping. However, and
> forgive me if this appears trivial, but the reason for run a log
> backup, truncate and shrink is to prevent the log file getting too
> big, as it currently grows at the rate of 20-30gb a day. If I rely on
> the log shipping process only, will this provide adequate truncating
> of the log?
> Thanks
Couple of key things here:
1. Log backups truncate the log - the more frequently that you run a
log backup, the quicker committed transactions will get truncated, and
the less likely your log is to grow. Note that LARGE transactions can
still cause growth, because they can't be truncated until fully
committed.
2. You are hurting your overall performance in one, possibly two,
ways. By repeatedly shrinking the log file, you are forcing SQL
Server to grow it again as needed, which introduces additional
overhead, possibly during a busy period. Also, repeatedly growing/
shrinking/growing/shrinking will lead to disk fragmentation, which
will also ultimately hurt your performance.
My advice would be to not use the log-shipping wizard that is built-
in. You can kill two birds with one stone by writing your own backup
routines. Create a log backup job that runs every hour (we do 5-
minute intervals here), have that job create backup files that contain
a date/time stamp, place these files into some folder, let's say
"FolderX". Write a log-shipping routine that monitors FolderX for new
files. When a new file is detected, your log shipping routine should
restore it and record the file name in a logging table. It then goes
back to monitoring FolderX for new files that aren't in the logging
table.
It's really not as complicated as it seems, and you'll solve all of
these problems...|||On 22 Feb, 21:06, "Tracy McKibben" <tracy.mckib...@.gmail.com> wrote:
> On Feb 22, 2:48 pm, "Toby" <tjbeaum...@.gmail.com> wrote:
>
> > Hi
> > In reply to your question "Are you running transaction log backups IN
> > ADDITION to the log
> > > shipping process? " - the answer is yes I am, so clearly here lies the problem.
> > I'm running a daily log backup, truncate and shrink - which I realise
> > now is going to cause issues with the log shipping. However, and
> > forgive me if this appears trivial, but the reason for run a log
> > backup, truncate and shrink is to prevent the log file getting too
> > big, as it currently grows at the rate of 20-30gb a day. If I rely on
> > the log shipping process only, will this provide adequate truncating
> > of the log?
> > Thanks
> Couple of key things here:
> 1. Log backups truncate the log - the more frequently that you run a
> log backup, the quicker committed transactions will get truncated, and
> the less likely your log is to grow. Note that LARGE transactions can
> still cause growth, because they can't be truncated until fully
> committed.
> 2. You are hurting your overall performance in one, possibly two,
> ways. By repeatedly shrinking the log file, you are forcing SQL
> Server to grow it again as needed, which introduces additional
> overhead, possibly during a busy period. Also, repeatedly growing/
> shrinking/growing/shrinking will lead to disk fragmentation, which
> will also ultimately hurt your performance.
> My advice would be to not use the log-shipping wizard that is built-
> in. You can kill two birds with one stone by writing your own backup
> routines. Create a log backup job that runs every hour (we do 5-
> minute intervals here), have that job create backup files that contain
> a date/time stamp, place these files into some folder, let's say
> "FolderX". Write a log-shipping routine that monitors FolderX for new
> files. When a new file is detected, your log shipping routine should
> restore it and record the file name in a logging table. It then goes
> back to monitoring FolderX for new files that aren't in the logging
> table.
> It's really not as complicated as it seems, and you'll solve all of
> these problems...
OK that's great thanks. I really don't know why I had the task shrink
the log in the first place, given the rate it increases.|||On 22 Feb, 21:06, "Tracy McKibben" <tracy.mckib...@.gmail.com> wrote:
> On Feb 22, 2:48 pm, "Toby" <tjbeaum...@.gmail.com> wrote:
>
> > Hi
> > In reply to your question "Are you running transaction log backups IN
> > ADDITION to the log
> > > shipping process? " - the answer is yes I am, so clearly here lies the problem.
> > I'm running a daily log backup, truncate and shrink - which I realise
> > now is going to cause issues with the log shipping. However, and
> > forgive me if this appears trivial, but the reason for run a log
> > backup, truncate and shrink is to prevent the log file getting too
> > big, as it currently grows at the rate of 20-30gb a day. If I rely on
> > the log shipping process only, will this provide adequate truncating
> > of the log?
> > Thanks
> Couple of key things here:
> 1. Log backups truncate the log - the more frequently that you run a
> log backup, the quicker committed transactions will get truncated, and
> the less likely your log is to grow. Note that LARGE transactions can
> still cause growth, because they can't be truncated until fully
> committed.
> 2. You are hurting your overall performance in one, possibly two,
> ways. By repeatedly shrinking the log file, you are forcing SQL
> Server to grow it again as needed, which introduces additional
> overhead, possibly during a busy period. Also, repeatedly growing/
> shrinking/growing/shrinking will lead to disk fragmentation, which
> will also ultimately hurt your performance.
> My advice would be to not use the log-shipping wizard that is built-
> in. You can kill two birds with one stone by writing your own backup
> routines. Create a log backup job that runs every hour (we do 5-
> minute intervals here), have that job create backup files that contain
> a date/time stamp, place these files into some folder, let's say
> "FolderX". Write a log-shipping routine that monitors FolderX for new
> files. When a new file is detected, your log shipping routine should
> restore it and record the file name in a logging table. It then goes
> back to monitoring FolderX for new files that aren't in the logging
> table.
> It's really not as complicated as it seems, and you'll solve all of
> these problems...
Hi again
I now have the transaction log shipping running fine - I have used the
Wizard for now so I'll see how it goes.
One thing though - having removed the additional process to backup and
truncate the log, the log is now not being truncated.
Any thoughts?
Thanks.|||On Feb 25, 6:44 am, "Toby" <tjbeaum...@.gmail.com> wrote:
> On 22 Feb, 21:06, "Tracy McKibben" <tracy.mckib...@.gmail.com> wrote:
>
> > On Feb 22, 2:48 pm, "Toby" <tjbeaum...@.gmail.com> wrote:
> > > Hi
> > > In reply to your question "Are you running transaction log backups IN
> > > ADDITION to the log
> > > > shipping process? " - the answer is yes I am, so clearly here lies the problem.
> > > I'm running a daily log backup, truncate and shrink - which I realise
> > > now is going to cause issues with the log shipping. However, and
> > > forgive me if this appears trivial, but the reason for run a log
> > > backup, truncate and shrink is to prevent the log file getting too
> > > big, as it currently grows at the rate of 20-30gb a day. If I rely on
> > > the log shipping process only, will this provide adequate truncating
> > > of the log?
> > > Thanks
> > Couple of key things here:
> > 1. Log backups truncate the log - the more frequently that you run a
> > log backup, the quicker committed transactions will get truncated, and
> > the less likely your log is to grow. Note that LARGE transactions can
> > still cause growth, because they can't be truncated until fully
> > committed.
> > 2. You are hurting your overall performance in one, possibly two,
> > ways. By repeatedly shrinking the log file, you are forcing SQL
> > Server to grow it again as needed, which introduces additional
> > overhead, possibly during a busy period. Also, repeatedly growing/
> > shrinking/growing/shrinking will lead to disk fragmentation, which
> > will also ultimately hurt your performance.
> > My advice would be to not use the log-shipping wizard that is built-
> > in. You can kill two birds with one stone by writing your own backup
> > routines. Create a log backup job that runs every hour (we do 5-
> > minute intervals here), have that job create backup files that contain
> > a date/time stamp, place these files into some folder, let's say
> > "FolderX". Write a log-shipping routine that monitors FolderX for new
> > files. When a new file is detected, your log shipping routine should
> > restore it and record the file name in a logging table. It then goes
> > back to monitoring FolderX for new files that aren't in the logging
> > table.
> > It's really not as complicated as it seems, and you'll solve all of
> > these problems...
> Hi again
> I now have the transaction log shipping running fine - I have used the
> Wizard for now so I'll see how it goes.
> One thing though - having removed the additional process to backup and
> truncate the log, the log is now not being truncated.
> Any thoughts?
> Thanks.
As I said, I would suggestion NOT using the wizards... I've never
used that log shipping wizard, I have no idea what sort of backup job
it creates. Create your OWN processes, then you know what's going
on...

Log Shipping does not ship to secondary database

Good day to the people who's reading this post!

I have some trouble with shipping my transaction logs to the secondary database be it on

another server or within the same server to another database instance.

Im using SQL Server 2005 workGroup editions with Service Pack 2.

Here are the problems that i encountered.

I do hope someone has bumped into such a problem and willing to help me out.

I tried on 2 separate servers (not domain environment) and also between 2 separate instances

(which is supposed to be simple!) on

our development server,but was unsuccessful.

Between 2 separate instances on the development server -

No error after configuring Log shipping though.

The configuring went through and it was a success.

Transaction logs was backup every minute and it got copied over to the other folder.

But SQL Agent not doing its last job which is supposed to restore to the secondary database on

another instance.No errors given out in SQL Agent error log files.Anywhere else im supposed to

look to see if there are errors given out?

Both instances SQL Agent has the same log on username and password with Administartive rights

So what went wrong?

Between the 2 servers-

The transaction logs was backup every 1min on the primary server

but it didn't got copied over to to the secondary database.

- Error message given was:Error in restoring database to the secondary

database.Network path given could not be found. Can't open the AxTest.bak file.

(i am very sure i have type the correct network path,even have shared it out and i think the firewall

is blocking incoming traffic since unlike our development server,

which allows us to access when we use Start>Run and type in the ip address,user name

and password,the primary server will only tell me no network path was found)

I also believe it's because the SQL Agent on the secondary database server wasn't given

permission to access the primary database folder.

I've shared out the drive and folder on the secondary server and

even have allowed SQL Agent to read,write and modify on both servers.

For the primary and secondary SQL Agent,

I configure their log on to be the same user account name and password

which have administrative rights.

So what went wrong?

Isit really true that both servers have to be in domain environment before you can configure log

shipping,mirroring and replication?

Hope someone help me out of this predicament.Thank you in advance!

Log shipping between domains or different work groups is pretty picky. Here's a link I used when setting it up before.

http://support.microsoft.com/default.aspx/kb/321247/

This section may apply to your situation:

Cross Domain Log Shipping

If computers that are running SQL Server are placed in a multi-domain environment, Microsoft recommends that you set up two-way trusts between all domains that are involved in log shipping. However, if you cannot establish trusts between domains, you can use network pass-through security for log shipping. Refer to the section of this article that discusses the LocalSystem network account startup option for SQL Server-related services.

Why your restores are not working between instances is another story. Maybe try restoring the copied tran log manually and see if it works or generates any errors. Add some log files to the job steps directly and see if you get anymore information.

Good Luck|||

Hi Mark!Your post is certainly very helpful!

Could you correct me if i misunderstood the article please.

Does it mean that if i set up the SQL services log on account on the secondary database with the exact match of a local user account which exists on the primary

database server,

my secondary database SQL services will be able to access the primary database because it has bypass the network security?

Hope to hear your reply soon.

By the way i found out that certain ports has to be open to enable SQL services to execute the log shipping properly.

Port 135 - for the services

Ports 137, 138, and 139 or 445 need to be open too cuz im using UNC path for the folder sharing

This link will provide more information. Hope it will help others...

http://72.14.235.104/search?q =cache:Nb5a6PvckzwJ:www.stlssug.org/docs/Log-Shipping.ppt+what+port+does+log+shipping+use&hl=en&ct=clnk&cd=1

|||Yes, we synced the administrator passwords on both servers.

Good luck and thanks for the port info.|||

Hi Mark.

Turns out the log shipping still didnt work between the two servers even after opening the ports.

It keeps saying the network path could not be found each time the agent from the secondary database server tried to retrieve the

transaction log file to restore a new database.

Any idea if there is any other security settings that might be blocking the server from accessing the primary database

server network path? Or do you know if i have to enable any services?

My log shipping between the 2 instances work now though.

SQL Browser were disabled just had to enable it back.

Thanks in Advance!

|||If you have already done/tried the things below, I can't help you. There seems to be a network disconnect. Is there a trust set up between the 2 servers? Sorry, I'm not a network admin guy.

Local Network Account

You can use SQL Server to start under a locally-created network account. In the situation where there is network access required by a SQL Server process, which is the case if you have configured SQL Server to use log shipping, you can use network pass-through security. With pass-through security, all machines that will be accessed by SQL Server must have the same network account with the same password and appropriate permissions, configured locally. Additionally, when the SQL Server process requests resources from the second computer, traditional network security is bypassed if the same account (under which the requesting SQL Server service is started) exists with the same password. As long the account on the second computer is configured with enough permission to carry out the task that is requested by calling SQL Server, the task will be successful.

Local System Account

You can also configure SQL Server to start under the Local System account. Modifying the password for the LocalSystem account may result in the failure of some services that are critical for system stability. This account is local to the computer where it resides, which means that the security context that SQL Server services uses is local. As stated in the Local Network Account section, you cannot use network pass-through security when you start SQL Server under the LocalSystem account because the passwords for the LocalSystem account on different computers are different. The starting of SQL Server under this account when network resource access is required will most likely result in the unsuccessful completion of tasks.

Log Shipping does not ship to secondary database

Good day to the people who's reading this post!

I have some trouble with shipping my transaction logs to the secondary database be it on

another server or within the same server to another database instance.

Im using SQL Server 2005 workGroup editions with Service Pack 2.

Here are the problems that i encountered.

I do hope someone has bumped into such a problem and willing to help me out.

I tried on 2 separate servers (not domain environment) and also between 2 separate instances

(which is supposed to be simple!) on

our development server,but was unsuccessful.

Between 2 separate instances on the development server -

No error after configuring Log shipping though.

The configuring went through and it was a success.

Transaction logs was backup every minute and it got copied over to the other folder.

But SQL Agent not doing its last job which is supposed to restore to the secondary database on

another instance.No errors given out in SQL Agent error log files.Anywhere else im supposed to

look to see if there are errors given out?

Both instances SQL Agent has the same log on username and password with Administartive rights

So what went wrong?

Between the 2 servers-

The transaction logs was backup every 1min on the primary server

but it didn't got copied over to to the secondary database.

- Error message given was:Error in restoring database to the secondary

database.Network path given could not be found. Can't open the AxTest.bak file.

(i am very sure i have type the correct network path,even have shared it out and i think the firewall

is blocking incoming traffic since unlike our development server,

which allows us to access when we use Start>Run and type in the ip address,user name

and password,the primary server will only tell me no network path was found)

I also believe it's because the SQL Agent on the secondary database server wasn't given

permission to access the primary database folder.

I've shared out the drive and folder on the secondary server and

even have allowed SQL Agent to read,write and modify on both servers.

For the primary and secondary SQL Agent,

I configure their log on to be the same user account name and password

which have administrative rights.

So what went wrong?

Isit really true that both servers have to be in domain environment before you can configure log

shipping,mirroring and replication?

Hope someone help me out of this predicament.Thank you in advance!

Log shipping between domains or different work groups is pretty picky. Here's a link I used when setting it up before.

http://support.microsoft.com/default.aspx/kb/321247/

This section may apply to your situation:

Cross Domain Log Shipping

If computers that are running SQL Server are placed in a multi-domain environment, Microsoft recommends that you set up two-way trusts between all domains that are involved in log shipping. However, if you cannot establish trusts between domains, you can use network pass-through security for log shipping. Refer to the section of this article that discusses the LocalSystem network account startup option for SQL Server-related services.

Why your restores are not working between instances is another story. Maybe try restoring the copied tran log manually and see if it works or generates any errors. Add some log files to the job steps directly and see if you get anymore information.

Good Luck|||

Hi Mark!Your post is certainly very helpful!

Could you correct me if i misunderstood the article please.

Does it mean that if i set up the SQL services log on account on the secondary database with the exact match of a local user account which exists on the primary

database server,

my secondary database SQL services will be able to access the primary database because it has bypass the network security?

Hope to hear your reply soon.

By the way i found out that certain ports has to be open to enable SQL services to execute the log shipping properly.

Port 135 - for the services

Ports 137, 138, and 139 or 445 need to be open too cuz im using UNC path for the folder sharing

This link will provide more information. Hope it will help others...

http://72.14.235.104/search?q =cache:Nb5a6PvckzwJ:www.stlssug.org/docs/Log-Shipping.ppt+what+port+does+log+shipping+use&hl=en&ct=clnk&cd=1

|||Yes, we synced the administrator passwords on both servers.

Good luck and thanks for the port info.|||

Hi Mark.

Turns out the log shipping still didnt work between the two servers even after opening the ports.

It keeps saying the network path could not be found each time the agent from the secondary database server tried to retrieve the

transaction log file to restore a new database.

Any idea if there is any other security settings that might be blocking the server from accessing the primary database

server network path? Or do you know if i have to enable any services?

My log shipping between the 2 instances work now though.

SQL Browser were disabled just had to enable it back.

Thanks in Advance!

|||If you have already done/tried the things below, I can't help you. There seems to be a network disconnect. Is there a trust set up between the 2 servers? Sorry, I'm not a network admin guy.

Local Network Account

You can use SQL Server to start under a locally-created network account. In the situation where there is network access required by a SQL Server process, which is the case if you have configured SQL Server to use log shipping, you can use network pass-through security. With pass-through security, all machines that will be accessed by SQL Server must have the same network account with the same password and appropriate permissions, configured locally. Additionally, when the SQL Server process requests resources from the second computer, traditional network security is bypassed if the same account (under which the requesting SQL Server service is started) exists with the same password. As long the account on the second computer is configured with enough permission to carry out the task that is requested by calling SQL Server, the task will be successful.

Local System Account

You can also configure SQL Server to start under the Local System account. Modifying the password for the LocalSystem account may result in the failure of some services that are critical for system stability. This account is local to the computer where it resides, which means that the security context that SQL Server services uses is local. As stated in the Local Network Account section, you cannot use network pass-through security when you start SQL Server under the LocalSystem account because the passwords for the LocalSystem account on different computers are different. The starting of SQL Server under this account when network resource access is required will most likely result in the unsuccessful completion of tasks.

Log Shipping database loading

Hello All,
I have set up Log Shipping on my production server to ship the logs to a
backup server. But the database in the backup server is always in the
loading state. It have "read only" option set on its properties that way I
can still run quires on the DB, but it always says (loading). Can anybody
help!!!
Thanks,
-Pavan
Never Mind changed it from "No recovery Mode" to 'Standby" mode and it works
fine now
"Pavan" <seattlemcse@.online.hotmail.com> wrote in message
news:#1SNgvnzEHA.3548@.TK2MSFTNGP09.phx.gbl...
> Hello All,
> I have set up Log Shipping on my production server to ship the logs to
a
> backup server. But the database in the backup server is always in the
> loading state. It have "read only" option set on its properties that way I
> can still run quires on the DB, but it always says (loading). Can anybody
> help!!!
>
> Thanks,
> -Pavan
>
|||A few days ago you posted that your log shipping database is stuck in loading state and you were unable to run reports from that server. You mentioned changing from no recovery to standby and all is well. How did you go about doing that ? When I initially setup log shipping I set everything to standby and even now the maintenance plans show standby, yet my DB still show loading. Your help is GREATLY appreciated !!

Quote:

Originally posted by Pavan
Hello All,
I have set up Log Shipping on my production server to ship the logs to a
backup server. But the database in the backup server is always in the
loading state. It have "read only" option set on its properties that way I
can still run quires on the DB, but it always says (loading). Can anybody
help!!!
Thanks,
-Pavan

log shipping and Full text indexing

We have FT Indexing service enabled ? How do I know if we have any full text
indexes and when I log ship and/or backup my databases in SQL 2005, does it
take care of it as well or do I have to manually move them to the other
server and back them up ?
Using SQL 2005
ThanksOn your database, go to Storage and Full Text Catalogs. See if you have any
full text catalogs there.
A full database backup also takes care of backing up your full text
catalogs. Since log shipping uses a database backup to initialize the
secondary database, the full text catalog is restored as well on this
database.
Hope this helps,
Ben Nevarez
Senior Database Administrator
AIG SunAmerica
"Hassan" wrote:

> We have FT Indexing service enabled ? How do I know if we have any full te
xt
> indexes and when I log ship and/or backup my databases in SQL 2005, does i
t
> take care of it as well or do I have to manually move them to the other
> server and back them up ?
> Using SQL 2005
> Thanks
>|||On your database, go to Storage and Full Text Catalogs. See if you have any
full text catalogs there.
A full database backup also takes care of backing up your full text
catalogs. Since log shipping uses a database backup to initialize the
secondary database, the full text catalog is restored as well on this
database.
Hope this helps,
Ben Nevarez
Senior Database Administrator
AIG SunAmerica
"Hassan" wrote:

> We have FT Indexing service enabled ? How do I know if we have any full te
xt
> indexes and when I log ship and/or backup my databases in SQL 2005, does i
t
> take care of it as well or do I have to manually move them to the other
> server and back them up ?
> Using SQL 2005
> Thanks
>

log shipping and Full text indexing

We have FT Indexing service enabled ? How do I know if we have any full text
indexes and when I log ship and/or backup my databases in SQL 2005, does it
take care of it as well or do I have to manually move them to the other
server and back them up ?
Using SQL 2005
Thanks
On your database, go to Storage and Full Text Catalogs. See if you have any
full text catalogs there.
A full database backup also takes care of backing up your full text
catalogs. Since log shipping uses a database backup to initialize the
secondary database, the full text catalog is restored as well on this
database.
Hope this helps,
Ben Nevarez
Senior Database Administrator
AIG SunAmerica
"Hassan" wrote:

> We have FT Indexing service enabled ? How do I know if we have any full text
> indexes and when I log ship and/or backup my databases in SQL 2005, does it
> take care of it as well or do I have to manually move them to the other
> server and back them up ?
> Using SQL 2005
> Thanks
>
|||On your database, go to Storage and Full Text Catalogs. See if you have any
full text catalogs there.
A full database backup also takes care of backing up your full text
catalogs. Since log shipping uses a database backup to initialize the
secondary database, the full text catalog is restored as well on this
database.
Hope this helps,
Ben Nevarez
Senior Database Administrator
AIG SunAmerica
"Hassan" wrote:

> We have FT Indexing service enabled ? How do I know if we have any full text
> indexes and when I log ship and/or backup my databases in SQL 2005, does it
> take care of it as well or do I have to manually move them to the other
> server and back them up ?
> Using SQL 2005
> Thanks
>

log shipping and Full text indexing

We have FT Indexing service enabled ? How do I know if we have any full text
indexes and when I log ship and/or backup my databases in SQL 2005, does it
take care of it as well or do I have to manually move them to the other
server and back them up ?
Using SQL 2005
ThanksOn your database, go to Storage and Full Text Catalogs. See if you have any
full text catalogs there.
A full database backup also takes care of backing up your full text
catalogs. Since log shipping uses a database backup to initialize the
secondary database, the full text catalog is restored as well on this
database.
Hope this helps,
Ben Nevarez
Senior Database Administrator
AIG SunAmerica
"Hassan" wrote:
> We have FT Indexing service enabled ? How do I know if we have any full text
> indexes and when I log ship and/or backup my databases in SQL 2005, does it
> take care of it as well or do I have to manually move them to the other
> server and back them up ?
> Using SQL 2005
> Thanks
>|||On your database, go to Storage and Full Text Catalogs. See if you have any
full text catalogs there.
A full database backup also takes care of backing up your full text
catalogs. Since log shipping uses a database backup to initialize the
secondary database, the full text catalog is restored as well on this
database.
Hope this helps,
Ben Nevarez
Senior Database Administrator
AIG SunAmerica
"Hassan" wrote:
> We have FT Indexing service enabled ? How do I know if we have any full text
> indexes and when I log ship and/or backup my databases in SQL 2005, does it
> take care of it as well or do I have to manually move them to the other
> server and back them up ?
> Using SQL 2005
> Thanks
>