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