What's the logshipping trn file retention most DBA usually set, 1,2 or 3
days? I am curious. In our production database, we set our LS file retention
for 3 days and I am just wonder if it 's too long or too short. Is there a
guideline or some short.
Thanks in advance
PhilN wrote:
> What's the logshipping trn file retention most DBA usually set, 1,2 or 3
> days? I am curious. In our production database, we set our LS file retention
> for 3 days and I am just wonder if it 's too long or too short. Is there a
> guideline or some short.
> Thanks in advance
>
We use a home-grown log shipping process here, and keep a solid week's
worth of backups. As each log is restored, it is zipped up into an
archive for that day. At any given point, we have 7 zip files,
containing the t-logs for the previous 7 days.
Tracy McKibben
MCDBA
http://www.realsqlguy.com
Showing posts with label trn. Show all posts
Showing posts with label trn. Show all posts
Friday, March 30, 2012
Log shipping trn file retention
What's the logshipping trn file retention most DBA usually set, 1,2 or 3
days? I am curious. In our production database, we set our LS file retention
for 3 days and I am just wonder if it 's too long or too short. Is there a
guideline or some short.
Thanks in advancePhilN wrote:
> What's the logshipping trn file retention most DBA usually set, 1,2 or 3
> days? I am curious. In our production database, we set our LS file retention
> for 3 days and I am just wonder if it 's too long or too short. Is there a
> guideline or some short.
> Thanks in advance
>
We use a home-grown log shipping process here, and keep a solid week's
worth of backups. As each log is restored, it is zipped up into an
archive for that day. At any given point, we have 7 zip files,
containing the t-logs for the previous 7 days.
Tracy McKibben
MCDBA
http://www.realsqlguy.comsql
days? I am curious. In our production database, we set our LS file retention
for 3 days and I am just wonder if it 's too long or too short. Is there a
guideline or some short.
Thanks in advancePhilN wrote:
> What's the logshipping trn file retention most DBA usually set, 1,2 or 3
> days? I am curious. In our production database, we set our LS file retention
> for 3 days and I am just wonder if it 's too long or too short. Is there a
> guideline or some short.
> Thanks in advance
>
We use a home-grown log shipping process here, and keep a solid week's
worth of backups. As each log is restored, it is zipped up into an
archive for that day. At any given point, we have 7 zip files,
containing the t-logs for the previous 7 days.
Tracy McKibben
MCDBA
http://www.realsqlguy.comsql
Log shipping trn file retention
What's the logshipping trn file retention most DBA usually set, 1,2 or 3
days? I am curious. In our production database, we set our LS file retention
for 3 days and I am just wonder if it 's too long or too short. Is there a
guideline or some short.
Thanks in advancePhilN wrote:
> What's the logshipping trn file retention most DBA usually set, 1,2 or 3
> days? I am curious. In our production database, we set our LS file retenti
on
> for 3 days and I am just wonder if it 's too long or too short. Is there a
> guideline or some short.
> Thanks in advance
>
We use a home-grown log shipping process here, and keep a solid week's
worth of backups. As each log is restored, it is zipped up into an
archive for that day. At any given point, we have 7 zip files,
containing the t-logs for the previous 7 days.
Tracy McKibben
MCDBA
http://www.realsqlguy.com
days? I am curious. In our production database, we set our LS file retention
for 3 days and I am just wonder if it 's too long or too short. Is there a
guideline or some short.
Thanks in advancePhilN wrote:
> What's the logshipping trn file retention most DBA usually set, 1,2 or 3
> days? I am curious. In our production database, we set our LS file retenti
on
> for 3 days and I am just wonder if it 's too long or too short. Is there a
> guideline or some short.
> Thanks in advance
>
We use a home-grown log shipping process here, and keep a solid week's
worth of backups. As each log is restored, it is zipped up into an
archive for that day. At any given point, we have 7 zip files,
containing the t-logs for the previous 7 days.
Tracy McKibben
MCDBA
http://www.realsqlguy.com
Monday, March 26, 2012
Log Shipping Question: reset copy delta
SQL Server 2000 on both servers. Log shipping between them.
We had to reboot the primary server and now the trn files are not
being copied to the secondary server.
In the past when this happened, we manually copied the files from
primary to secondary and then ran the upload job on the secondary
server. The copy delta would then reset at some point (usually
overnight).
This time after I have copied the files and uploaded them, the copy
delta has not reset and now stands at 5415 minutes. The Load delta is
at 0 minutes currently.
Is there a way to force the copy delta to update itself because all
the trn files now have been loaded?
If there isn't I will have to run the wizard to create the log
shipping plans again for all four of our databases.
Regards
Nicko
Hi
What does mean 'copy delta'?
http://www.sql-server-performance.com/sql_server_log_shipping.asp
<nickostle@.hotmail.com> wrote in message
news:1179713332.252623.51410@.z28g2000prd.googlegro ups.com...
> SQL Server 2000 on both servers. Log shipping between them.
> We had to reboot the primary server and now the trn files are not
> being copied to the secondary server.
> In the past when this happened, we manually copied the files from
> primary to secondary and then ran the upload job on the secondary
> server. The copy delta would then reset at some point (usually
> overnight).
> This time after I have copied the files and uploaded them, the copy
> delta has not reset and now stands at 5415 minutes. The Load delta is
> at 0 minutes currently.
> Is there a way to force the copy delta to update itself because all
> the trn files now have been loaded?
> If there isn't I will have to run the wizard to create the log
> shipping plans again for all four of our databases.
> Regards
> Nicko
>
|||Copy Delta is the time dfference between when it says the last file
was copied to the present time on the server.
sql
We had to reboot the primary server and now the trn files are not
being copied to the secondary server.
In the past when this happened, we manually copied the files from
primary to secondary and then ran the upload job on the secondary
server. The copy delta would then reset at some point (usually
overnight).
This time after I have copied the files and uploaded them, the copy
delta has not reset and now stands at 5415 minutes. The Load delta is
at 0 minutes currently.
Is there a way to force the copy delta to update itself because all
the trn files now have been loaded?
If there isn't I will have to run the wizard to create the log
shipping plans again for all four of our databases.
Regards
Nicko
Hi
What does mean 'copy delta'?
http://www.sql-server-performance.com/sql_server_log_shipping.asp
<nickostle@.hotmail.com> wrote in message
news:1179713332.252623.51410@.z28g2000prd.googlegro ups.com...
> SQL Server 2000 on both servers. Log shipping between them.
> We had to reboot the primary server and now the trn files are not
> being copied to the secondary server.
> In the past when this happened, we manually copied the files from
> primary to secondary and then ran the upload job on the secondary
> server. The copy delta would then reset at some point (usually
> overnight).
> This time after I have copied the files and uploaded them, the copy
> delta has not reset and now stands at 5415 minutes. The Load delta is
> at 0 minutes currently.
> Is there a way to force the copy delta to update itself because all
> the trn files now have been loaded?
> If there isn't I will have to run the wizard to create the log
> shipping plans again for all four of our databases.
> Regards
> Nicko
>
|||Copy Delta is the time dfference between when it says the last file
was copied to the present time on the server.
sql
Log Shipping Question: reset copy delta
SQL Server 2000 on both servers. Log shipping between them.
We had to reboot the primary server and now the trn files are not
being copied to the secondary server.
In the past when this happened, we manually copied the files from
primary to secondary and then ran the upload job on the secondary
server. The copy delta would then reset at some point (usually
overnight).
This time after I have copied the files and uploaded them, the copy
delta has not reset and now stands at 5415 minutes. The Load delta is
at 0 minutes currently.
Is there a way to force the copy delta to update itself because all
the trn files now have been loaded?
If there isn't I will have to run the wizard to create the log
shipping plans again for all four of our databases.
Regards
NickoHi
What does mean 'copy delta'?
http://www.sql-server-performance.c...og_shipping.asp
<nickostle@.hotmail.com> wrote in message
news:1179713332.252623.51410@.z28g2000prd.googlegroups.com...
> SQL Server 2000 on both servers. Log shipping between them.
> We had to reboot the primary server and now the trn files are not
> being copied to the secondary server.
> In the past when this happened, we manually copied the files from
> primary to secondary and then ran the upload job on the secondary
> server. The copy delta would then reset at some point (usually
> overnight).
> This time after I have copied the files and uploaded them, the copy
> delta has not reset and now stands at 5415 minutes. The Load delta is
> at 0 minutes currently.
> Is there a way to force the copy delta to update itself because all
> the trn files now have been loaded?
> If there isn't I will have to run the wizard to create the log
> shipping plans again for all four of our databases.
> Regards
> Nicko
>|||Copy Delta is the time dfference between when it says the last file
was copied to the present time on the server.
We had to reboot the primary server and now the trn files are not
being copied to the secondary server.
In the past when this happened, we manually copied the files from
primary to secondary and then ran the upload job on the secondary
server. The copy delta would then reset at some point (usually
overnight).
This time after I have copied the files and uploaded them, the copy
delta has not reset and now stands at 5415 minutes. The Load delta is
at 0 minutes currently.
Is there a way to force the copy delta to update itself because all
the trn files now have been loaded?
If there isn't I will have to run the wizard to create the log
shipping plans again for all four of our databases.
Regards
NickoHi
What does mean 'copy delta'?
http://www.sql-server-performance.c...og_shipping.asp
<nickostle@.hotmail.com> wrote in message
news:1179713332.252623.51410@.z28g2000prd.googlegroups.com...
> SQL Server 2000 on both servers. Log shipping between them.
> We had to reboot the primary server and now the trn files are not
> being copied to the secondary server.
> In the past when this happened, we manually copied the files from
> primary to secondary and then ran the upload job on the secondary
> server. The copy delta would then reset at some point (usually
> overnight).
> This time after I have copied the files and uploaded them, the copy
> delta has not reset and now stands at 5415 minutes. The Load delta is
> at 0 minutes currently.
> Is there a way to force the copy delta to update itself because all
> the trn files now have been loaded?
> If there isn't I will have to run the wizard to create the log
> shipping plans again for all four of our databases.
> Regards
> Nicko
>|||Copy Delta is the time dfference between when it says the last file
was copied to the present time on the server.
Log Shipping Question: reset copy delta
SQL Server 2000 on both servers. Log shipping between them.
We had to reboot the primary server and now the trn files are not
being copied to the secondary server.
In the past when this happened, we manually copied the files from
primary to secondary and then ran the upload job on the secondary
server. The copy delta would then reset at some point (usually
overnight).
This time after I have copied the files and uploaded them, the copy
delta has not reset and now stands at 5415 minutes. The Load delta is
at 0 minutes currently.
Is there a way to force the copy delta to update itself because all
the trn files now have been loaded?
If there isn't I will have to run the wizard to create the log
shipping plans again for all four of our databases.
Regards
NickoHi
What does mean 'copy delta'?
http://www.sql-server-performance.com/sql_server_log_shipping.asp
<nickostle@.hotmail.com> wrote in message
news:1179713332.252623.51410@.z28g2000prd.googlegroups.com...
> SQL Server 2000 on both servers. Log shipping between them.
> We had to reboot the primary server and now the trn files are not
> being copied to the secondary server.
> In the past when this happened, we manually copied the files from
> primary to secondary and then ran the upload job on the secondary
> server. The copy delta would then reset at some point (usually
> overnight).
> This time after I have copied the files and uploaded them, the copy
> delta has not reset and now stands at 5415 minutes. The Load delta is
> at 0 minutes currently.
> Is there a way to force the copy delta to update itself because all
> the trn files now have been loaded?
> If there isn't I will have to run the wizard to create the log
> shipping plans again for all four of our databases.
> Regards
> Nicko
>|||Copy Delta is the time dfference between when it says the last file
was copied to the present time on the server.
We had to reboot the primary server and now the trn files are not
being copied to the secondary server.
In the past when this happened, we manually copied the files from
primary to secondary and then ran the upload job on the secondary
server. The copy delta would then reset at some point (usually
overnight).
This time after I have copied the files and uploaded them, the copy
delta has not reset and now stands at 5415 minutes. The Load delta is
at 0 minutes currently.
Is there a way to force the copy delta to update itself because all
the trn files now have been loaded?
If there isn't I will have to run the wizard to create the log
shipping plans again for all four of our databases.
Regards
NickoHi
What does mean 'copy delta'?
http://www.sql-server-performance.com/sql_server_log_shipping.asp
<nickostle@.hotmail.com> wrote in message
news:1179713332.252623.51410@.z28g2000prd.googlegroups.com...
> SQL Server 2000 on both servers. Log shipping between them.
> We had to reboot the primary server and now the trn files are not
> being copied to the secondary server.
> In the past when this happened, we manually copied the files from
> primary to secondary and then ran the upload job on the secondary
> server. The copy delta would then reset at some point (usually
> overnight).
> This time after I have copied the files and uploaded them, the copy
> delta has not reset and now stands at 5415 minutes. The Load delta is
> at 0 minutes currently.
> Is there a way to force the copy delta to update itself because all
> the trn files now have been loaded?
> If there isn't I will have to run the wizard to create the log
> shipping plans again for all four of our databases.
> Regards
> Nicko
>|||Copy Delta is the time dfference between when it says the last file
was copied to the present time on the server.
Friday, March 23, 2012
Log Shipping question
Hi!
I managed to make a plan of log shipping and have some questions.
In the first trn back up I recieved an error
[Microsoft SQL-DMO (ODBC SQLState: 42000)] Error 3201: [Microsoft][ODBC SQL
Server Driver][SQL Server]Cannot open backup device
'D:\logshipping\Pergam2_tlog_200312250945.TRN'. Device error or device
off-line. See the SQL Server error log for more details.
[Microsoft][ODBC SQL Server Driver][SQL Server]RESTORE LOG is terminating
abnormally.
All other back ups are fine and databases seeens to be identical. But Log
shipping monitor shows out of sync ?!!!
What it can be?
if backup/restore or restore fails what will be with databases in the next
step when all will work fine?
Thanks
DmitryI have seen messages like this sometimes on our log
shipping installation too. I believe Sql Server sometimes
starts reading the log files even before they have been
completely transferred. This seems to be best ignored. Set
your monitor to a higher out of sync value.
If the databases get out of sync, the best way is to back
up and restore them and restart log shipping.
>--Original Message--
>Hi!
>I managed to make a plan of log shipping and have some
questions.
>In the first trn back up I recieved an error
>[Microsoft SQL-DMO (ODBC SQLState: 42000)] Error 3201:
[Microsoft][ODBC SQL
>Server Driver][SQL Server]Cannot open backup device
>'D:\logshipping\Pergam2_tlog_200312250945.TRN'. Device
error or device
>off-line. See the SQL Server error log for more details.
>[Microsoft][ODBC SQL Server Driver][SQL Server]RESTORE
LOG is terminating
>abnormally.
>All other back ups are fine and databases seeens to be
identical. But Log
>shipping monitor shows out of sync ?!!!
>What it can be?
>if backup/restore or restore fails what will be with
databases in the next
>step when all will work fine?
>Thanks
>Dmitry
>
>.
>
I managed to make a plan of log shipping and have some questions.
In the first trn back up I recieved an error
[Microsoft SQL-DMO (ODBC SQLState: 42000)] Error 3201: [Microsoft][ODBC SQL
Server Driver][SQL Server]Cannot open backup device
'D:\logshipping\Pergam2_tlog_200312250945.TRN'. Device error or device
off-line. See the SQL Server error log for more details.
[Microsoft][ODBC SQL Server Driver][SQL Server]RESTORE LOG is terminating
abnormally.
All other back ups are fine and databases seeens to be identical. But Log
shipping monitor shows out of sync ?!!!
What it can be?
if backup/restore or restore fails what will be with databases in the next
step when all will work fine?
Thanks
DmitryI have seen messages like this sometimes on our log
shipping installation too. I believe Sql Server sometimes
starts reading the log files even before they have been
completely transferred. This seems to be best ignored. Set
your monitor to a higher out of sync value.
If the databases get out of sync, the best way is to back
up and restore them and restart log shipping.
>--Original Message--
>Hi!
>I managed to make a plan of log shipping and have some
questions.
>In the first trn back up I recieved an error
>[Microsoft SQL-DMO (ODBC SQLState: 42000)] Error 3201:
[Microsoft][ODBC SQL
>Server Driver][SQL Server]Cannot open backup device
>'D:\logshipping\Pergam2_tlog_200312250945.TRN'. Device
error or device
>off-line. See the SQL Server error log for more details.
>[Microsoft][ODBC SQL Server Driver][SQL Server]RESTORE
LOG is terminating
>abnormally.
>All other back ups are fine and databases seeens to be
identical. But Log
>shipping monitor shows out of sync ?!!!
>What it can be?
>if backup/restore or restore fails what will be with
databases in the next
>step when all will work fine?
>Thanks
>Dmitry
>
>.
>
Wednesday, March 21, 2012
Log Shipping not Loading TRN file
I cannot get Log Shipping to work. It does not give any outward
errors. Everything seams to work correctly except the secondary server
is not picking up the Transaction logs and applying them. The TRN
files are being written to a shared directory on the primary server as
scheduled.
I tracked down the following error on the scecondary server from the
Log Shipping copy job.
Microsoft (R) SQLMaint Utility (Unicode), Version 8.00.760
Copyright (C) Microsoft Corporation, 1995 - 1998
Logged on to SQL Server 'DATABASE2\Dev'
as 'NT AUTHORITY\SYSTEM' (trusted)
[Microsoft SQL-DMO (ODBC SQLState: 28000)] Error 18452:
[Microsoft][ODBC SQL Server Driver][SQL Server]Login
failed for user '(null)'. Reason: Not associated with
a trusted SQL Server connection.
Starting copy for plan DATABASE1\Dev.CMX_Dev_logshipping
Source database - CMX_Dev
Copied 0 files
Finished copy for plan DATABASE1\Dev.CMX_Dev_logshipping
I have two Enterprise SQL Server 2000 machines (Database1 &
Database2). They are not part of any domain. They both are running
SQL Server and Agent under the identical user which has Administration
priviledges. Both machines can see the shared drive and have full
access. The shared drive is on Database1 and Database1 is also
currently the monitoring server.
Any suggestions would be appreciated...
Thanks
Calvin,
I have a related problem (the destination server is in a disaster site
without any domain)
It seems the Windows account who creates and runs the logshipping has
sa access on the destination server
The error suggest you were able to create a login on the destination
server for the user SYSTEM on local domain (=machine) NT AUTHORITY
(this is what a plan to do, but since I cannot browse the domain of
the primary server I plan to fiddle with the host file
Did you assign administrator role to this login ?
HTH
Jan Waumans
On 6 Apr 2004 13:46:10 -0700, CalvinNSlater@.Hotmail.com (Calvin
Slater) wrote:
>I cannot get Log Shipping to work. It does not give any outward
>errors. Everything seams to work correctly except the secondary server
>is not picking up the Transaction logs and applying them. The TRN
>files are being written to a shared directory on the primary server as
>scheduled.
> I tracked down the following error on the scecondary server from the
>Log Shipping copy job.
> Microsoft (R) SQLMaint Utility (Unicode), Version 8.00.760
> Copyright (C) Microsoft Corporation, 1995 - 1998
> Logged on to SQL Server 'DATABASE2\Dev'
> as 'NT AUTHORITY\SYSTEM' (trusted)
> [Microsoft SQL-DMO (ODBC SQLState: 28000)] Error 18452:
> [Microsoft][ODBC SQL Server Driver][SQL Server]Login
> failed for user '(null)'. Reason: Not associated with
> a trusted SQL Server connection.
> Starting copy for plan DATABASE1\Dev.CMX_Dev_logshipping
> Source database - CMX_Dev
> Copied 0 files
> Finished copy for plan DATABASE1\Dev.CMX_Dev_logshipping
>
>I have two Enterprise SQL Server 2000 machines (Database1 &
>Database2). They are not part of any domain. They both are running
>SQL Server and Agent under the identical user which has Administration
>priviledges. Both machines can see the shared drive and have full
>access. The shared drive is on Database1 and Database1 is also
>currently the monitoring server.
>Any suggestions would be appreciated...
>Thanks
errors. Everything seams to work correctly except the secondary server
is not picking up the Transaction logs and applying them. The TRN
files are being written to a shared directory on the primary server as
scheduled.
I tracked down the following error on the scecondary server from the
Log Shipping copy job.
Microsoft (R) SQLMaint Utility (Unicode), Version 8.00.760
Copyright (C) Microsoft Corporation, 1995 - 1998
Logged on to SQL Server 'DATABASE2\Dev'
as 'NT AUTHORITY\SYSTEM' (trusted)
[Microsoft SQL-DMO (ODBC SQLState: 28000)] Error 18452:
[Microsoft][ODBC SQL Server Driver][SQL Server]Login
failed for user '(null)'. Reason: Not associated with
a trusted SQL Server connection.
Starting copy for plan DATABASE1\Dev.CMX_Dev_logshipping
Source database - CMX_Dev
Copied 0 files
Finished copy for plan DATABASE1\Dev.CMX_Dev_logshipping
I have two Enterprise SQL Server 2000 machines (Database1 &
Database2). They are not part of any domain. They both are running
SQL Server and Agent under the identical user which has Administration
priviledges. Both machines can see the shared drive and have full
access. The shared drive is on Database1 and Database1 is also
currently the monitoring server.
Any suggestions would be appreciated...
Thanks
Calvin,
I have a related problem (the destination server is in a disaster site
without any domain)
It seems the Windows account who creates and runs the logshipping has
sa access on the destination server
The error suggest you were able to create a login on the destination
server for the user SYSTEM on local domain (=machine) NT AUTHORITY
(this is what a plan to do, but since I cannot browse the domain of
the primary server I plan to fiddle with the host file
Did you assign administrator role to this login ?
HTH
Jan Waumans
On 6 Apr 2004 13:46:10 -0700, CalvinNSlater@.Hotmail.com (Calvin
Slater) wrote:
>I cannot get Log Shipping to work. It does not give any outward
>errors. Everything seams to work correctly except the secondary server
>is not picking up the Transaction logs and applying them. The TRN
>files are being written to a shared directory on the primary server as
>scheduled.
> I tracked down the following error on the scecondary server from the
>Log Shipping copy job.
> Microsoft (R) SQLMaint Utility (Unicode), Version 8.00.760
> Copyright (C) Microsoft Corporation, 1995 - 1998
> Logged on to SQL Server 'DATABASE2\Dev'
> as 'NT AUTHORITY\SYSTEM' (trusted)
> [Microsoft SQL-DMO (ODBC SQLState: 28000)] Error 18452:
> [Microsoft][ODBC SQL Server Driver][SQL Server]Login
> failed for user '(null)'. Reason: Not associated with
> a trusted SQL Server connection.
> Starting copy for plan DATABASE1\Dev.CMX_Dev_logshipping
> Source database - CMX_Dev
> Copied 0 files
> Finished copy for plan DATABASE1\Dev.CMX_Dev_logshipping
>
>I have two Enterprise SQL Server 2000 machines (Database1 &
>Database2). They are not part of any domain. They both are running
>SQL Server and Agent under the identical user which has Administration
>priviledges. Both machines can see the shared drive and have full
>access. The shared drive is on Database1 and Database1 is also
>currently the monitoring server.
>Any suggestions would be appreciated...
>Thanks
Log Shipping not Loading TRN file
I cannot get Log Shipping to work. It does not give any outward
errors. Everything seams to work correctly except the secondary server
is not picking up the Transaction logs and applying them. The TRN
files are being written to a shared directory on the primary server as
scheduled.
I tracked down the following error on the scecondary server from the
Log Shipping copy job.
Microsoft (R) SQLMaint Utility (Unicode), Version 8.00.760
Copyright (C) Microsoft Corporation, 1995 - 1998
Logged on to SQL Server 'DATABASE2\Dev'
as 'NT AUTHORITY\SYSTEM' (trusted)
[Microsoft SQL-DMO (ODBC SQLState: 28000)] Error 18452:
[Microsoft][ODBC SQL Server Driver][SQL Server]Login
failed for user '(null)'. Reason: Not associated with
a trusted SQL Server connection.
Starting copy for plan DATABASE1\Dev.CMX_Dev_logshipping
Source database - CMX_Dev
Copied 0 files
Finished copy for plan DATABASE1\Dev.CMX_Dev_logshipping
I have two Enterprise SQL Server 2000 machines (Database1 &
Database2). They are not part of any domain. They both are running
SQL Server and Agent under the identical user which has Administration
priviledges. Both machines can see the shared drive and have full
access. The shared drive is on Database1 and Database1 is also
currently the monitoring server.
Any suggestions would be appreciated...
ThanksCalvin,
I have a related problem (the destination server is in a disaster site
without any domain)
It seems the Windows account who creates and runs the logshipping has
sa access on the destination server
The error suggest you were able to create a login on the destination
server for the user SYSTEM on local domain (=machine) NT AUTHORITY
(this is what a plan to do, but since I cannot browse the domain of
the primary server I plan to fiddle with the host file
Did you assign administrator role to this login ?
HTH
Jan Waumans
On 6 Apr 2004 13:46:10 -0700, CalvinNSlater@.Hotmail.com (Calvin
Slater) wrote:
>I cannot get Log Shipping to work. It does not give any outward
>errors. Everything seams to work correctly except the secondary server
>is not picking up the Transaction logs and applying them. The TRN
>files are being written to a shared directory on the primary server as
>scheduled.
> I tracked down the following error on the scecondary server from the
>Log Shipping copy job.
> Microsoft (R) SQLMaint Utility (Unicode), Version 8.00.760
> Copyright (C) Microsoft Corporation, 1995 - 1998
> Logged on to SQL Server 'DATABASE2\Dev'
> as 'NT AUTHORITY\SYSTEM' (trusted)
> [Microsoft SQL-DMO (ODBC SQLState: 28000)] Error 18452:
> [Microsoft][ODBC SQL Server Driver][SQL Server]Login
> failed for user '(null)'. Reason: Not associated with
> a trusted SQL Server connection.
> Starting copy for plan DATABASE1\Dev.CMX_Dev_logshipping
> Source database - CMX_Dev
> Copied 0 files
> Finished copy for plan DATABASE1\Dev.CMX_Dev_logshipping
>
>I have two Enterprise SQL Server 2000 machines (Database1 &
>Database2). They are not part of any domain. They both are running
>SQL Server and Agent under the identical user which has Administration
>priviledges. Both machines can see the shared drive and have full
>access. The shared drive is on Database1 and Database1 is also
>currently the monitoring server.
>Any suggestions would be appreciated...
>Thanks
errors. Everything seams to work correctly except the secondary server
is not picking up the Transaction logs and applying them. The TRN
files are being written to a shared directory on the primary server as
scheduled.
I tracked down the following error on the scecondary server from the
Log Shipping copy job.
Microsoft (R) SQLMaint Utility (Unicode), Version 8.00.760
Copyright (C) Microsoft Corporation, 1995 - 1998
Logged on to SQL Server 'DATABASE2\Dev'
as 'NT AUTHORITY\SYSTEM' (trusted)
[Microsoft SQL-DMO (ODBC SQLState: 28000)] Error 18452:
[Microsoft][ODBC SQL Server Driver][SQL Server]Login
failed for user '(null)'. Reason: Not associated with
a trusted SQL Server connection.
Starting copy for plan DATABASE1\Dev.CMX_Dev_logshipping
Source database - CMX_Dev
Copied 0 files
Finished copy for plan DATABASE1\Dev.CMX_Dev_logshipping
I have two Enterprise SQL Server 2000 machines (Database1 &
Database2). They are not part of any domain. They both are running
SQL Server and Agent under the identical user which has Administration
priviledges. Both machines can see the shared drive and have full
access. The shared drive is on Database1 and Database1 is also
currently the monitoring server.
Any suggestions would be appreciated...
ThanksCalvin,
I have a related problem (the destination server is in a disaster site
without any domain)
It seems the Windows account who creates and runs the logshipping has
sa access on the destination server
The error suggest you were able to create a login on the destination
server for the user SYSTEM on local domain (=machine) NT AUTHORITY
(this is what a plan to do, but since I cannot browse the domain of
the primary server I plan to fiddle with the host file
Did you assign administrator role to this login ?
HTH
Jan Waumans
On 6 Apr 2004 13:46:10 -0700, CalvinNSlater@.Hotmail.com (Calvin
Slater) wrote:
>I cannot get Log Shipping to work. It does not give any outward
>errors. Everything seams to work correctly except the secondary server
>is not picking up the Transaction logs and applying them. The TRN
>files are being written to a shared directory on the primary server as
>scheduled.
> I tracked down the following error on the scecondary server from the
>Log Shipping copy job.
> Microsoft (R) SQLMaint Utility (Unicode), Version 8.00.760
> Copyright (C) Microsoft Corporation, 1995 - 1998
> Logged on to SQL Server 'DATABASE2\Dev'
> as 'NT AUTHORITY\SYSTEM' (trusted)
> [Microsoft SQL-DMO (ODBC SQLState: 28000)] Error 18452:
> [Microsoft][ODBC SQL Server Driver][SQL Server]Login
> failed for user '(null)'. Reason: Not associated with
> a trusted SQL Server connection.
> Starting copy for plan DATABASE1\Dev.CMX_Dev_logshipping
> Source database - CMX_Dev
> Copied 0 files
> Finished copy for plan DATABASE1\Dev.CMX_Dev_logshipping
>
>I have two Enterprise SQL Server 2000 machines (Database1 &
>Database2). They are not part of any domain. They both are running
>SQL Server and Agent under the identical user which has Administration
>priviledges. Both machines can see the shared drive and have full
>access. The shared drive is on Database1 and Database1 is also
>currently the monitoring server.
>Any suggestions would be appreciated...
>Thanks
Log Shipping not Loading TRN file
I cannot get Log Shipping to work. It does not give any outward
errors. Everything seams to work correctly except the secondary server
is not picking up the Transaction logs and applying them. The TRN
files are being written to a shared directory on the primary server as
scheduled.
I tracked down the following error on the scecondary server from the
Log Shipping copy job.
Microsoft (R) SQLMaint Utility (Unicode), Version 8.00.760
Copyright (C) Microsoft Corporation, 1995 - 1998
Logged on to SQL Server 'DATABASE2\Dev'
as 'NT AUTHORITY\SYSTEM' (trusted)
[Microsoft SQL-DMO (ODBC SQLState: 28000)] Error 18452:
[Microsoft][ODBC SQL Server Driver][SQL Server]Login
failed for user '(null)'. Reason: Not associated with
a trusted SQL Server connection.
Starting copy for plan DATABASE1\Dev.CMX_Dev_logshipping
Source database - CMX_Dev
Copied 0 files
Finished copy for plan DATABASE1\Dev.CMX_Dev_logshipping
I have two Enterprise SQL Server 2000 machines (Database1 &
Database2). They are not part of any domain. They both are running
SQL Server and Agent under the identical user which has Administration
priviledges. Both machines can see the shared drive and have full
access. The shared drive is on Database1 and Database1 is also
currently the monitoring server.
Any suggestions would be appreciated...
ThanksCalvin,
I have a related problem (the destination server is in a disaster site
without any domain)
It seems the Windows account who creates and runs the logshipping has
sa access on the destination server
The error suggest you were able to create a login on the destination
server for the user SYSTEM on local domain (=machine) NT AUTHORITY
(this is what a plan to do, but since I cannot browse the domain of
the primary server I plan to fiddle with the host file
Did you assign administrator role to this login ?
HTH
Jan Waumans
On 6 Apr 2004 13:46:10 -0700, CalvinNSlater@.Hotmail.com (Calvin
Slater) wrote:
>I cannot get Log Shipping to work. It does not give any outward
>errors. Everything seams to work correctly except the secondary server
>is not picking up the Transaction logs and applying them. The TRN
>files are being written to a shared directory on the primary server as
>scheduled.
> I tracked down the following error on the scecondary server from the
>Log Shipping copy job.
> Microsoft (R) SQLMaint Utility (Unicode), Version 8.00.760
> Copyright (C) Microsoft Corporation, 1995 - 1998
> Logged on to SQL Server 'DATABASE2\Dev'
> as 'NT AUTHORITY\SYSTEM' (trusted)
> [Microsoft SQL-DMO (ODBC SQLState: 28000)] Error 18452:
> [Microsoft][ODBC SQL Server Driver][SQL Server]Login
> failed for user '(null)'. Reason: Not associated with
> a trusted SQL Server connection.
> Starting copy for plan DATABASE1\Dev.CMX_Dev_logshipping
> Source database - CMX_Dev
> Copied 0 files
> Finished copy for plan DATABASE1\Dev.CMX_Dev_logshipping
>
>I have two Enterprise SQL Server 2000 machines (Database1 &
>Database2). They are not part of any domain. They both are running
>SQL Server and Agent under the identical user which has Administration
>priviledges. Both machines can see the shared drive and have full
>access. The shared drive is on Database1 and Database1 is also
>currently the monitoring server.
>Any suggestions would be appreciated...
>Thanks
errors. Everything seams to work correctly except the secondary server
is not picking up the Transaction logs and applying them. The TRN
files are being written to a shared directory on the primary server as
scheduled.
I tracked down the following error on the scecondary server from the
Log Shipping copy job.
Microsoft (R) SQLMaint Utility (Unicode), Version 8.00.760
Copyright (C) Microsoft Corporation, 1995 - 1998
Logged on to SQL Server 'DATABASE2\Dev'
as 'NT AUTHORITY\SYSTEM' (trusted)
[Microsoft SQL-DMO (ODBC SQLState: 28000)] Error 18452:
[Microsoft][ODBC SQL Server Driver][SQL Server]Login
failed for user '(null)'. Reason: Not associated with
a trusted SQL Server connection.
Starting copy for plan DATABASE1\Dev.CMX_Dev_logshipping
Source database - CMX_Dev
Copied 0 files
Finished copy for plan DATABASE1\Dev.CMX_Dev_logshipping
I have two Enterprise SQL Server 2000 machines (Database1 &
Database2). They are not part of any domain. They both are running
SQL Server and Agent under the identical user which has Administration
priviledges. Both machines can see the shared drive and have full
access. The shared drive is on Database1 and Database1 is also
currently the monitoring server.
Any suggestions would be appreciated...
ThanksCalvin,
I have a related problem (the destination server is in a disaster site
without any domain)
It seems the Windows account who creates and runs the logshipping has
sa access on the destination server
The error suggest you were able to create a login on the destination
server for the user SYSTEM on local domain (=machine) NT AUTHORITY
(this is what a plan to do, but since I cannot browse the domain of
the primary server I plan to fiddle with the host file
Did you assign administrator role to this login ?
HTH
Jan Waumans
On 6 Apr 2004 13:46:10 -0700, CalvinNSlater@.Hotmail.com (Calvin
Slater) wrote:
>I cannot get Log Shipping to work. It does not give any outward
>errors. Everything seams to work correctly except the secondary server
>is not picking up the Transaction logs and applying them. The TRN
>files are being written to a shared directory on the primary server as
>scheduled.
> I tracked down the following error on the scecondary server from the
>Log Shipping copy job.
> Microsoft (R) SQLMaint Utility (Unicode), Version 8.00.760
> Copyright (C) Microsoft Corporation, 1995 - 1998
> Logged on to SQL Server 'DATABASE2\Dev'
> as 'NT AUTHORITY\SYSTEM' (trusted)
> [Microsoft SQL-DMO (ODBC SQLState: 28000)] Error 18452:
> [Microsoft][ODBC SQL Server Driver][SQL Server]Login
> failed for user '(null)'. Reason: Not associated with
> a trusted SQL Server connection.
> Starting copy for plan DATABASE1\Dev.CMX_Dev_logshipping
> Source database - CMX_Dev
> Copied 0 files
> Finished copy for plan DATABASE1\Dev.CMX_Dev_logshipping
>
>I have two Enterprise SQL Server 2000 machines (Database1 &
>Database2). They are not part of any domain. They both are running
>SQL Server and Agent under the identical user which has Administration
>priviledges. Both machines can see the shared drive and have full
>access. The shared drive is on Database1 and Database1 is also
>currently the monitoring server.
>Any suggestions would be appreciated...
>Thanks
Subscribe to:
Posts (Atom)