The Tlog dump as part of Log shipping has got me wondering on how the time
portion of the file name is done. So right now I have a file name called
DBName_20071109204000.trn that was taken at 12:40pm on 11/9/2007. Just
looking at the file, how can you tell the time ? I am using SQL 2005. It was
better in SQL 2000.
ThanksPls refer
http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=1773170&SiteID=1
it uses UTC timing convention I believe !
--
Thanxx
Deepak
"Hassan" wrote:
> The Tlog dump as part of Log shipping has got me wondering on how the time
> portion of the file name is done. So right now I have a file name called
> DBName_20071109204000.trn that was taken at 12:40pm on 11/9/2007. Just
> looking at the file, how can you tell the time ? I am using SQL 2005. It was
> better in SQL 2000.
> Thanks
>
>
>
Showing posts with label time. Show all posts
Showing posts with label time. Show all posts
Wednesday, March 28, 2012
Monday, March 26, 2012
Log Shipping Restore seems to Time out after 10 minutes
While playing with log shipping it appears that the restore is timing out, without errors. The shipper is successfully backing up to disk, xcopying the backup to the receiver, calling the restore SP on the receiver. The restore runs for exactly 10 minutes
and 1 second then ends with a success. Any ideas on what I missed?
Denny,
I'm not sure about this. How do you know it has timed out - do any of the
transactions get applied on the standby server at all?
Regards,
Paul Ibison
|||I am not sure it is timing out, it was only a guess. When it tries to apply the first log it says that database was only partially restored.
If I manually run the retore SP on the receiver, rather than having the shipper call it, it successfully restores the entire backup file then I can ship the logs with no errors.
|||I ran the restore SP via Query Analyzer on the shipping server and I was correct. The error was (OLE/DB provider returned message: Timeout Expired)..
Did I do my linked server incorrectly?
|||Denny,
your setup is sound, as there is no timeout property in log shipping. I
suspect this is something peripheral - it could be network lag, or
alternatively (and possibly more likely) your database is expanding. I have
a KB article that explains this as a potential cause of this issue:
http://support.microsoft.com/default...;EN-US;Q305635
HTH,
Paul Ibison
|||I was able to narrow it down to a timeout setting with the Linked Servers. Both the connection timeout and query timeout had a value of zero entered, which is supposed to be no timeout (assuming I understood the documentation correctly). As soon as I set
the query timeout to 1200 seconds everything works fine. I will probably set it to 1800 seconds, I'd imagine 30 minutes would be more than enough time to restore from a file.
|||Denny,
but log-shipping doesn't use linked servers. Is this perhaps a custom
inplementation?
Regards,
Paul Ibison
|||Yes it is. I followed the directions from a doc on SQL-Server-Performance. The scheduled task on the production box dumps to disk, copies it to the warm standby server using xcopy, then calls an SP on the warm standby server that restores that file.
|||Denny this makes sense now. If the query timeout is zero, it uses the value
in sp_configure. I thing that you'll find that that is the problem as it is
set too low. Setting the value at the lower level as you have done overrides
the sp_configure value, so that explains why it works now.
Regards,
Paul Ibison
and 1 second then ends with a success. Any ideas on what I missed?
Denny,
I'm not sure about this. How do you know it has timed out - do any of the
transactions get applied on the standby server at all?
Regards,
Paul Ibison
|||I am not sure it is timing out, it was only a guess. When it tries to apply the first log it says that database was only partially restored.
If I manually run the retore SP on the receiver, rather than having the shipper call it, it successfully restores the entire backup file then I can ship the logs with no errors.
|||I ran the restore SP via Query Analyzer on the shipping server and I was correct. The error was (OLE/DB provider returned message: Timeout Expired)..
Did I do my linked server incorrectly?
|||Denny,
your setup is sound, as there is no timeout property in log shipping. I
suspect this is something peripheral - it could be network lag, or
alternatively (and possibly more likely) your database is expanding. I have
a KB article that explains this as a potential cause of this issue:
http://support.microsoft.com/default...;EN-US;Q305635
HTH,
Paul Ibison
|||I was able to narrow it down to a timeout setting with the Linked Servers. Both the connection timeout and query timeout had a value of zero entered, which is supposed to be no timeout (assuming I understood the documentation correctly). As soon as I set
the query timeout to 1200 seconds everything works fine. I will probably set it to 1800 seconds, I'd imagine 30 minutes would be more than enough time to restore from a file.
|||Denny,
but log-shipping doesn't use linked servers. Is this perhaps a custom
inplementation?
Regards,
Paul Ibison
|||Yes it is. I followed the directions from a doc on SQL-Server-Performance. The scheduled task on the production box dumps to disk, copies it to the warm standby server using xcopy, then calls an SP on the warm standby server that restores that file.
|||Denny this makes sense now. If the query timeout is zero, it uses the value
in sp_configure. I thing that you'll find that that is the problem as it is
set too low. Setting the value at the lower level as you have done overrides
the sp_configure value, so that explains why it works now.
Regards,
Paul Ibison
log shipping question on two databases
Hi,
I created 2 log shipping plans at the same time, for database dbA and dbB
respectively, to ship logs to antother database server.
All the log transaction schedule and location are the same.
However, only log shipping plan for dbA succeed.
Is there any restriction on log shipping for 2 databases at the same time?
Thanks for help.
Jason
No, there is no such restriction. You can can configure two databases from
the same instance for log shipping.
Ben Nevarez
Senior Database Administrator
AIG SunAmerica
"Jason Huang" wrote:
> Hi,
> I created 2 log shipping plans at the same time, for database dbA and dbB
> respectively, to ship logs to antother database server.
> All the log transaction schedule and location are the same.
> However, only log shipping plan for dbA succeed.
> Is there any restriction on log shipping for 2 databases at the same time?
> Thanks for help.
>
> Jason
>
>
I created 2 log shipping plans at the same time, for database dbA and dbB
respectively, to ship logs to antother database server.
All the log transaction schedule and location are the same.
However, only log shipping plan for dbA succeed.
Is there any restriction on log shipping for 2 databases at the same time?
Thanks for help.
Jason
No, there is no such restriction. You can can configure two databases from
the same instance for log shipping.
Ben Nevarez
Senior Database Administrator
AIG SunAmerica
"Jason Huang" wrote:
> Hi,
> I created 2 log shipping plans at the same time, for database dbA and dbB
> respectively, to ship logs to antother database server.
> All the log transaction schedule and location are the same.
> However, only log shipping plan for dbA succeed.
> Is there any restriction on log shipping for 2 databases at the same time?
> Thanks for help.
>
> Jason
>
>
log shipping question on two databases
Hi,
I created 2 log shipping plans at the same time, for database dbA and dbB
respectively, to ship logs to antother database server.
All the log transaction schedule and location are the same.
However, only log shipping plan for dbA succeed.
Is there any restriction on log shipping for 2 databases at the same time?
Thanks for help.
JasonNo, there is no such restriction. You can can configure two databases from
the same instance for log shipping.
Ben Nevarez
Senior Database Administrator
AIG SunAmerica
"Jason Huang" wrote:
> Hi,
> I created 2 log shipping plans at the same time, for database dbA and dbB
> respectively, to ship logs to antother database server.
> All the log transaction schedule and location are the same.
> However, only log shipping plan for dbA succeed.
> Is there any restriction on log shipping for 2 databases at the same time?
> Thanks for help.
>
> Jason
>
>
I created 2 log shipping plans at the same time, for database dbA and dbB
respectively, to ship logs to antother database server.
All the log transaction schedule and location are the same.
However, only log shipping plan for dbA succeed.
Is there any restriction on log shipping for 2 databases at the same time?
Thanks for help.
JasonNo, there is no such restriction. You can can configure two databases from
the same instance for log shipping.
Ben Nevarez
Senior Database Administrator
AIG SunAmerica
"Jason Huang" wrote:
> Hi,
> I created 2 log shipping plans at the same time, for database dbA and dbB
> respectively, to ship logs to antother database server.
> All the log transaction schedule and location are the same.
> However, only log shipping plan for dbA succeed.
> Is there any restriction on log shipping for 2 databases at the same time?
> Thanks for help.
>
> Jason
>
>
log shipping question on two databases
Hi,
I created 2 log shipping plans at the same time, for database dbA and dbB
respectively, to ship logs to antother database server.
All the log transaction schedule and location are the same.
However, only log shipping plan for dbA succeed.
Is there any restriction on log shipping for 2 databases at the same time?
Thanks for help.
JasonNo, there is no such restriction. You can can configure two databases from
the same instance for log shipping.
Ben Nevarez
Senior Database Administrator
AIG SunAmerica
"Jason Huang" wrote:
> Hi,
> I created 2 log shipping plans at the same time, for database dbA and dbB
> respectively, to ship logs to antother database server.
> All the log transaction schedule and location are the same.
> However, only log shipping plan for dbA succeed.
> Is there any restriction on log shipping for 2 databases at the same time?
> Thanks for help.
>
> Jason
>
>
I created 2 log shipping plans at the same time, for database dbA and dbB
respectively, to ship logs to antother database server.
All the log transaction schedule and location are the same.
However, only log shipping plan for dbA succeed.
Is there any restriction on log shipping for 2 databases at the same time?
Thanks for help.
JasonNo, there is no such restriction. You can can configure two databases from
the same instance for log shipping.
Ben Nevarez
Senior Database Administrator
AIG SunAmerica
"Jason Huang" wrote:
> Hi,
> I created 2 log shipping plans at the same time, for database dbA and dbB
> respectively, to ship logs to antother database server.
> All the log transaction schedule and location are the same.
> However, only log shipping plan for dbA succeed.
> Is there any restriction on log shipping for 2 databases at the same time?
> Thanks for help.
>
> Jason
>
>
Monday, March 12, 2012
Log shipping fails the second time.
Log shipping fails the second time to restore 5Gb transactional log backup with the following error.
Error 823: [Microsoft][ODBC SQL Server Driver][SQL Server]I/O error (bad page ID)
detected during read at offset 0x000001f340e000 in file 'e:\program files\microsoft sql server\DBName.mdf'.
There is no hardware problem. The restore failed in a test server on the same step with the same error message.
The DBCC CHECKDB does not give any error message.
What it might be?
My guess is that the transaction log backup is corrupt and is laying down a full-page format log record (which contains a full page image) that has a corrupt page ID. Is the source database clean as far as CHECKDB is concerned?|||
CHECKDB does not give any error. The transactional backup got corrupted after indexes rebuild operation. It does not happen every time. Is there any way to check transactional backup integrity?
|||yes its possible to check the integrity of a backup file.just refer this command......
Restore verifyonly from disk='Full path of your tran log file'.........it will check whether all the pages in the trn file are readable and also if the backup set is complete........
Log shipping fails the second time.
Log shipping fails the second time to restore 5Gb transactional log backup with the following error.
Error 823: [Microsoft][ODBC SQL Server Driver][SQL Server]I/O error (bad page ID)
detected during read at offset 0x000001f340e000 in file 'e:\program files\microsoft sql server\DBName.mdf'.
There is no hardware problem. The restore failed in a test server on the same step with the same error message.
The DBCC CHECKDB does not give any error message.
What it might be?
My guess is that the transaction log backup is corrupt and is laying down a full-page format log record (which contains a full page image) that has a corrupt page ID. Is the source database clean as far as CHECKDB is concerned?|||
CHECKDB does not give any error. The transactional backup got corrupted after indexes rebuild operation. It does not happen every time. Is there any way to check transactional backup integrity?
|||yes its possible to check the integrity of a backup file.just refer this command......
Restore verifyonly from disk='Full path of your tran log file'.........it will check whether all the pages in the trn file are readable and also if the backup set is complete........
Friday, March 9, 2012
Log shipping fail over
I assume this is the correct spot for a log shipping question. Pardon if
it's not.
I've set up a log shipping pair (first time) and everything 'appears' to be
running fine, but I have a question about fail over.
In my research I have found that, in order to bring the secondary up as the
primary, I have to run a few procedures. The first of which is to be run on
the primary server to change its role. How would I do this if the server has
crashed? What steps should I take if this is the scenario?
Thanks in advance.
So what's the best fail over method should the primary server crash? This is
how I see it,
1) Run sp_change_secondary_role on the secondary server.
2) Switch app to point to secondary server or rename and re-IP secondary
server.
3) The users log into the application and the app uses one SQL login, so I
assume I don't need to worry too much about resolving logins.
This will get my users back to functional? What about once the old primary
is back up? Should I then run sp_change_primary_role? Or would it be best
to delete the maintenance jobs and recreate the log shipping pair?
Sorry about all of the questions, I've seen plenty of information on how to
change roles if the primary is still functional, but nothing concerning a
primary server crash.
Again, thanks in advance.
"Paul Ibison" wrote:
> Mick,
> you're correct - sp_change_primary_role removes the
> primary server from the maintenance plan and it will not
> usually be possible to do this in reality. The key
> failover procedure is sp_change_secondary_role which gets
> the last log and restores the system with recovery.
> Rgds,
> Paul Ibison (SQL Server MVP)
>
>
|||Mick,
Run sp_change_secondary_role, rename the server and use sp_dropserver,
sp_addserver, restart services. Create the login you require and use
sp_change_users_login if you haven't taken the SID.
There's no simple way of switching back roles to the primary, apart from
setting up a new log shipping pair and reversing the process.
The old maintenance plan at this stage is now defunct and needs to be
removed if the primary server comes online at some later stage.
HTH,
Paul Ibison (SQL Server MVP)
[vbcol=seagreen]
it's not.
I've set up a log shipping pair (first time) and everything 'appears' to be
running fine, but I have a question about fail over.
In my research I have found that, in order to bring the secondary up as the
primary, I have to run a few procedures. The first of which is to be run on
the primary server to change its role. How would I do this if the server has
crashed? What steps should I take if this is the scenario?
Thanks in advance.
So what's the best fail over method should the primary server crash? This is
how I see it,
1) Run sp_change_secondary_role on the secondary server.
2) Switch app to point to secondary server or rename and re-IP secondary
server.
3) The users log into the application and the app uses one SQL login, so I
assume I don't need to worry too much about resolving logins.
This will get my users back to functional? What about once the old primary
is back up? Should I then run sp_change_primary_role? Or would it be best
to delete the maintenance jobs and recreate the log shipping pair?
Sorry about all of the questions, I've seen plenty of information on how to
change roles if the primary is still functional, but nothing concerning a
primary server crash.
Again, thanks in advance.
"Paul Ibison" wrote:
> Mick,
> you're correct - sp_change_primary_role removes the
> primary server from the maintenance plan and it will not
> usually be possible to do this in reality. The key
> failover procedure is sp_change_secondary_role which gets
> the last log and restores the system with recovery.
> Rgds,
> Paul Ibison (SQL Server MVP)
>
>
|||Mick,
Run sp_change_secondary_role, rename the server and use sp_dropserver,
sp_addserver, restart services. Create the login you require and use
sp_change_users_login if you haven't taken the SID.
There's no simple way of switching back roles to the primary, apart from
setting up a new log shipping pair and reversing the process.
The old maintenance plan at this stage is now defunct and needs to be
removed if the primary server comes online at some later stage.
HTH,
Paul Ibison (SQL Server MVP)
[vbcol=seagreen]
Log Shipping Error - Failing to save Secondary Server Configurations Err # 14262
I set up Log Shipping with just 2 servers primary and secondary. When I run from the Wizard for the very first time keeps failing at the stage of saving Secondary Server Configuration info. When i instead run the generated script this problem disappears but then restoring of transactions fails - the process can backup transactions from the Primary server , copy them accross to the secondary and fails on the restore. Any ideas why.
Hi Jonathan
When you use the SSMS UI to configure log shipping and it fails, can you give me the error message that should be available in the error dialog?
When you use the generated script to configure log shipping, but the restore fails, have you had a look at the log_shipping_monitor_error_detail tables on both the primary and seconary servers? These tables are in msdb (see BOL for more information) and should provide detailed error information.
Thanks, Mark
|||Also its good to check whether both the instances have the same MDAC level & service pack, as this will happen if there is such mismatch.
http://www.sql-server-performance.com/sql_server_log_shipping.asp fyi.
|||Hi Satya
Greetings to you. I managed to resolve the problem of failing to save Secondary Server configuration. I reinstalled SQL Server and the problem disappeared. My next challenge is I want to automate my backup strategy where I have Log Shipping between 6am to 8pm backing up transactions at 20 minute interval. Then Log Shipping between 8pm to 10pm at 1 hour interval then Full database backup daily , once a week , once a month etc. in which case I need to disable Log Shipping .
|||Hi there Mark!
Thanks for your interest in my problem. I managed to go over the problem. I reinstalled SQL Server and the problem disappeared. However I have a new challenge. I need to automatically setup Log Shipping between 6am to 8pm backing up transactions at 20 minute intervals then Log shipping between 8pm to 10pm at 1hr intervals then automatically disable Log shipping and do Full Database backup at night like midnight per day ,week etc
|||Hi Jonathan
Glad the problem disappeared.
Do you really need to have two different interval periods for the backups? It is obviously simpler if you only have the one configuration. If you do need the two schedules, then you should be able add a schedule to the backup job that is created. Using the log shipping UI, go to the "Transaction Log Backup Settings" dialog then the "Edit Job" button to pull up the job properties.
Regarding the full backup you do not need to disable log shipping for you to be able to do a full backup. See the topic in BOL titled "Creating Transaction Log Backups" for a description of the log sequence and how transaction log backups are independent of the full backup.
Wednesday, March 7, 2012
Log shipping configuration - HELP
I'm having a difficult time making sence of the schedule SQL Server has
configured for my copy and restore jobs. I can't tie the monitor information
back to any of it.
My log shipping configuration does a backup every 120 minutes between 5AM
and 2:59AM; I run backups @. 3AM. The copy/load Frequency is set to 120
minutes with a load delay is 15 minutes.
Actual results are not what I expected, the log backups occur as expected
5AM, 7AM,9AM ect.., but the copy and restore jobs created on the secondary
are behind by 1 hour. Both the copy and restore jobs are executing on a 6AM,
8AM, 10AM schedule. Cany some one explain why this is happening? It is
causing an out of sync condition.
What effect does the load delay have on the restore job schedule.
Not sure it will help but look at
http://www.mindsdoor.net/SQLAdmin/LogShipping.html
If you want to replace it.
"Jerrick D.H" wrote:
> I'm having a difficult time making sence of the schedule SQL Server has
> configured for my copy and restore jobs. I can't tie the monitor information
> back to any of it.
> My log shipping configuration does a backup every 120 minutes between 5AM
> and 2:59AM; I run backups @. 3AM. The copy/load Frequency is set to 120
> minutes with a load delay is 15 minutes.
> Actual results are not what I expected, the log backups occur as expected
> 5AM, 7AM,9AM ect.., but the copy and restore jobs created on the secondary
> are behind by 1 hour. Both the copy and restore jobs are executing on a 6AM,
> 8AM, 10AM schedule. Cany some one explain why this is happening? It is
> causing an out of sync condition.
> What effect does the load delay have on the restore job schedule.
>
|||Nigel,
Thank you for taking the time to respond. I was using a similar process as
the one documented by mindsdoor, but switched to SQL automated process, and
I like it. Since I could not find a valid reason for the delay, I played
around with the job schedules until they woked they way I wanted them too.
"Nigel Rivett" wrote:
[vbcol=seagreen]
> Not sure it will help but look at
> http://www.mindsdoor.net/SQLAdmin/LogShipping.html
> If you want to replace it.
> "Jerrick D.H" wrote:
configured for my copy and restore jobs. I can't tie the monitor information
back to any of it.
My log shipping configuration does a backup every 120 minutes between 5AM
and 2:59AM; I run backups @. 3AM. The copy/load Frequency is set to 120
minutes with a load delay is 15 minutes.
Actual results are not what I expected, the log backups occur as expected
5AM, 7AM,9AM ect.., but the copy and restore jobs created on the secondary
are behind by 1 hour. Both the copy and restore jobs are executing on a 6AM,
8AM, 10AM schedule. Cany some one explain why this is happening? It is
causing an out of sync condition.
What effect does the load delay have on the restore job schedule.
Not sure it will help but look at
http://www.mindsdoor.net/SQLAdmin/LogShipping.html
If you want to replace it.
"Jerrick D.H" wrote:
> I'm having a difficult time making sence of the schedule SQL Server has
> configured for my copy and restore jobs. I can't tie the monitor information
> back to any of it.
> My log shipping configuration does a backup every 120 minutes between 5AM
> and 2:59AM; I run backups @. 3AM. The copy/load Frequency is set to 120
> minutes with a load delay is 15 minutes.
> Actual results are not what I expected, the log backups occur as expected
> 5AM, 7AM,9AM ect.., but the copy and restore jobs created on the secondary
> are behind by 1 hour. Both the copy and restore jobs are executing on a 6AM,
> 8AM, 10AM schedule. Cany some one explain why this is happening? It is
> causing an out of sync condition.
> What effect does the load delay have on the restore job schedule.
>
|||Nigel,
Thank you for taking the time to respond. I was using a similar process as
the one documented by mindsdoor, but switched to SQL automated process, and
I like it. Since I could not find a valid reason for the delay, I played
around with the job schedules until they woked they way I wanted them too.
"Nigel Rivett" wrote:
[vbcol=seagreen]
> Not sure it will help but look at
> http://www.mindsdoor.net/SQLAdmin/LogShipping.html
> If you want to replace it.
> "Jerrick D.H" wrote:
Monday, February 20, 2012
Log Shipping & Query Plans
I have noticed that on our setup that every time the Log Shipping restore
happens, dm_exec_cached_plans and dm_exec_query_stats get completly whiped
out. Is this normal?
We are running on Sql Server 2005 Enterprise Edition SP1 on Windows Server
2003 R2 EEHi Bryan,
This is the expected behavior based on the current design.
We are considering of changing the design to allow the presevarion of
cached plans after a restore, in the next release of SQL Server.
Regards,
Leo
"Bryan Aldrich" <BryanAldrich@.discussions.microsoft.com> wrote in message
news:F1F94B7D-8664-4658-B73D-6B7137B9B618@.microsoft.com...
>I have noticed that on our setup that every time the Log Shipping restore
> happens, dm_exec_cached_plans and dm_exec_query_stats get completly whiped
> out. Is this normal?
> We are running on Sql Server 2005 Enterprise Edition SP1 on Windows Server
> 2003 R2 EE|||Thanks
"Leo Giakoumakis [MS]" wrote:
> Hi Bryan,
> This is the expected behavior based on the current design.
> We are considering of changing the design to allow the presevarion of
> cached plans after a restore, in the next release of SQL Server.
> Regards,
> Leo
>
> "Bryan Aldrich" <BryanAldrich@.discussions.microsoft.com> wrote in message
> news:F1F94B7D-8664-4658-B73D-6B7137B9B618@.microsoft.com...
> >I have noticed that on our setup that every time the Log Shipping restore
> > happens, dm_exec_cached_plans and dm_exec_query_stats get completly whiped
> > out. Is this normal?
> >
> > We are running on Sql Server 2005 Enterprise Edition SP1 on Windows Server
> > 2003 R2 EE
>
>
happens, dm_exec_cached_plans and dm_exec_query_stats get completly whiped
out. Is this normal?
We are running on Sql Server 2005 Enterprise Edition SP1 on Windows Server
2003 R2 EEHi Bryan,
This is the expected behavior based on the current design.
We are considering of changing the design to allow the presevarion of
cached plans after a restore, in the next release of SQL Server.
Regards,
Leo
"Bryan Aldrich" <BryanAldrich@.discussions.microsoft.com> wrote in message
news:F1F94B7D-8664-4658-B73D-6B7137B9B618@.microsoft.com...
>I have noticed that on our setup that every time the Log Shipping restore
> happens, dm_exec_cached_plans and dm_exec_query_stats get completly whiped
> out. Is this normal?
> We are running on Sql Server 2005 Enterprise Edition SP1 on Windows Server
> 2003 R2 EE|||Thanks
"Leo Giakoumakis [MS]" wrote:
> Hi Bryan,
> This is the expected behavior based on the current design.
> We are considering of changing the design to allow the presevarion of
> cached plans after a restore, in the next release of SQL Server.
> Regards,
> Leo
>
> "Bryan Aldrich" <BryanAldrich@.discussions.microsoft.com> wrote in message
> news:F1F94B7D-8664-4658-B73D-6B7137B9B618@.microsoft.com...
> >I have noticed that on our setup that every time the Log Shipping restore
> > happens, dm_exec_cached_plans and dm_exec_query_stats get completly whiped
> > out. Is this normal?
> >
> > We are running on Sql Server 2005 Enterprise Edition SP1 on Windows Server
> > 2003 R2 EE
>
>
Log Shipping & Query Plans
I have noticed that on our setup that every time the Log Shipping restore
happens, dm_exec_cached_plans and dm_exec_query_stats get completly whiped
out. Is this normal?
We are running on Sql Server 2005 Enterprise Edition SP1 on Windows Server
2003 R2 EE
Hi Bryan,
This is the expected behavior based on the current design.
We are considering of changing the design to allow the presevarion of
cached plans after a restore, in the next release of SQL Server.
Regards,
Leo
"Bryan Aldrich" <BryanAldrich@.discussions.microsoft.com> wrote in message
news:F1F94B7D-8664-4658-B73D-6B7137B9B618@.microsoft.com...
>I have noticed that on our setup that every time the Log Shipping restore
> happens, dm_exec_cached_plans and dm_exec_query_stats get completly whiped
> out. Is this normal?
> We are running on Sql Server 2005 Enterprise Edition SP1 on Windows Server
> 2003 R2 EE
|||Thanks
"Leo Giakoumakis [MS]" wrote:
> Hi Bryan,
> This is the expected behavior based on the current design.
> We are considering of changing the design to allow the presevarion of
> cached plans after a restore, in the next release of SQL Server.
> Regards,
> Leo
>
> "Bryan Aldrich" <BryanAldrich@.discussions.microsoft.com> wrote in message
> news:F1F94B7D-8664-4658-B73D-6B7137B9B618@.microsoft.com...
>
>
happens, dm_exec_cached_plans and dm_exec_query_stats get completly whiped
out. Is this normal?
We are running on Sql Server 2005 Enterprise Edition SP1 on Windows Server
2003 R2 EE
Hi Bryan,
This is the expected behavior based on the current design.
We are considering of changing the design to allow the presevarion of
cached plans after a restore, in the next release of SQL Server.
Regards,
Leo
"Bryan Aldrich" <BryanAldrich@.discussions.microsoft.com> wrote in message
news:F1F94B7D-8664-4658-B73D-6B7137B9B618@.microsoft.com...
>I have noticed that on our setup that every time the Log Shipping restore
> happens, dm_exec_cached_plans and dm_exec_query_stats get completly whiped
> out. Is this normal?
> We are running on Sql Server 2005 Enterprise Edition SP1 on Windows Server
> 2003 R2 EE
|||Thanks
"Leo Giakoumakis [MS]" wrote:
> Hi Bryan,
> This is the expected behavior based on the current design.
> We are considering of changing the design to allow the presevarion of
> cached plans after a restore, in the next release of SQL Server.
> Regards,
> Leo
>
> "Bryan Aldrich" <BryanAldrich@.discussions.microsoft.com> wrote in message
> news:F1F94B7D-8664-4658-B73D-6B7137B9B618@.microsoft.com...
>
>
Log Shipping & Query Plans
I have noticed that on our setup that every time the Log Shipping restore
happens, dm_exec_cached_plans and dm_exec_query_stats get completly whiped
out. Is this normal?
We are running on Sql Server 2005 Enterprise Edition SP1 on Windows Server
2003 R2 EEHi Bryan,
This is the expected behavior based on the current design.
We are considering of changing the design to allow the presevarion of
cached plans after a restore, in the next release of SQL Server.
Regards,
Leo
"Bryan Aldrich" <BryanAldrich@.discussions.microsoft.com> wrote in message
news:F1F94B7D-8664-4658-B73D-6B7137B9B618@.microsoft.com...
>I have noticed that on our setup that every time the Log Shipping restore
> happens, dm_exec_cached_plans and dm_exec_query_stats get completly whiped
> out. Is this normal?
> We are running on Sql Server 2005 Enterprise Edition SP1 on Windows Server
> 2003 R2 EE|||Thanks
"Leo Giakoumakis [MS]" wrote:
> Hi Bryan,
> This is the expected behavior based on the current design.
> We are considering of changing the design to allow the presevarion of
> cached plans after a restore, in the next release of SQL Server.
> Regards,
> Leo
>
> "Bryan Aldrich" <BryanAldrich@.discussions.microsoft.com> wrote in message
> news:F1F94B7D-8664-4658-B73D-6B7137B9B618@.microsoft.com...
>
>
happens, dm_exec_cached_plans and dm_exec_query_stats get completly whiped
out. Is this normal?
We are running on Sql Server 2005 Enterprise Edition SP1 on Windows Server
2003 R2 EEHi Bryan,
This is the expected behavior based on the current design.
We are considering of changing the design to allow the presevarion of
cached plans after a restore, in the next release of SQL Server.
Regards,
Leo
"Bryan Aldrich" <BryanAldrich@.discussions.microsoft.com> wrote in message
news:F1F94B7D-8664-4658-B73D-6B7137B9B618@.microsoft.com...
>I have noticed that on our setup that every time the Log Shipping restore
> happens, dm_exec_cached_plans and dm_exec_query_stats get completly whiped
> out. Is this normal?
> We are running on Sql Server 2005 Enterprise Edition SP1 on Windows Server
> 2003 R2 EE|||Thanks
"Leo Giakoumakis [MS]" wrote:
> Hi Bryan,
> This is the expected behavior based on the current design.
> We are considering of changing the design to allow the presevarion of
> cached plans after a restore, in the next release of SQL Server.
> Regards,
> Leo
>
> "Bryan Aldrich" <BryanAldrich@.discussions.microsoft.com> wrote in message
> news:F1F94B7D-8664-4658-B73D-6B7137B9B618@.microsoft.com...
>
>
Subscribe to:
Comments (Atom)