Hi.
I found this misleading issue and thought I would share it.
We set up a maint plan on a SQL2005 RTM box to rebuild our indexes with a
fillfactor of 90%. After the plan ran, the database grew by about 70% and
the fill factor was actually 10%.
We found the following in the maint plan:
'Change free space per page percentage to:' We entered 10%.
In hindsight, it meant FILLFACTOR and should have been 90%.
Do you also find this misleading?
The documentation (BOL) reads:
Change free space per page percentage to
Drop the indexes on the tables in the database and re-create them with a
new, automatically calculated fill factor, thereby reserving the specified
amount of free space on the index pages. The higher the percentage, the more
free space is reserved on the index pages, and the larger the index grows.
Valid values are from 0 through 100.
It says the HIGHER the percentage, the more free space is reserved. This
should read LOWER?
Is this a 'bug' in the documentation?
Could someone please pass this onto the Microsoft guys. Maybe they know
about this already.
Thanks!
WayneWayne
I agree that it is a little bit confusing
> We set up a maint plan on a SQL2005 RTM box to rebuild our indexes with a
> fillfactor of 90%. After the plan ran, the database grew by about 70% and
> the fill factor was actually 10%.
rebuild indexes is logged operation and needs a free space to rebuild all
indexes
Kalen Delaney said
"The first definition
is correct; fillfactor specifies how full each page should be. 30 means 30%
full, 100 means 100% full. The only special case is 0, which means the leaf
level is full, but there is room for one or two rows per page in the upper
levels of the index tree.
I will report this discrepancy in the Books Online definitions. "
http://groups.google.com/group/microsoft.public.sqlserver.programming/browse_thread/thread/eda35e4b5bedab51/535a1ef3d33f1d88?lnk=st&q=&rnum=3&hl=en#535a1ef3d33f1d88
"Wayne" <Wayne@.discussions.microsoft.com> wrote in message
news:D30307D8-C6C6-4196-AB44-76E2F7958714@.microsoft.com...
> Hi.
> I found this misleading issue and thought I would share it.
> We set up a maint plan on a SQL2005 RTM box to rebuild our indexes with a
> fillfactor of 90%. After the plan ran, the database grew by about 70% and
> the fill factor was actually 10%.
> We found the following in the maint plan:
> 'Change free space per page percentage to:' We entered 10%.
> In hindsight, it meant FILLFACTOR and should have been 90%.
> Do you also find this misleading?
> The documentation (BOL) reads:
>
> Change free space per page percentage to
> Drop the indexes on the tables in the database and re-create them with a
> new, automatically calculated fill factor, thereby reserving the specified
> amount of free space on the index pages. The higher the percentage, the
> more
> free space is reserved on the index pages, and the larger the index grows.
> Valid values are from 0 through 100.
>
> It says the HIGHER the percentage, the more free space is reserved. This
> should read LOWER?
>
> Is this a 'bug' in the documentation?
>
> Could someone please pass this onto the Microsoft guys. Maybe they know
> about this already.
> Thanks!
> Wayne
>|||"Wayne" <Wayne@.discussions.microsoft.com> wrote in message
news:D30307D8-C6C6-4196-AB44-76E2F7958714@.microsoft.com...
> Hi.
> I found this misleading issue and thought I would share it.
> We set up a maint plan on a SQL2005 RTM box to rebuild our indexes with a
> fillfactor of 90%. After the plan ran, the database grew by about 70% and
> the fill factor was actually 10%.
> We found the following in the maint plan:
> 'Change free space per page percentage to:' We entered 10%.
> In hindsight, it meant FILLFACTOR and should have been 90%.
> Do you also find this misleading?
> The documentation (BOL) reads:
>
> Change free space per page percentage to
> Drop the indexes on the tables in the database and re-create them with a
> new, automatically calculated fill factor, thereby reserving the specified
> amount of free space on the index pages. The higher the percentage, the
> more
> free space is reserved on the index pages, and the larger the index grows.
> Valid values are from 0 through 100.
>
> It says the HIGHER the percentage, the more free space is reserved. This
> should read LOWER?
>
> Is this a 'bug' in the documentation?
>
> Could someone please pass this onto the Microsoft guys. Maybe they know
> about this already.
>
Anyone can submit doc bugs. The feedback link at the bottom of the BOL
topics will generate an email that automatically creates a doc bug.
David
Showing posts with label plan. Show all posts
Showing posts with label plan. Show all posts
Thursday, March 29, 2012
Description for fill factor on index rebuild maint plan misleading
Hi.
I found this misleading issue and thought I would share it.
We set up a maint plan on a SQL2005 RTM box to rebuild our indexes with a
fillfactor of 90%. After the plan ran, the database grew by about 70% and
the fill factor was actually 10%.
We found the following in the maint plan:
'Change free space per page percentage to:' We entered 10%.
In hindsight, it meant FILLFACTOR and should have been 90%.
Do you also find this misleading?
The documentation (BOL) reads:
Change free space per page percentage to
Drop the indexes on the tables in the database and re-create them with a
new, automatically calculated fill factor, thereby reserving the specified
amount of free space on the index pages. The higher the percentage, the more
free space is reserved on the index pages, and the larger the index grows.
Valid values are from 0 through 100.
It says the HIGHER the percentage, the more free space is reserved. This
should read LOWER?
Is this a 'bug' in the documentation?
Could someone please pass this onto the Microsoft guys. Maybe they know
about this already.
Thanks!
WayneWayne
I agree that it is a little bit confusing
> We set up a maint plan on a SQL2005 RTM box to rebuild our indexes with a
> fillfactor of 90%. After the plan ran, the database grew by about 70% and
> the fill factor was actually 10%.
rebuild indexes is logged operation and needs a free space to rebuild all
indexes
Kalen Delaney said
"The first definition
is correct; fillfactor specifies how full each page should be. 30 means 30%
full, 100 means 100% full. The only special case is 0, which means the leaf
level is full, but there is room for one or two rows per page in the upper
levels of the index tree.
I will report this discrepancy in the Books Online definitions. "
http://groups.google.com/group/micr...33f1d88
"Wayne" <Wayne@.discussions.microsoft.com> wrote in message
news:D30307D8-C6C6-4196-AB44-76E2F7958714@.microsoft.com...
> Hi.
> I found this misleading issue and thought I would share it.
> We set up a maint plan on a SQL2005 RTM box to rebuild our indexes with a
> fillfactor of 90%. After the plan ran, the database grew by about 70% and
> the fill factor was actually 10%.
> We found the following in the maint plan:
> 'Change free space per page percentage to:' We entered 10%.
> In hindsight, it meant FILLFACTOR and should have been 90%.
> Do you also find this misleading?
> The documentation (BOL) reads:
>
> Change free space per page percentage to
> Drop the indexes on the tables in the database and re-create them with a
> new, automatically calculated fill factor, thereby reserving the specified
> amount of free space on the index pages. The higher the percentage, the
> more
> free space is reserved on the index pages, and the larger the index grows.
> Valid values are from 0 through 100.
>
> It says the HIGHER the percentage, the more free space is reserved. This
> should read LOWER?
>
> Is this a 'bug' in the documentation?
>
> Could someone please pass this onto the Microsoft guys. Maybe they know
> about this already.
> Thanks!
> Wayne
>|||"Wayne" <Wayne@.discussions.microsoft.com> wrote in message
news:D30307D8-C6C6-4196-AB44-76E2F7958714@.microsoft.com...
> Hi.
> I found this misleading issue and thought I would share it.
> We set up a maint plan on a SQL2005 RTM box to rebuild our indexes with a
> fillfactor of 90%. After the plan ran, the database grew by about 70% and
> the fill factor was actually 10%.
> We found the following in the maint plan:
> 'Change free space per page percentage to:' We entered 10%.
> In hindsight, it meant FILLFACTOR and should have been 90%.
> Do you also find this misleading?
> The documentation (BOL) reads:
>
> Change free space per page percentage to
> Drop the indexes on the tables in the database and re-create them with a
> new, automatically calculated fill factor, thereby reserving the specified
> amount of free space on the index pages. The higher the percentage, the
> more
> free space is reserved on the index pages, and the larger the index grows.
> Valid values are from 0 through 100.
>
> It says the HIGHER the percentage, the more free space is reserved. This
> should read LOWER?
>
> Is this a 'bug' in the documentation?
>
> Could someone please pass this onto the Microsoft guys. Maybe they know
> about this already.
>
Anyone can submit doc bugs. The feedback link at the bottom of the BOL
topics will generate an email that automatically creates a doc bug.
David
I found this misleading issue and thought I would share it.
We set up a maint plan on a SQL2005 RTM box to rebuild our indexes with a
fillfactor of 90%. After the plan ran, the database grew by about 70% and
the fill factor was actually 10%.
We found the following in the maint plan:
'Change free space per page percentage to:' We entered 10%.
In hindsight, it meant FILLFACTOR and should have been 90%.
Do you also find this misleading?
The documentation (BOL) reads:
Change free space per page percentage to
Drop the indexes on the tables in the database and re-create them with a
new, automatically calculated fill factor, thereby reserving the specified
amount of free space on the index pages. The higher the percentage, the more
free space is reserved on the index pages, and the larger the index grows.
Valid values are from 0 through 100.
It says the HIGHER the percentage, the more free space is reserved. This
should read LOWER?
Is this a 'bug' in the documentation?
Could someone please pass this onto the Microsoft guys. Maybe they know
about this already.
Thanks!
WayneWayne
I agree that it is a little bit confusing
> We set up a maint plan on a SQL2005 RTM box to rebuild our indexes with a
> fillfactor of 90%. After the plan ran, the database grew by about 70% and
> the fill factor was actually 10%.
rebuild indexes is logged operation and needs a free space to rebuild all
indexes
Kalen Delaney said
"The first definition
is correct; fillfactor specifies how full each page should be. 30 means 30%
full, 100 means 100% full. The only special case is 0, which means the leaf
level is full, but there is room for one or two rows per page in the upper
levels of the index tree.
I will report this discrepancy in the Books Online definitions. "
http://groups.google.com/group/micr...33f1d88
"Wayne" <Wayne@.discussions.microsoft.com> wrote in message
news:D30307D8-C6C6-4196-AB44-76E2F7958714@.microsoft.com...
> Hi.
> I found this misleading issue and thought I would share it.
> We set up a maint plan on a SQL2005 RTM box to rebuild our indexes with a
> fillfactor of 90%. After the plan ran, the database grew by about 70% and
> the fill factor was actually 10%.
> We found the following in the maint plan:
> 'Change free space per page percentage to:' We entered 10%.
> In hindsight, it meant FILLFACTOR and should have been 90%.
> Do you also find this misleading?
> The documentation (BOL) reads:
>
> Change free space per page percentage to
> Drop the indexes on the tables in the database and re-create them with a
> new, automatically calculated fill factor, thereby reserving the specified
> amount of free space on the index pages. The higher the percentage, the
> more
> free space is reserved on the index pages, and the larger the index grows.
> Valid values are from 0 through 100.
>
> It says the HIGHER the percentage, the more free space is reserved. This
> should read LOWER?
>
> Is this a 'bug' in the documentation?
>
> Could someone please pass this onto the Microsoft guys. Maybe they know
> about this already.
> Thanks!
> Wayne
>|||"Wayne" <Wayne@.discussions.microsoft.com> wrote in message
news:D30307D8-C6C6-4196-AB44-76E2F7958714@.microsoft.com...
> Hi.
> I found this misleading issue and thought I would share it.
> We set up a maint plan on a SQL2005 RTM box to rebuild our indexes with a
> fillfactor of 90%. After the plan ran, the database grew by about 70% and
> the fill factor was actually 10%.
> We found the following in the maint plan:
> 'Change free space per page percentage to:' We entered 10%.
> In hindsight, it meant FILLFACTOR and should have been 90%.
> Do you also find this misleading?
> The documentation (BOL) reads:
>
> Change free space per page percentage to
> Drop the indexes on the tables in the database and re-create them with a
> new, automatically calculated fill factor, thereby reserving the specified
> amount of free space on the index pages. The higher the percentage, the
> more
> free space is reserved on the index pages, and the larger the index grows.
> Valid values are from 0 through 100.
>
> It says the HIGHER the percentage, the more free space is reserved. This
> should read LOWER?
>
> Is this a 'bug' in the documentation?
>
> Could someone please pass this onto the Microsoft guys. Maybe they know
> about this already.
>
Anyone can submit doc bugs. The feedback link at the bottom of the BOL
topics will generate an email that automatically creates a doc bug.
David
Sunday, March 25, 2012
Deprecated features in 2005
Hello folks,
I am currently working on a project plan to move from SQL7/NT4 to
SQL2005/Win2003 and I am putting together a documentation for our developers
regarding new features and deprecated features in 2005.
Can you point me to a detailed ducumentation on the programming side?
Thanks a lot.http://msdn2.microsoft.com/en-us/library/ms143729(en-US,SQL.90).aspx
and
http://msdn2.microsoft.com/en-us/library/ms144262.aspx
Tony Rogerson
SQL Server MVP
http://sqlblogcasts.com/blogs/tonyrogerson - technical commentary from a SQL
Server Consultant
http://sqlserverfaq.com - free video tutorials
"Ata John" <AtaJohn@.discussions.microsoft.com> wrote in message
news:67622D5C-D5C8-4F16-89FA-2CDFD6730F01@.microsoft.com...
> Hello folks,
> I am currently working on a project plan to move from SQL7/NT4 to
> SQL2005/Win2003 and I am putting together a documentation for our
> developers
> regarding new features and deprecated features in 2005.
> Can you point me to a detailed ducumentation on the programming side?
> Thanks a lot.|||On Tue, 23 May 2006 22:22:23 +0100, "Tony Rogerson"
<tonyrogerson@.sqlserverfaq.com> wrote:
>http://msdn2.microsoft.com/en-us/library/ms143729(en-US,SQL.90).aspx
>and
>http://msdn2.microsoft.com/en-us/library/ms144262.aspx
One level up the tree from those:
http://msdn2.microsoft.com/en-us/library/ms143532.aspx
there are two more important links:
"Database Engine feature changes that might require changes to
applications."
http://msdn2.microsoft.com/en-us/library/ms143179.aspx
"Other changes in behavior to database features in this release."
http://msdn2.microsoft.com/en-us/library/ms143359.aspx
Roy Harvey
Beacon Falls, CTsql
I am currently working on a project plan to move from SQL7/NT4 to
SQL2005/Win2003 and I am putting together a documentation for our developers
regarding new features and deprecated features in 2005.
Can you point me to a detailed ducumentation on the programming side?
Thanks a lot.http://msdn2.microsoft.com/en-us/library/ms143729(en-US,SQL.90).aspx
and
http://msdn2.microsoft.com/en-us/library/ms144262.aspx
Tony Rogerson
SQL Server MVP
http://sqlblogcasts.com/blogs/tonyrogerson - technical commentary from a SQL
Server Consultant
http://sqlserverfaq.com - free video tutorials
"Ata John" <AtaJohn@.discussions.microsoft.com> wrote in message
news:67622D5C-D5C8-4F16-89FA-2CDFD6730F01@.microsoft.com...
> Hello folks,
> I am currently working on a project plan to move from SQL7/NT4 to
> SQL2005/Win2003 and I am putting together a documentation for our
> developers
> regarding new features and deprecated features in 2005.
> Can you point me to a detailed ducumentation on the programming side?
> Thanks a lot.|||On Tue, 23 May 2006 22:22:23 +0100, "Tony Rogerson"
<tonyrogerson@.sqlserverfaq.com> wrote:
>http://msdn2.microsoft.com/en-us/library/ms143729(en-US,SQL.90).aspx
>and
>http://msdn2.microsoft.com/en-us/library/ms144262.aspx
One level up the tree from those:
http://msdn2.microsoft.com/en-us/library/ms143532.aspx
there are two more important links:
"Database Engine feature changes that might require changes to
applications."
http://msdn2.microsoft.com/en-us/library/ms143179.aspx
"Other changes in behavior to database features in this release."
http://msdn2.microsoft.com/en-us/library/ms143359.aspx
Roy Harvey
Beacon Falls, CTsql
Friday, March 9, 2012
Deploying DB Maintenance plan in SQL 2005 across many differentservers
I am in the process of depolying a database maintenance plan tasks for
several servers. I have designed one using the Databases maintenance
plan wizard but I want to be able to replicate the same maintenance
plan for all the SQL instances in our environment. I want to avoid to
manually create them for each and every instance? If possible I want
to also avoid importing this from other servers, I am looking to see
if there is a way to script it all.
Is there a way to deploy the same database maintenance plan for all
the SQL instances in a automated fashion? What will be the most
efficient way to accomplish this?
Any help in this regard will be greatly appreciated.
Thanks
Take a look at SQL Farms and see if it can help out.
Kevin G. Boles
Indicium Resources, Inc.
SQL Server MVP
kgboles a earthlink dt net
"shub" <shubtech@.gmail.com> wrote in message
news:da1295e1-0f53-4b03-8a70-d3ca9903c812@.d21g2000prf.googlegroups.com...
>I am in the process of depolying a database maintenance plan tasks for
> several servers. I have designed one using the Databases maintenance
> plan wizard but I want to be able to replicate the same maintenance
> plan for all the SQL instances in our environment. I want to avoid to
> manually create them for each and every instance? If possible I want
> to also avoid importing this from other servers, I am looking to see
> if there is a way to script it all.
> Is there a way to deploy the same database maintenance plan for all
> the SQL instances in a automated fashion? What will be the most
> efficient way to accomplish this?
> Any help in this regard will be greatly appreciated.
> Thanks
|||On Mar 24, 10:47Xam, "TheSQLGuru" <kgbo...@.earthlink.net> wrote:
> Take a look at SQL Farms and see if it can help out.
> --
> Kevin G. Boles
> Indicium Resources, Inc.
> SQL Server MVP
> kgboles a earthlink dt net
> "shub" <shubt...@.gmail.com> wrote in message
> news:da1295e1-0f53-4b03-8a70-d3ca9903c812@.d21g2000prf.googlegroups.com...
>
>
>
> - Show quoted text -
Thank you so much for your response. Besides this product is there any
other option to deploy database maintenance plan across different
server in SQL 2005?
|||That is one of the down falls of using the maintenance plans. I would create
your own scheduled jobs and custom maintenance sps so that you can script
these and do what you want with them.
Andrew J. Kelly SQL MVP
Solid Quality Mentors
"shub" <shubtech@.gmail.com> wrote in message
news:da1295e1-0f53-4b03-8a70-d3ca9903c812@.d21g2000prf.googlegroups.com...
>I am in the process of depolying a database maintenance plan tasks for
> several servers. I have designed one using the Databases maintenance
> plan wizard but I want to be able to replicate the same maintenance
> plan for all the SQL instances in our environment. I want to avoid to
> manually create them for each and every instance? If possible I want
> to also avoid importing this from other servers, I am looking to see
> if there is a way to script it all.
> Is there a way to deploy the same database maintenance plan for all
> the SQL instances in a automated fashion? What will be the most
> efficient way to accomplish this?
> Any help in this regard will be greatly appreciated.
> Thanks
|||You may be able to generate a script for the plan (not sure about this
though) and then execute that script against each server. Seems that most
objects in SSMS can be scripted out.
I do agree with Andrew that you should consider not using maintenance plans
at all and do/control everything with your own scripts.
Kevin G. Boles
Indicium Resources, Inc.
SQL Server MVP
kgboles a earthlink dt net
"shub" <shubtech@.gmail.com> wrote in message
news:20611010-8c52-4718-982c-4f4400a0b6bc@.s12g2000prg.googlegroups.com...
On Mar 24, 10:47 am, "TheSQLGuru" <kgbo...@.earthlink.net> wrote:
> Take a look at SQL Farms and see if it can help out.
> --
> Kevin G. Boles
> Indicium Resources, Inc.
> SQL Server MVP
> kgboles a earthlink dt net
> "shub" <shubt...@.gmail.com> wrote in message
> news:da1295e1-0f53-4b03-8a70-d3ca9903c812@.d21g2000prf.googlegroups.com...
>
>
>
> - Show quoted text -
Thank you so much for your response. Besides this product is there any
other option to deploy database maintenance plan across different
server in SQL 2005?
|||On Mar 25, 12:54Xpm, "Tibor Karaszi"
<tibor_please.no.email_kara...@.hotmail.nomail.com> wrote:
> I guess one could investigate to export the maint plan to a .dtsx file (a maint plan is an SSIS
> package after all). And use that dtsx file as base for multi-server deployment. Of course, one need
> to investigate how much customization of the dtsx file is needed. For instance, you don't want to
> deploy such file to another server if the old server name is in there somewhere.
> --
> Tibor Karaszi, SQL Server MVPhttp://www.karaszi.com/sqlserver/default.asphttp://sqlblog.com/blogs/tibor_karaszi
>
> "TheSQLGuru" <kgbo...@.earthlink.net> wrote in messagenews:13uievj7t0rja8e@.corp.supernews.com...
>
>
>
>
>
>
> - Show quoted text -
FWIW - this does work and the only thing that needs to be changed is
the connection. The steps are:
1) Export to dtsx file
2) Open in BIDS
3) Modify the connection to the destination server
4) Import into the destination server
However, this does not import the schedules and can cause problems if
you import over an existing maintenance plan. Once the maintenance
plan has been imported, you still have to open the plan on the
destination server and modify the plan to schedule each sub-plan.
Personally, I have found that it really does not take any longer to
create a new maintenance plan manually than it does to export/modify/
import/update on each destination server.
Jeff
|||And everytime you do something manually you run the risk of making an error
or having some setting different on different servers inadvertently. A well
tested script can be configured to set everything right each time for each
server/DB it needs to act against.
Also, you can easily script job schedules too as well as check for existence
of existing job/maintenance plan prior to stomping on it. :-)
Kevin G. Boles
Indicium Resources, Inc.
SQL Server MVP
kgboles a earthlink dt net
"Jeffrey Williams" <jeff.williams@.sharp.com> wrote in message
news:9b46cf7e-7d44-4473-acdc-458d33c7cb15@.e10g2000prf.googlegroups.com...
On Mar 25, 12:54 pm, "Tibor Karaszi"
<tibor_please.no.email_kara...@.hotmail.nomail.com> wrote:
> I guess one could investigate to export the maint plan to a .dtsx file (a
> maint plan is an SSIS
> package after all). And use that dtsx file as base for multi-server
> deployment. Of course, one need
> to investigate how much customization of the dtsx file is needed. For
> instance, you don't want to
> deploy such file to another server if the old server name is in there
> somewhere.
> --
> Tibor Karaszi, SQL Server
> MVPhttp://www.karaszi.com/sqlserver/default.asphttp://sqlblog.com/blogs/tibor_karaszi
>
> "TheSQLGuru" <kgbo...@.earthlink.net> wrote in
> messagenews:13uievj7t0rja8e@.corp.supernews.com...
>
>
>
>
>
>
> - Show quoted text -
FWIW - this does work and the only thing that needs to be changed is
the connection. The steps are:
1) Export to dtsx file
2) Open in BIDS
3) Modify the connection to the destination server
4) Import into the destination server
However, this does not import the schedules and can cause problems if
you import over an existing maintenance plan. Once the maintenance
plan has been imported, you still have to open the plan on the
destination server and modify the plan to schedule each sub-plan.
Personally, I have found that it really does not take any longer to
create a new maintenance plan manually than it does to export/modify/
import/update on each destination server.
Jeff
|||In addition you may not have the same DB's on each server so unless you
chose it to do all dbs it will fail as well.
Andrew J. Kelly SQL MVP
Solid Quality Mentors
"TheSQLGuru" <kgboles@.earthlink.net> wrote in message
news:13uis61kv2i4n92@.corp.supernews.com...
> And everytime you do something manually you run the risk of making an
> error or having some setting different on different servers inadvertently.
> A well tested script can be configured to set everything right each time
> for each server/DB it needs to act against.
> Also, you can easily script job schedules too as well as check for
> existence of existing job/maintenance plan prior to stomping on it. :-)
>
> --
> Kevin G. Boles
> Indicium Resources, Inc.
> SQL Server MVP
> kgboles a earthlink dt net
>
> "Jeffrey Williams" <jeff.williams@.sharp.com> wrote in message
> news:9b46cf7e-7d44-4473-acdc-458d33c7cb15@.e10g2000prf.googlegroups.com...
> On Mar 25, 12:54 pm, "Tibor Karaszi"
> <tibor_please.no.email_kara...@.hotmail.nomail.com> wrote:
> FWIW - this does work and the only thing that needs to be changed is
> the connection. The steps are:
> 1) Export to dtsx file
> 2) Open in BIDS
> 3) Modify the connection to the destination server
> 4) Import into the destination server
> However, this does not import the schedules and can cause problems if
> you import over an existing maintenance plan. Once the maintenance
> plan has been imported, you still have to open the plan on the
> destination server and modify the plan to schedule each sub-plan.
> Personally, I have found that it really does not take any longer to
> create a new maintenance plan manually than it does to export/modify/
> import/update on each destination server.
> Jeff
>
several servers. I have designed one using the Databases maintenance
plan wizard but I want to be able to replicate the same maintenance
plan for all the SQL instances in our environment. I want to avoid to
manually create them for each and every instance? If possible I want
to also avoid importing this from other servers, I am looking to see
if there is a way to script it all.
Is there a way to deploy the same database maintenance plan for all
the SQL instances in a automated fashion? What will be the most
efficient way to accomplish this?
Any help in this regard will be greatly appreciated.
Thanks
Take a look at SQL Farms and see if it can help out.
Kevin G. Boles
Indicium Resources, Inc.
SQL Server MVP
kgboles a earthlink dt net
"shub" <shubtech@.gmail.com> wrote in message
news:da1295e1-0f53-4b03-8a70-d3ca9903c812@.d21g2000prf.googlegroups.com...
>I am in the process of depolying a database maintenance plan tasks for
> several servers. I have designed one using the Databases maintenance
> plan wizard but I want to be able to replicate the same maintenance
> plan for all the SQL instances in our environment. I want to avoid to
> manually create them for each and every instance? If possible I want
> to also avoid importing this from other servers, I am looking to see
> if there is a way to script it all.
> Is there a way to deploy the same database maintenance plan for all
> the SQL instances in a automated fashion? What will be the most
> efficient way to accomplish this?
> Any help in this regard will be greatly appreciated.
> Thanks
|||On Mar 24, 10:47Xam, "TheSQLGuru" <kgbo...@.earthlink.net> wrote:
> Take a look at SQL Farms and see if it can help out.
> --
> Kevin G. Boles
> Indicium Resources, Inc.
> SQL Server MVP
> kgboles a earthlink dt net
> "shub" <shubt...@.gmail.com> wrote in message
> news:da1295e1-0f53-4b03-8a70-d3ca9903c812@.d21g2000prf.googlegroups.com...
>
>
>
> - Show quoted text -
Thank you so much for your response. Besides this product is there any
other option to deploy database maintenance plan across different
server in SQL 2005?
|||That is one of the down falls of using the maintenance plans. I would create
your own scheduled jobs and custom maintenance sps so that you can script
these and do what you want with them.
Andrew J. Kelly SQL MVP
Solid Quality Mentors
"shub" <shubtech@.gmail.com> wrote in message
news:da1295e1-0f53-4b03-8a70-d3ca9903c812@.d21g2000prf.googlegroups.com...
>I am in the process of depolying a database maintenance plan tasks for
> several servers. I have designed one using the Databases maintenance
> plan wizard but I want to be able to replicate the same maintenance
> plan for all the SQL instances in our environment. I want to avoid to
> manually create them for each and every instance? If possible I want
> to also avoid importing this from other servers, I am looking to see
> if there is a way to script it all.
> Is there a way to deploy the same database maintenance plan for all
> the SQL instances in a automated fashion? What will be the most
> efficient way to accomplish this?
> Any help in this regard will be greatly appreciated.
> Thanks
|||You may be able to generate a script for the plan (not sure about this
though) and then execute that script against each server. Seems that most
objects in SSMS can be scripted out.
I do agree with Andrew that you should consider not using maintenance plans
at all and do/control everything with your own scripts.
Kevin G. Boles
Indicium Resources, Inc.
SQL Server MVP
kgboles a earthlink dt net
"shub" <shubtech@.gmail.com> wrote in message
news:20611010-8c52-4718-982c-4f4400a0b6bc@.s12g2000prg.googlegroups.com...
On Mar 24, 10:47 am, "TheSQLGuru" <kgbo...@.earthlink.net> wrote:
> Take a look at SQL Farms and see if it can help out.
> --
> Kevin G. Boles
> Indicium Resources, Inc.
> SQL Server MVP
> kgboles a earthlink dt net
> "shub" <shubt...@.gmail.com> wrote in message
> news:da1295e1-0f53-4b03-8a70-d3ca9903c812@.d21g2000prf.googlegroups.com...
>
>
>
> - Show quoted text -
Thank you so much for your response. Besides this product is there any
other option to deploy database maintenance plan across different
server in SQL 2005?
|||On Mar 25, 12:54Xpm, "Tibor Karaszi"
<tibor_please.no.email_kara...@.hotmail.nomail.com> wrote:
> I guess one could investigate to export the maint plan to a .dtsx file (a maint plan is an SSIS
> package after all). And use that dtsx file as base for multi-server deployment. Of course, one need
> to investigate how much customization of the dtsx file is needed. For instance, you don't want to
> deploy such file to another server if the old server name is in there somewhere.
> --
> Tibor Karaszi, SQL Server MVPhttp://www.karaszi.com/sqlserver/default.asphttp://sqlblog.com/blogs/tibor_karaszi
>
> "TheSQLGuru" <kgbo...@.earthlink.net> wrote in messagenews:13uievj7t0rja8e@.corp.supernews.com...
>
>
>
>
>
>
> - Show quoted text -
FWIW - this does work and the only thing that needs to be changed is
the connection. The steps are:
1) Export to dtsx file
2) Open in BIDS
3) Modify the connection to the destination server
4) Import into the destination server
However, this does not import the schedules and can cause problems if
you import over an existing maintenance plan. Once the maintenance
plan has been imported, you still have to open the plan on the
destination server and modify the plan to schedule each sub-plan.
Personally, I have found that it really does not take any longer to
create a new maintenance plan manually than it does to export/modify/
import/update on each destination server.
Jeff
|||And everytime you do something manually you run the risk of making an error
or having some setting different on different servers inadvertently. A well
tested script can be configured to set everything right each time for each
server/DB it needs to act against.
Also, you can easily script job schedules too as well as check for existence
of existing job/maintenance plan prior to stomping on it. :-)
Kevin G. Boles
Indicium Resources, Inc.
SQL Server MVP
kgboles a earthlink dt net
"Jeffrey Williams" <jeff.williams@.sharp.com> wrote in message
news:9b46cf7e-7d44-4473-acdc-458d33c7cb15@.e10g2000prf.googlegroups.com...
On Mar 25, 12:54 pm, "Tibor Karaszi"
<tibor_please.no.email_kara...@.hotmail.nomail.com> wrote:
> I guess one could investigate to export the maint plan to a .dtsx file (a
> maint plan is an SSIS
> package after all). And use that dtsx file as base for multi-server
> deployment. Of course, one need
> to investigate how much customization of the dtsx file is needed. For
> instance, you don't want to
> deploy such file to another server if the old server name is in there
> somewhere.
> --
> Tibor Karaszi, SQL Server
> MVPhttp://www.karaszi.com/sqlserver/default.asphttp://sqlblog.com/blogs/tibor_karaszi
>
> "TheSQLGuru" <kgbo...@.earthlink.net> wrote in
> messagenews:13uievj7t0rja8e@.corp.supernews.com...
>
>
>
>
>
>
> - Show quoted text -
FWIW - this does work and the only thing that needs to be changed is
the connection. The steps are:
1) Export to dtsx file
2) Open in BIDS
3) Modify the connection to the destination server
4) Import into the destination server
However, this does not import the schedules and can cause problems if
you import over an existing maintenance plan. Once the maintenance
plan has been imported, you still have to open the plan on the
destination server and modify the plan to schedule each sub-plan.
Personally, I have found that it really does not take any longer to
create a new maintenance plan manually than it does to export/modify/
import/update on each destination server.
Jeff
|||In addition you may not have the same DB's on each server so unless you
chose it to do all dbs it will fail as well.
Andrew J. Kelly SQL MVP
Solid Quality Mentors
"TheSQLGuru" <kgboles@.earthlink.net> wrote in message
news:13uis61kv2i4n92@.corp.supernews.com...
> And everytime you do something manually you run the risk of making an
> error or having some setting different on different servers inadvertently.
> A well tested script can be configured to set everything right each time
> for each server/DB it needs to act against.
> Also, you can easily script job schedules too as well as check for
> existence of existing job/maintenance plan prior to stomping on it. :-)
>
> --
> Kevin G. Boles
> Indicium Resources, Inc.
> SQL Server MVP
> kgboles a earthlink dt net
>
> "Jeffrey Williams" <jeff.williams@.sharp.com> wrote in message
> news:9b46cf7e-7d44-4473-acdc-458d33c7cb15@.e10g2000prf.googlegroups.com...
> On Mar 25, 12:54 pm, "Tibor Karaszi"
> <tibor_please.no.email_kara...@.hotmail.nomail.com> wrote:
> FWIW - this does work and the only thing that needs to be changed is
> the connection. The steps are:
> 1) Export to dtsx file
> 2) Open in BIDS
> 3) Modify the connection to the destination server
> 4) Import into the destination server
> However, this does not import the schedules and can cause problems if
> you import over an existing maintenance plan. Once the maintenance
> plan has been imported, you still have to open the plan on the
> destination server and modify the plan to schedule each sub-plan.
> Personally, I have found that it really does not take any longer to
> create a new maintenance plan manually than it does to export/modify/
> import/update on each destination server.
> Jeff
>
Deploying DB Maintenance plan in SQL 2005 across many different
I am in the process of depolying a database maintenance plan tasks for
several servers. I have designed one using the Databases maintenance
plan wizard but I want to be able to replicate the same maintenance
plan for all the SQL instances in our environment. I want to avoid to
manually create them for each and every instance? If possible I want
to also avoid importing this from other servers, I am looking to see
if there is a way to script it all.
Is there a way to deploy the same database maintenance plan for all
the SQL instances in a automated fashion? What will be the most
efficient way to accomplish this?
Any help in this regard will be greatly appreciated.
ThanksTake a look at SQL Farms and see if it can help out.
--
Kevin G. Boles
Indicium Resources, Inc.
SQL Server MVP
kgboles a earthlink dt net
"shub" <shubtech@.gmail.com> wrote in message
news:da1295e1-0f53-4b03-8a70-d3ca9903c812@.d21g2000prf.googlegroups.com...
>I am in the process of depolying a database maintenance plan tasks for
> several servers. I have designed one using the Databases maintenance
> plan wizard but I want to be able to replicate the same maintenance
> plan for all the SQL instances in our environment. I want to avoid to
> manually create them for each and every instance? If possible I want
> to also avoid importing this from other servers, I am looking to see
> if there is a way to script it all.
> Is there a way to deploy the same database maintenance plan for all
> the SQL instances in a automated fashion? What will be the most
> efficient way to accomplish this?
> Any help in this regard will be greatly appreciated.
> Thanks|||On Mar 24, 10:47=A0am, "TheSQLGuru" <kgbo...@.earthlink.net> wrote:
> Take a look at SQL Farms and see if it can help out.
> --
> Kevin G. Boles
> Indicium Resources, Inc.
> SQL Server MVP
> kgboles a earthlink dt net
> "shub" <shubt...@.gmail.com> wrote in message
> news:da1295e1-0f53-4b03-8a70-d3ca9903c812@.d21g2000prf.googlegroups.com...
>
> >I am in the process of depolying a database maintenance plan tasks for
> > several servers. I have designed one using the Databases maintenance
> > plan wizard but I want to be able to replicate the same maintenance
> > plan for all the SQL instances in our environment. =A0I want to avoid to=
> > manually create them for each and every instance? If possible I want
> > to also avoid importing this from other servers, I am looking to see
> > if there is a way to script it all.
> > Is there a way to deploy the same database maintenance plan for all
> > the SQL instances in a automated fashion? =A0What will be the most
> > efficient way to accomplish this?
> > Any help in this regard will be greatly appreciated.
> > Thanks- Hide quoted text -
> - Show quoted text -
Thank you so much for your response. Besides this product is there any
other option to deploy database maintenance plan across different
server in SQL 2005?|||That is one of the down falls of using the maintenance plans. I would create
your own scheduled jobs and custom maintenance sps so that you can script
these and do what you want with them.
--
Andrew J. Kelly SQL MVP
Solid Quality Mentors
"shub" <shubtech@.gmail.com> wrote in message
news:da1295e1-0f53-4b03-8a70-d3ca9903c812@.d21g2000prf.googlegroups.com...
>I am in the process of depolying a database maintenance plan tasks for
> several servers. I have designed one using the Databases maintenance
> plan wizard but I want to be able to replicate the same maintenance
> plan for all the SQL instances in our environment. I want to avoid to
> manually create them for each and every instance? If possible I want
> to also avoid importing this from other servers, I am looking to see
> if there is a way to script it all.
> Is there a way to deploy the same database maintenance plan for all
> the SQL instances in a automated fashion? What will be the most
> efficient way to accomplish this?
> Any help in this regard will be greatly appreciated.
> Thanks|||You may be able to generate a script for the plan (not sure about this
though) and then execute that script against each server. Seems that most
objects in SSMS can be scripted out.
I do agree with Andrew that you should consider not using maintenance plans
at all and do/control everything with your own scripts.
--
Kevin G. Boles
Indicium Resources, Inc.
SQL Server MVP
kgboles a earthlink dt net
"shub" <shubtech@.gmail.com> wrote in message
news:20611010-8c52-4718-982c-4f4400a0b6bc@.s12g2000prg.googlegroups.com...
On Mar 24, 10:47 am, "TheSQLGuru" <kgbo...@.earthlink.net> wrote:
> Take a look at SQL Farms and see if it can help out.
> --
> Kevin G. Boles
> Indicium Resources, Inc.
> SQL Server MVP
> kgboles a earthlink dt net
> "shub" <shubt...@.gmail.com> wrote in message
> news:da1295e1-0f53-4b03-8a70-d3ca9903c812@.d21g2000prf.googlegroups.com...
>
> >I am in the process of depolying a database maintenance plan tasks for
> > several servers. I have designed one using the Databases maintenance
> > plan wizard but I want to be able to replicate the same maintenance
> > plan for all the SQL instances in our environment. I want to avoid to
> > manually create them for each and every instance? If possible I want
> > to also avoid importing this from other servers, I am looking to see
> > if there is a way to script it all.
> > Is there a way to deploy the same database maintenance plan for all
> > the SQL instances in a automated fashion? What will be the most
> > efficient way to accomplish this?
> > Any help in this regard will be greatly appreciated.
> > Thanks- Hide quoted text -
> - Show quoted text -
Thank you so much for your response. Besides this product is there any
other option to deploy database maintenance plan across different
server in SQL 2005?|||I guess one could investigate to export the maint plan to a .dtsx file (a maint plan is an SSIS
package after all). And use that dtsx file as base for multi-server deployment. Of course, one need
to investigate how much customization of the dtsx file is needed. For instance, you don't want to
deploy such file to another server if the old server name is in there somewhere.
--
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://sqlblog.com/blogs/tibor_karaszi
"TheSQLGuru" <kgboles@.earthlink.net> wrote in message news:13uievj7t0rja8e@.corp.supernews.com...
> You may be able to generate a script for the plan (not sure about this though) and then execute
> that script against each server. Seems that most objects in SSMS can be scripted out.
> I do agree with Andrew that you should consider not using maintenance plans at all and do/control
> everything with your own scripts.
> --
> Kevin G. Boles
> Indicium Resources, Inc.
> SQL Server MVP
> kgboles a earthlink dt net
>
> "shub" <shubtech@.gmail.com> wrote in message
> news:20611010-8c52-4718-982c-4f4400a0b6bc@.s12g2000prg.googlegroups.com...
> On Mar 24, 10:47 am, "TheSQLGuru" <kgbo...@.earthlink.net> wrote:
>> Take a look at SQL Farms and see if it can help out.
>> --
>> Kevin G. Boles
>> Indicium Resources, Inc.
>> SQL Server MVP
>> kgboles a earthlink dt net
>> "shub" <shubt...@.gmail.com> wrote in message
>> news:da1295e1-0f53-4b03-8a70-d3ca9903c812@.d21g2000prf.googlegroups.com...
>>
>> >I am in the process of depolying a database maintenance plan tasks for
>> > several servers. I have designed one using the Databases maintenance
>> > plan wizard but I want to be able to replicate the same maintenance
>> > plan for all the SQL instances in our environment. I want to avoid to
>> > manually create them for each and every instance? If possible I want
>> > to also avoid importing this from other servers, I am looking to see
>> > if there is a way to script it all.
>> > Is there a way to deploy the same database maintenance plan for all
>> > the SQL instances in a automated fashion? What will be the most
>> > efficient way to accomplish this?
>> > Any help in this regard will be greatly appreciated.
>> > Thanks- Hide quoted text -
>> - Show quoted text -
> Thank you so much for your response. Besides this product is there any
> other option to deploy database maintenance plan across different
> server in SQL 2005?
>|||On Mar 25, 12:54=A0pm, "Tibor Karaszi"
<tibor_please.no.email_kara...@.hotmail.nomail.com> wrote:
> I guess one could investigate to export the maint plan to a .dtsx file (a =maint plan is an SSIS
> package after all). And use that dtsx file as base for multi-server deploy=ment. Of course, one need
> to investigate how much customization of the dtsx file is needed. For inst=ance, you don't want to
> deploy such file to another server if the old server name is in there some=where.
> --
> Tibor Karaszi, SQL Server MVPhttp://www.karaszi.com/sqlserver/default.asph=
ttp://sqlblog.com/blogs/tibor_karaszi
>
> "TheSQLGuru" <kgbo...@.earthlink.net> wrote in messagenews:13uievj7t0rja8e@.=corp.supernews.com...
> > You may be able to generate a script for the plan (not sure about this t=hough) and then execute
> > that script against each server. =A0Seems that most objects in SSMS can =be scripted out.
> > I do agree with Andrew that you should consider not using maintenance pl=ans at all and do/control
> > everything with your own scripts.
> > --
> > Kevin G. Boles
> > Indicium Resources, Inc.
> > SQL Server MVP
> > kgboles a earthlink dt net
> > "shub" <shubt...@.gmail.com> wrote in message
> >news:20611010-8c52-4718-982c-4f4400a0b6bc@.s12g2000prg.googlegroups.com...=
> > On Mar 24, 10:47 am, "TheSQLGuru" <kgbo...@.earthlink.net> wrote:
> >> Take a look at SQL Farms and see if it can help out.
> >> --
> >> Kevin G. Boles
> >> Indicium Resources, Inc.
> >> SQL Server MVP
> >> kgboles a earthlink dt net
> >> "shub" <shubt...@.gmail.com> wrote in message
> >>news:da1295e1-0f53-4b03-8a70-d3ca9903c812@.d21g2000prf.googlegroups.com..=.
> >> >I am in the process of depolying a database maintenance plan tasks for=
> >> > several servers. I have designed one using the Databases maintenance
> >> > plan wizard but I want to be able to replicate the same maintenance
> >> > plan for all the SQL instances in our environment. I want to avoid to=
> >> > manually create them for each and every instance? If possible I want
> >> > to also avoid importing this from other servers, I am looking to see
> >> > if there is a way to script it all.
> >> > Is there a way to deploy the same database maintenance plan for all
> >> > the SQL instances in a automated fashion? What will be the most
> >> > efficient way to accomplish this?
> >> > Any help in this regard will be greatly appreciated.
> >> > Thanks- Hide quoted text -
> >> - Show quoted text -
> > Thank you so much for your response. Besides this product is there any
> > other option to deploy database maintenance plan across different
> > server in SQL 2005... Hide quoted text -
> - Show quoted text -
FWIW - this does work and the only thing that needs to be changed is
the connection. The steps are:
1) Export to dtsx file
2) Open in BIDS
3) Modify the connection to the destination server
4) Import into the destination server
However, this does not import the schedules and can cause problems if
you import over an existing maintenance plan. Once the maintenance
plan has been imported, you still have to open the plan on the
destination server and modify the plan to schedule each sub-plan.
Personally, I have found that it really does not take any longer to
create a new maintenance plan manually than it does to export/modify/
import/update on each destination server.
Jeff|||And everytime you do something manually you run the risk of making an error
or having some setting different on different servers inadvertently. A well
tested script can be configured to set everything right each time for each
server/DB it needs to act against.
Also, you can easily script job schedules too as well as check for existence
of existing job/maintenance plan prior to stomping on it. :-)
Kevin G. Boles
Indicium Resources, Inc.
SQL Server MVP
kgboles a earthlink dt net
"Jeffrey Williams" <jeff.williams@.sharp.com> wrote in message
news:9b46cf7e-7d44-4473-acdc-458d33c7cb15@.e10g2000prf.googlegroups.com...
On Mar 25, 12:54 pm, "Tibor Karaszi"
<tibor_please.no.email_kara...@.hotmail.nomail.com> wrote:
> I guess one could investigate to export the maint plan to a .dtsx file (a
> maint plan is an SSIS
> package after all). And use that dtsx file as base for multi-server
> deployment. Of course, one need
> to investigate how much customization of the dtsx file is needed. For
> instance, you don't want to
> deploy such file to another server if the old server name is in there
> somewhere.
> --
> Tibor Karaszi, SQL Server
> MVPhttp://www.karaszi.com/sqlserver/default.asphttp://sqlblog.com/blogs/tibor_karaszi
>
> "TheSQLGuru" <kgbo...@.earthlink.net> wrote in
> messagenews:13uievj7t0rja8e@.corp.supernews.com...
> > You may be able to generate a script for the plan (not sure about this
> > though) and then execute
> > that script against each server. Seems that most objects in SSMS can be
> > scripted out.
> > I do agree with Andrew that you should consider not using maintenance
> > plans at all and do/control
> > everything with your own scripts.
> > --
> > Kevin G. Boles
> > Indicium Resources, Inc.
> > SQL Server MVP
> > kgboles a earthlink dt net
> > "shub" <shubt...@.gmail.com> wrote in message
> >news:20611010-8c52-4718-982c-4f4400a0b6bc@.s12g2000prg.googlegroups.com...
> > On Mar 24, 10:47 am, "TheSQLGuru" <kgbo...@.earthlink.net> wrote:
> >> Take a look at SQL Farms and see if it can help out.
> >> --
> >> Kevin G. Boles
> >> Indicium Resources, Inc.
> >> SQL Server MVP
> >> kgboles a earthlink dt net
> >> "shub" <shubt...@.gmail.com> wrote in message
> >>news:da1295e1-0f53-4b03-8a70-d3ca9903c812@.d21g2000prf.googlegroups.com...
> >> >I am in the process of depolying a database maintenance plan tasks for
> >> > several servers. I have designed one using the Databases maintenance
> >> > plan wizard but I want to be able to replicate the same maintenance
> >> > plan for all the SQL instances in our environment. I want to avoid to
> >> > manually create them for each and every instance? If possible I want
> >> > to also avoid importing this from other servers, I am looking to see
> >> > if there is a way to script it all.
> >> > Is there a way to deploy the same database maintenance plan for all
> >> > the SQL instances in a automated fashion? What will be the most
> >> > efficient way to accomplish this?
> >> > Any help in this regard will be greatly appreciated.
> >> > Thanks- Hide quoted text -
> >> - Show quoted text -
> > Thank you so much for your response. Besides this product is there any
> > other option to deploy database maintenance plan across different
> > server in SQL 2005... Hide quoted text -
> - Show quoted text -
FWIW - this does work and the only thing that needs to be changed is
the connection. The steps are:
1) Export to dtsx file
2) Open in BIDS
3) Modify the connection to the destination server
4) Import into the destination server
However, this does not import the schedules and can cause problems if
you import over an existing maintenance plan. Once the maintenance
plan has been imported, you still have to open the plan on the
destination server and modify the plan to schedule each sub-plan.
Personally, I have found that it really does not take any longer to
create a new maintenance plan manually than it does to export/modify/
import/update on each destination server.
Jeff|||In addition you may not have the same DB's on each server so unless you
chose it to do all dbs it will fail as well.
--
Andrew J. Kelly SQL MVP
Solid Quality Mentors
"TheSQLGuru" <kgboles@.earthlink.net> wrote in message
news:13uis61kv2i4n92@.corp.supernews.com...
> And everytime you do something manually you run the risk of making an
> error or having some setting different on different servers inadvertently.
> A well tested script can be configured to set everything right each time
> for each server/DB it needs to act against.
> Also, you can easily script job schedules too as well as check for
> existence of existing job/maintenance plan prior to stomping on it. :-)
>
> --
> Kevin G. Boles
> Indicium Resources, Inc.
> SQL Server MVP
> kgboles a earthlink dt net
>
> "Jeffrey Williams" <jeff.williams@.sharp.com> wrote in message
> news:9b46cf7e-7d44-4473-acdc-458d33c7cb15@.e10g2000prf.googlegroups.com...
> On Mar 25, 12:54 pm, "Tibor Karaszi"
> <tibor_please.no.email_kara...@.hotmail.nomail.com> wrote:
>> I guess one could investigate to export the maint plan to a .dtsx file (a
>> maint plan is an SSIS
>> package after all). And use that dtsx file as base for multi-server
>> deployment. Of course, one need
>> to investigate how much customization of the dtsx file is needed. For
>> instance, you don't want to
>> deploy such file to another server if the old server name is in there
>> somewhere.
>> --
>> Tibor Karaszi, SQL Server
>> MVPhttp://www.karaszi.com/sqlserver/default.asphttp://sqlblog.com/blogs/tibor_karaszi
>>
>> "TheSQLGuru" <kgbo...@.earthlink.net> wrote in
>> messagenews:13uievj7t0rja8e@.corp.supernews.com...
>> > You may be able to generate a script for the plan (not sure about this
>> > though) and then execute
>> > that script against each server. Seems that most objects in SSMS can be
>> > scripted out.
>> > I do agree with Andrew that you should consider not using maintenance
>> > plans at all and do/control
>> > everything with your own scripts.
>> > --
>> > Kevin G. Boles
>> > Indicium Resources, Inc.
>> > SQL Server MVP
>> > kgboles a earthlink dt net
>> > "shub" <shubt...@.gmail.com> wrote in message
>> >news:20611010-8c52-4718-982c-4f4400a0b6bc@.s12g2000prg.googlegroups.com...
>> > On Mar 24, 10:47 am, "TheSQLGuru" <kgbo...@.earthlink.net> wrote:
>> >> Take a look at SQL Farms and see if it can help out.
>> >> --
>> >> Kevin G. Boles
>> >> Indicium Resources, Inc.
>> >> SQL Server MVP
>> >> kgboles a earthlink dt net
>> >> "shub" <shubt...@.gmail.com> wrote in message
>> >>news:da1295e1-0f53-4b03-8a70-d3ca9903c812@.d21g2000prf.googlegroups.com...
>> >> >I am in the process of depolying a database maintenance plan tasks
>> >> >for
>> >> > several servers. I have designed one using the Databases maintenance
>> >> > plan wizard but I want to be able to replicate the same maintenance
>> >> > plan for all the SQL instances in our environment. I want to avoid
>> >> > to
>> >> > manually create them for each and every instance? If possible I want
>> >> > to also avoid importing this from other servers, I am looking to see
>> >> > if there is a way to script it all.
>> >> > Is there a way to deploy the same database maintenance plan for all
>> >> > the SQL instances in a automated fashion? What will be the most
>> >> > efficient way to accomplish this?
>> >> > Any help in this regard will be greatly appreciated.
>> >> > Thanks- Hide quoted text -
>> >> - Show quoted text -
>> > Thank you so much for your response. Besides this product is there any
>> > other option to deploy database maintenance plan across different
>> > server in SQL 2005... Hide quoted text -
>> - Show quoted text -
> FWIW - this does work and the only thing that needs to be changed is
> the connection. The steps are:
> 1) Export to dtsx file
> 2) Open in BIDS
> 3) Modify the connection to the destination server
> 4) Import into the destination server
> However, this does not import the schedules and can cause problems if
> you import over an existing maintenance plan. Once the maintenance
> plan has been imported, you still have to open the plan on the
> destination server and modify the plan to schedule each sub-plan.
> Personally, I have found that it really does not take any longer to
> create a new maintenance plan manually than it does to export/modify/
> import/update on each destination server.
> Jeff
>
several servers. I have designed one using the Databases maintenance
plan wizard but I want to be able to replicate the same maintenance
plan for all the SQL instances in our environment. I want to avoid to
manually create them for each and every instance? If possible I want
to also avoid importing this from other servers, I am looking to see
if there is a way to script it all.
Is there a way to deploy the same database maintenance plan for all
the SQL instances in a automated fashion? What will be the most
efficient way to accomplish this?
Any help in this regard will be greatly appreciated.
ThanksTake a look at SQL Farms and see if it can help out.
--
Kevin G. Boles
Indicium Resources, Inc.
SQL Server MVP
kgboles a earthlink dt net
"shub" <shubtech@.gmail.com> wrote in message
news:da1295e1-0f53-4b03-8a70-d3ca9903c812@.d21g2000prf.googlegroups.com...
>I am in the process of depolying a database maintenance plan tasks for
> several servers. I have designed one using the Databases maintenance
> plan wizard but I want to be able to replicate the same maintenance
> plan for all the SQL instances in our environment. I want to avoid to
> manually create them for each and every instance? If possible I want
> to also avoid importing this from other servers, I am looking to see
> if there is a way to script it all.
> Is there a way to deploy the same database maintenance plan for all
> the SQL instances in a automated fashion? What will be the most
> efficient way to accomplish this?
> Any help in this regard will be greatly appreciated.
> Thanks|||On Mar 24, 10:47=A0am, "TheSQLGuru" <kgbo...@.earthlink.net> wrote:
> Take a look at SQL Farms and see if it can help out.
> --
> Kevin G. Boles
> Indicium Resources, Inc.
> SQL Server MVP
> kgboles a earthlink dt net
> "shub" <shubt...@.gmail.com> wrote in message
> news:da1295e1-0f53-4b03-8a70-d3ca9903c812@.d21g2000prf.googlegroups.com...
>
> >I am in the process of depolying a database maintenance plan tasks for
> > several servers. I have designed one using the Databases maintenance
> > plan wizard but I want to be able to replicate the same maintenance
> > plan for all the SQL instances in our environment. =A0I want to avoid to=
> > manually create them for each and every instance? If possible I want
> > to also avoid importing this from other servers, I am looking to see
> > if there is a way to script it all.
> > Is there a way to deploy the same database maintenance plan for all
> > the SQL instances in a automated fashion? =A0What will be the most
> > efficient way to accomplish this?
> > Any help in this regard will be greatly appreciated.
> > Thanks- Hide quoted text -
> - Show quoted text -
Thank you so much for your response. Besides this product is there any
other option to deploy database maintenance plan across different
server in SQL 2005?|||That is one of the down falls of using the maintenance plans. I would create
your own scheduled jobs and custom maintenance sps so that you can script
these and do what you want with them.
--
Andrew J. Kelly SQL MVP
Solid Quality Mentors
"shub" <shubtech@.gmail.com> wrote in message
news:da1295e1-0f53-4b03-8a70-d3ca9903c812@.d21g2000prf.googlegroups.com...
>I am in the process of depolying a database maintenance plan tasks for
> several servers. I have designed one using the Databases maintenance
> plan wizard but I want to be able to replicate the same maintenance
> plan for all the SQL instances in our environment. I want to avoid to
> manually create them for each and every instance? If possible I want
> to also avoid importing this from other servers, I am looking to see
> if there is a way to script it all.
> Is there a way to deploy the same database maintenance plan for all
> the SQL instances in a automated fashion? What will be the most
> efficient way to accomplish this?
> Any help in this regard will be greatly appreciated.
> Thanks|||You may be able to generate a script for the plan (not sure about this
though) and then execute that script against each server. Seems that most
objects in SSMS can be scripted out.
I do agree with Andrew that you should consider not using maintenance plans
at all and do/control everything with your own scripts.
--
Kevin G. Boles
Indicium Resources, Inc.
SQL Server MVP
kgboles a earthlink dt net
"shub" <shubtech@.gmail.com> wrote in message
news:20611010-8c52-4718-982c-4f4400a0b6bc@.s12g2000prg.googlegroups.com...
On Mar 24, 10:47 am, "TheSQLGuru" <kgbo...@.earthlink.net> wrote:
> Take a look at SQL Farms and see if it can help out.
> --
> Kevin G. Boles
> Indicium Resources, Inc.
> SQL Server MVP
> kgboles a earthlink dt net
> "shub" <shubt...@.gmail.com> wrote in message
> news:da1295e1-0f53-4b03-8a70-d3ca9903c812@.d21g2000prf.googlegroups.com...
>
> >I am in the process of depolying a database maintenance plan tasks for
> > several servers. I have designed one using the Databases maintenance
> > plan wizard but I want to be able to replicate the same maintenance
> > plan for all the SQL instances in our environment. I want to avoid to
> > manually create them for each and every instance? If possible I want
> > to also avoid importing this from other servers, I am looking to see
> > if there is a way to script it all.
> > Is there a way to deploy the same database maintenance plan for all
> > the SQL instances in a automated fashion? What will be the most
> > efficient way to accomplish this?
> > Any help in this regard will be greatly appreciated.
> > Thanks- Hide quoted text -
> - Show quoted text -
Thank you so much for your response. Besides this product is there any
other option to deploy database maintenance plan across different
server in SQL 2005?|||I guess one could investigate to export the maint plan to a .dtsx file (a maint plan is an SSIS
package after all). And use that dtsx file as base for multi-server deployment. Of course, one need
to investigate how much customization of the dtsx file is needed. For instance, you don't want to
deploy such file to another server if the old server name is in there somewhere.
--
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://sqlblog.com/blogs/tibor_karaszi
"TheSQLGuru" <kgboles@.earthlink.net> wrote in message news:13uievj7t0rja8e@.corp.supernews.com...
> You may be able to generate a script for the plan (not sure about this though) and then execute
> that script against each server. Seems that most objects in SSMS can be scripted out.
> I do agree with Andrew that you should consider not using maintenance plans at all and do/control
> everything with your own scripts.
> --
> Kevin G. Boles
> Indicium Resources, Inc.
> SQL Server MVP
> kgboles a earthlink dt net
>
> "shub" <shubtech@.gmail.com> wrote in message
> news:20611010-8c52-4718-982c-4f4400a0b6bc@.s12g2000prg.googlegroups.com...
> On Mar 24, 10:47 am, "TheSQLGuru" <kgbo...@.earthlink.net> wrote:
>> Take a look at SQL Farms and see if it can help out.
>> --
>> Kevin G. Boles
>> Indicium Resources, Inc.
>> SQL Server MVP
>> kgboles a earthlink dt net
>> "shub" <shubt...@.gmail.com> wrote in message
>> news:da1295e1-0f53-4b03-8a70-d3ca9903c812@.d21g2000prf.googlegroups.com...
>>
>> >I am in the process of depolying a database maintenance plan tasks for
>> > several servers. I have designed one using the Databases maintenance
>> > plan wizard but I want to be able to replicate the same maintenance
>> > plan for all the SQL instances in our environment. I want to avoid to
>> > manually create them for each and every instance? If possible I want
>> > to also avoid importing this from other servers, I am looking to see
>> > if there is a way to script it all.
>> > Is there a way to deploy the same database maintenance plan for all
>> > the SQL instances in a automated fashion? What will be the most
>> > efficient way to accomplish this?
>> > Any help in this regard will be greatly appreciated.
>> > Thanks- Hide quoted text -
>> - Show quoted text -
> Thank you so much for your response. Besides this product is there any
> other option to deploy database maintenance plan across different
> server in SQL 2005?
>|||On Mar 25, 12:54=A0pm, "Tibor Karaszi"
<tibor_please.no.email_kara...@.hotmail.nomail.com> wrote:
> I guess one could investigate to export the maint plan to a .dtsx file (a =maint plan is an SSIS
> package after all). And use that dtsx file as base for multi-server deploy=ment. Of course, one need
> to investigate how much customization of the dtsx file is needed. For inst=ance, you don't want to
> deploy such file to another server if the old server name is in there some=where.
> --
> Tibor Karaszi, SQL Server MVPhttp://www.karaszi.com/sqlserver/default.asph=
ttp://sqlblog.com/blogs/tibor_karaszi
>
> "TheSQLGuru" <kgbo...@.earthlink.net> wrote in messagenews:13uievj7t0rja8e@.=corp.supernews.com...
> > You may be able to generate a script for the plan (not sure about this t=hough) and then execute
> > that script against each server. =A0Seems that most objects in SSMS can =be scripted out.
> > I do agree with Andrew that you should consider not using maintenance pl=ans at all and do/control
> > everything with your own scripts.
> > --
> > Kevin G. Boles
> > Indicium Resources, Inc.
> > SQL Server MVP
> > kgboles a earthlink dt net
> > "shub" <shubt...@.gmail.com> wrote in message
> >news:20611010-8c52-4718-982c-4f4400a0b6bc@.s12g2000prg.googlegroups.com...=
> > On Mar 24, 10:47 am, "TheSQLGuru" <kgbo...@.earthlink.net> wrote:
> >> Take a look at SQL Farms and see if it can help out.
> >> --
> >> Kevin G. Boles
> >> Indicium Resources, Inc.
> >> SQL Server MVP
> >> kgboles a earthlink dt net
> >> "shub" <shubt...@.gmail.com> wrote in message
> >>news:da1295e1-0f53-4b03-8a70-d3ca9903c812@.d21g2000prf.googlegroups.com..=.
> >> >I am in the process of depolying a database maintenance plan tasks for=
> >> > several servers. I have designed one using the Databases maintenance
> >> > plan wizard but I want to be able to replicate the same maintenance
> >> > plan for all the SQL instances in our environment. I want to avoid to=
> >> > manually create them for each and every instance? If possible I want
> >> > to also avoid importing this from other servers, I am looking to see
> >> > if there is a way to script it all.
> >> > Is there a way to deploy the same database maintenance plan for all
> >> > the SQL instances in a automated fashion? What will be the most
> >> > efficient way to accomplish this?
> >> > Any help in this regard will be greatly appreciated.
> >> > Thanks- Hide quoted text -
> >> - Show quoted text -
> > Thank you so much for your response. Besides this product is there any
> > other option to deploy database maintenance plan across different
> > server in SQL 2005... Hide quoted text -
> - Show quoted text -
FWIW - this does work and the only thing that needs to be changed is
the connection. The steps are:
1) Export to dtsx file
2) Open in BIDS
3) Modify the connection to the destination server
4) Import into the destination server
However, this does not import the schedules and can cause problems if
you import over an existing maintenance plan. Once the maintenance
plan has been imported, you still have to open the plan on the
destination server and modify the plan to schedule each sub-plan.
Personally, I have found that it really does not take any longer to
create a new maintenance plan manually than it does to export/modify/
import/update on each destination server.
Jeff|||And everytime you do something manually you run the risk of making an error
or having some setting different on different servers inadvertently. A well
tested script can be configured to set everything right each time for each
server/DB it needs to act against.
Also, you can easily script job schedules too as well as check for existence
of existing job/maintenance plan prior to stomping on it. :-)
Kevin G. Boles
Indicium Resources, Inc.
SQL Server MVP
kgboles a earthlink dt net
"Jeffrey Williams" <jeff.williams@.sharp.com> wrote in message
news:9b46cf7e-7d44-4473-acdc-458d33c7cb15@.e10g2000prf.googlegroups.com...
On Mar 25, 12:54 pm, "Tibor Karaszi"
<tibor_please.no.email_kara...@.hotmail.nomail.com> wrote:
> I guess one could investigate to export the maint plan to a .dtsx file (a
> maint plan is an SSIS
> package after all). And use that dtsx file as base for multi-server
> deployment. Of course, one need
> to investigate how much customization of the dtsx file is needed. For
> instance, you don't want to
> deploy such file to another server if the old server name is in there
> somewhere.
> --
> Tibor Karaszi, SQL Server
> MVPhttp://www.karaszi.com/sqlserver/default.asphttp://sqlblog.com/blogs/tibor_karaszi
>
> "TheSQLGuru" <kgbo...@.earthlink.net> wrote in
> messagenews:13uievj7t0rja8e@.corp.supernews.com...
> > You may be able to generate a script for the plan (not sure about this
> > though) and then execute
> > that script against each server. Seems that most objects in SSMS can be
> > scripted out.
> > I do agree with Andrew that you should consider not using maintenance
> > plans at all and do/control
> > everything with your own scripts.
> > --
> > Kevin G. Boles
> > Indicium Resources, Inc.
> > SQL Server MVP
> > kgboles a earthlink dt net
> > "shub" <shubt...@.gmail.com> wrote in message
> >news:20611010-8c52-4718-982c-4f4400a0b6bc@.s12g2000prg.googlegroups.com...
> > On Mar 24, 10:47 am, "TheSQLGuru" <kgbo...@.earthlink.net> wrote:
> >> Take a look at SQL Farms and see if it can help out.
> >> --
> >> Kevin G. Boles
> >> Indicium Resources, Inc.
> >> SQL Server MVP
> >> kgboles a earthlink dt net
> >> "shub" <shubt...@.gmail.com> wrote in message
> >>news:da1295e1-0f53-4b03-8a70-d3ca9903c812@.d21g2000prf.googlegroups.com...
> >> >I am in the process of depolying a database maintenance plan tasks for
> >> > several servers. I have designed one using the Databases maintenance
> >> > plan wizard but I want to be able to replicate the same maintenance
> >> > plan for all the SQL instances in our environment. I want to avoid to
> >> > manually create them for each and every instance? If possible I want
> >> > to also avoid importing this from other servers, I am looking to see
> >> > if there is a way to script it all.
> >> > Is there a way to deploy the same database maintenance plan for all
> >> > the SQL instances in a automated fashion? What will be the most
> >> > efficient way to accomplish this?
> >> > Any help in this regard will be greatly appreciated.
> >> > Thanks- Hide quoted text -
> >> - Show quoted text -
> > Thank you so much for your response. Besides this product is there any
> > other option to deploy database maintenance plan across different
> > server in SQL 2005... Hide quoted text -
> - Show quoted text -
FWIW - this does work and the only thing that needs to be changed is
the connection. The steps are:
1) Export to dtsx file
2) Open in BIDS
3) Modify the connection to the destination server
4) Import into the destination server
However, this does not import the schedules and can cause problems if
you import over an existing maintenance plan. Once the maintenance
plan has been imported, you still have to open the plan on the
destination server and modify the plan to schedule each sub-plan.
Personally, I have found that it really does not take any longer to
create a new maintenance plan manually than it does to export/modify/
import/update on each destination server.
Jeff|||In addition you may not have the same DB's on each server so unless you
chose it to do all dbs it will fail as well.
--
Andrew J. Kelly SQL MVP
Solid Quality Mentors
"TheSQLGuru" <kgboles@.earthlink.net> wrote in message
news:13uis61kv2i4n92@.corp.supernews.com...
> And everytime you do something manually you run the risk of making an
> error or having some setting different on different servers inadvertently.
> A well tested script can be configured to set everything right each time
> for each server/DB it needs to act against.
> Also, you can easily script job schedules too as well as check for
> existence of existing job/maintenance plan prior to stomping on it. :-)
>
> --
> Kevin G. Boles
> Indicium Resources, Inc.
> SQL Server MVP
> kgboles a earthlink dt net
>
> "Jeffrey Williams" <jeff.williams@.sharp.com> wrote in message
> news:9b46cf7e-7d44-4473-acdc-458d33c7cb15@.e10g2000prf.googlegroups.com...
> On Mar 25, 12:54 pm, "Tibor Karaszi"
> <tibor_please.no.email_kara...@.hotmail.nomail.com> wrote:
>> I guess one could investigate to export the maint plan to a .dtsx file (a
>> maint plan is an SSIS
>> package after all). And use that dtsx file as base for multi-server
>> deployment. Of course, one need
>> to investigate how much customization of the dtsx file is needed. For
>> instance, you don't want to
>> deploy such file to another server if the old server name is in there
>> somewhere.
>> --
>> Tibor Karaszi, SQL Server
>> MVPhttp://www.karaszi.com/sqlserver/default.asphttp://sqlblog.com/blogs/tibor_karaszi
>>
>> "TheSQLGuru" <kgbo...@.earthlink.net> wrote in
>> messagenews:13uievj7t0rja8e@.corp.supernews.com...
>> > You may be able to generate a script for the plan (not sure about this
>> > though) and then execute
>> > that script against each server. Seems that most objects in SSMS can be
>> > scripted out.
>> > I do agree with Andrew that you should consider not using maintenance
>> > plans at all and do/control
>> > everything with your own scripts.
>> > --
>> > Kevin G. Boles
>> > Indicium Resources, Inc.
>> > SQL Server MVP
>> > kgboles a earthlink dt net
>> > "shub" <shubt...@.gmail.com> wrote in message
>> >news:20611010-8c52-4718-982c-4f4400a0b6bc@.s12g2000prg.googlegroups.com...
>> > On Mar 24, 10:47 am, "TheSQLGuru" <kgbo...@.earthlink.net> wrote:
>> >> Take a look at SQL Farms and see if it can help out.
>> >> --
>> >> Kevin G. Boles
>> >> Indicium Resources, Inc.
>> >> SQL Server MVP
>> >> kgboles a earthlink dt net
>> >> "shub" <shubt...@.gmail.com> wrote in message
>> >>news:da1295e1-0f53-4b03-8a70-d3ca9903c812@.d21g2000prf.googlegroups.com...
>> >> >I am in the process of depolying a database maintenance plan tasks
>> >> >for
>> >> > several servers. I have designed one using the Databases maintenance
>> >> > plan wizard but I want to be able to replicate the same maintenance
>> >> > plan for all the SQL instances in our environment. I want to avoid
>> >> > to
>> >> > manually create them for each and every instance? If possible I want
>> >> > to also avoid importing this from other servers, I am looking to see
>> >> > if there is a way to script it all.
>> >> > Is there a way to deploy the same database maintenance plan for all
>> >> > the SQL instances in a automated fashion? What will be the most
>> >> > efficient way to accomplish this?
>> >> > Any help in this regard will be greatly appreciated.
>> >> > Thanks- Hide quoted text -
>> >> - Show quoted text -
>> > Thank you so much for your response. Besides this product is there any
>> > other option to deploy database maintenance plan across different
>> > server in SQL 2005... Hide quoted text -
>> - Show quoted text -
> FWIW - this does work and the only thing that needs to be changed is
> the connection. The steps are:
> 1) Export to dtsx file
> 2) Open in BIDS
> 3) Modify the connection to the destination server
> 4) Import into the destination server
> However, this does not import the schedules and can cause problems if
> you import over an existing maintenance plan. Once the maintenance
> plan has been imported, you still have to open the plan on the
> destination server and modify the plan to schedule each sub-plan.
> Personally, I have found that it really does not take any longer to
> create a new maintenance plan manually than it does to export/modify/
> import/update on each destination server.
> Jeff
>
Sunday, February 19, 2012
deploy maintenance plans?
Hi. I have a maintenece plan on my development server that rebuilds
indexes and updates statistics of a certian database that undergoes a
lot of updates of data daily; it also truncates the log file and backs
up the database.
Now, is there any way to script it to deploy it to client computers,
either as is or within a setup routine with names and paths inserted on
the fly?
Oh. This is about SQL Server 2005
|||Eh? Deploy it to client computers?
What do you mean by "it?"
The maintenance plan?
The database(s) that you back up?
What do you mean by "client computer?"
Desktops?
Servers running SQL Server?
To me, a client computer means a desktop or notebook. These computers do
not have SQL Server installed and they should not need a maintenance plan or
a database deployed to it.
I am guessing that many people are confused by your question. If you can
better explan what you want to do perhaps someone will be able to provide an
answer.
Keith Kratochvil
<realgeek@.gmail.com> wrote in message
news:1160060522.143749.302550@.i42g2000cwa.googlegr oups.com...
> Hi. I have a maintenece plan on my development server that rebuilds
> indexes and updates statistics of a certian database that undergoes a
> lot of updates of data daily; it also truncates the log file and backs
> up the database.
> Now, is there any way to script it to deploy it to client computers,
> either as is or within a setup routine with names and paths inserted on
> the fly?
>
|||
> What do you mean by "client computer?"
> Desktops?
> Servers running SQL Server?
> To me, a client computer means a desktop or notebook. These computers do
> not have SQL Server installed and they should not need a maintenance plan or
> a database deployed to it.
>
By it, I mean a maintenance plan, by client computer, I mean client
server, e.g. the place where the application is deployed.
I have an installation script that restores database to a chosen
location from backup provided with installation (the db initially has a
lot of data so I chose that over scripting it), creates and maps logins
etc; I wanted to add maintenance plan creation script to it but I found
no way to script maintenance plan from Management Studio
|||realgeek@.gmail.com wrote:
> By it, I mean a maintenance plan, by client computer, I mean client
> server, e.g. the place where the application is deployed.
> I have an installation script that restores database to a chosen
> location from backup provided with installation (the db initially has a
> lot of data so I chose that over scripting it), creates and maps logins
> etc; I wanted to add maintenance plan creation script to it but I found
> no way to script maintenance plan from Management Studio
>
I think you would be better off NOT using Maintenance Plans in this
manner. Write your own sprocs to do backups, DBCC checks, reindexing,
etc, and deploy those sprocs instead. Much easier to manage and debug
than Maintenance Plans.
Tracy McKibben
MCDBA
http://www.realsqlguy.com
|||I agree 100%
Keith Kratochvil
"Tracy McKibben" <tracy@.realsqlguy.com> wrote in message
news:452B9819.8060707@.realsqlguy.com...
> realgeek@.gmail.com wrote:
> I think you would be better off NOT using Maintenance Plans in this
> manner. Write your own sprocs to do backups, DBCC checks, reindexing,
> etc, and deploy those sprocs instead. Much easier to manage and debug
> than Maintenance Plans.
>
> --
> Tracy McKibben
> MCDBA
> http://www.realsqlguy.com
indexes and updates statistics of a certian database that undergoes a
lot of updates of data daily; it also truncates the log file and backs
up the database.
Now, is there any way to script it to deploy it to client computers,
either as is or within a setup routine with names and paths inserted on
the fly?
Oh. This is about SQL Server 2005
|||Eh? Deploy it to client computers?
What do you mean by "it?"
The maintenance plan?
The database(s) that you back up?
What do you mean by "client computer?"
Desktops?
Servers running SQL Server?
To me, a client computer means a desktop or notebook. These computers do
not have SQL Server installed and they should not need a maintenance plan or
a database deployed to it.
I am guessing that many people are confused by your question. If you can
better explan what you want to do perhaps someone will be able to provide an
answer.
Keith Kratochvil
<realgeek@.gmail.com> wrote in message
news:1160060522.143749.302550@.i42g2000cwa.googlegr oups.com...
> Hi. I have a maintenece plan on my development server that rebuilds
> indexes and updates statistics of a certian database that undergoes a
> lot of updates of data daily; it also truncates the log file and backs
> up the database.
> Now, is there any way to script it to deploy it to client computers,
> either as is or within a setup routine with names and paths inserted on
> the fly?
>
|||
> What do you mean by "client computer?"
> Desktops?
> Servers running SQL Server?
> To me, a client computer means a desktop or notebook. These computers do
> not have SQL Server installed and they should not need a maintenance plan or
> a database deployed to it.
>
By it, I mean a maintenance plan, by client computer, I mean client
server, e.g. the place where the application is deployed.
I have an installation script that restores database to a chosen
location from backup provided with installation (the db initially has a
lot of data so I chose that over scripting it), creates and maps logins
etc; I wanted to add maintenance plan creation script to it but I found
no way to script maintenance plan from Management Studio
|||realgeek@.gmail.com wrote:
> By it, I mean a maintenance plan, by client computer, I mean client
> server, e.g. the place where the application is deployed.
> I have an installation script that restores database to a chosen
> location from backup provided with installation (the db initially has a
> lot of data so I chose that over scripting it), creates and maps logins
> etc; I wanted to add maintenance plan creation script to it but I found
> no way to script maintenance plan from Management Studio
>
I think you would be better off NOT using Maintenance Plans in this
manner. Write your own sprocs to do backups, DBCC checks, reindexing,
etc, and deploy those sprocs instead. Much easier to manage and debug
than Maintenance Plans.
Tracy McKibben
MCDBA
http://www.realsqlguy.com
|||I agree 100%
Keith Kratochvil
"Tracy McKibben" <tracy@.realsqlguy.com> wrote in message
news:452B9819.8060707@.realsqlguy.com...
> realgeek@.gmail.com wrote:
> I think you would be better off NOT using Maintenance Plans in this
> manner. Write your own sprocs to do backups, DBCC checks, reindexing,
> etc, and deploy those sprocs instead. Much easier to manage and debug
> than Maintenance Plans.
>
> --
> Tracy McKibben
> MCDBA
> http://www.realsqlguy.com
deploy maintenance plans?
Hi. I have a maintenece plan on my development server that rebuilds
indexes and updates statistics of a certian database that undergoes a
lot of updates of data daily; it also truncates the log file and backs
up the database.
Now, is there any way to script it to deploy it to client computers,
either as is or within a setup routine with names and paths inserted on
the fly?Oh. This is about SQL Server 2005|||Eh? Deploy it to client computers?
What do you mean by "it?"
The maintenance plan?
The database(s) that you back up?
What do you mean by "client computer?"
Desktops?
Servers running SQL Server?
To me, a client computer means a desktop or notebook. These computers do
not have SQL Server installed and they should not need a maintenance plan or
a database deployed to it.
I am guessing that many people are confused by your question. If you can
better explan what you want to do perhaps someone will be able to provide an
answer.
Keith Kratochvil
<realgeek@.gmail.com> wrote in message
news:1160060522.143749.302550@.i42g2000cwa.googlegroups.com...
> Hi. I have a maintenece plan on my development server that rebuilds
> indexes and updates statistics of a certian database that undergoes a
> lot of updates of data daily; it also truncates the log file and backs
> up the database.
> Now, is there any way to script it to deploy it to client computers,
> either as is or within a setup routine with names and paths inserted on
> the fly?
>|||
> What do you mean by "client computer?"
> Desktops?
> Servers running SQL Server?
> To me, a client computer means a desktop or notebook. These computers do
> not have SQL Server installed and they should not need a maintenance plan
or
> a database deployed to it.
>
By it, I mean a maintenance plan, by client computer, I mean client
server, e.g. the place where the application is deployed.
I have an installation script that restores database to a chosen
location from backup provided with installation (the db initially has a
lot of data so I chose that over scripting it), creates and maps logins
etc; I wanted to add maintenance plan creation script to it but I found
no way to script maintenance plan from Management Studio|||realgeek@.gmail.com wrote:
> By it, I mean a maintenance plan, by client computer, I mean client
> server, e.g. the place where the application is deployed.
> I have an installation script that restores database to a chosen
> location from backup provided with installation (the db initially has a
> lot of data so I chose that over scripting it), creates and maps logins
> etc; I wanted to add maintenance plan creation script to it but I found
> no way to script maintenance plan from Management Studio
>
I think you would be better off NOT using Maintenance Plans in this
manner. Write your own sprocs to do backups, DBCC checks, reindexing,
etc, and deploy those sprocs instead. Much easier to manage and debug
than Maintenance Plans.
Tracy McKibben
MCDBA
http://www.realsqlguy.com|||I agree 100%
Keith Kratochvil
"Tracy McKibben" <tracy@.realsqlguy.com> wrote in message
news:452B9819.8060707@.realsqlguy.com...
> realgeek@.gmail.com wrote:
> I think you would be better off NOT using Maintenance Plans in this
> manner. Write your own sprocs to do backups, DBCC checks, reindexing,
> etc, and deploy those sprocs instead. Much easier to manage and debug
> than Maintenance Plans.
>
> --
> Tracy McKibben
> MCDBA
> http://www.realsqlguy.com
indexes and updates statistics of a certian database that undergoes a
lot of updates of data daily; it also truncates the log file and backs
up the database.
Now, is there any way to script it to deploy it to client computers,
either as is or within a setup routine with names and paths inserted on
the fly?Oh. This is about SQL Server 2005|||Eh? Deploy it to client computers?
What do you mean by "it?"
The maintenance plan?
The database(s) that you back up?
What do you mean by "client computer?"
Desktops?
Servers running SQL Server?
To me, a client computer means a desktop or notebook. These computers do
not have SQL Server installed and they should not need a maintenance plan or
a database deployed to it.
I am guessing that many people are confused by your question. If you can
better explan what you want to do perhaps someone will be able to provide an
answer.
Keith Kratochvil
<realgeek@.gmail.com> wrote in message
news:1160060522.143749.302550@.i42g2000cwa.googlegroups.com...
> Hi. I have a maintenece plan on my development server that rebuilds
> indexes and updates statistics of a certian database that undergoes a
> lot of updates of data daily; it also truncates the log file and backs
> up the database.
> Now, is there any way to script it to deploy it to client computers,
> either as is or within a setup routine with names and paths inserted on
> the fly?
>|||
> What do you mean by "client computer?"
> Desktops?
> Servers running SQL Server?
> To me, a client computer means a desktop or notebook. These computers do
> not have SQL Server installed and they should not need a maintenance plan
or
> a database deployed to it.
>
By it, I mean a maintenance plan, by client computer, I mean client
server, e.g. the place where the application is deployed.
I have an installation script that restores database to a chosen
location from backup provided with installation (the db initially has a
lot of data so I chose that over scripting it), creates and maps logins
etc; I wanted to add maintenance plan creation script to it but I found
no way to script maintenance plan from Management Studio|||realgeek@.gmail.com wrote:
> By it, I mean a maintenance plan, by client computer, I mean client
> server, e.g. the place where the application is deployed.
> I have an installation script that restores database to a chosen
> location from backup provided with installation (the db initially has a
> lot of data so I chose that over scripting it), creates and maps logins
> etc; I wanted to add maintenance plan creation script to it but I found
> no way to script maintenance plan from Management Studio
>
I think you would be better off NOT using Maintenance Plans in this
manner. Write your own sprocs to do backups, DBCC checks, reindexing,
etc, and deploy those sprocs instead. Much easier to manage and debug
than Maintenance Plans.
Tracy McKibben
MCDBA
http://www.realsqlguy.com|||I agree 100%
Keith Kratochvil
"Tracy McKibben" <tracy@.realsqlguy.com> wrote in message
news:452B9819.8060707@.realsqlguy.com...
> realgeek@.gmail.com wrote:
> I think you would be better off NOT using Maintenance Plans in this
> manner. Write your own sprocs to do backups, DBCC checks, reindexing,
> etc, and deploy those sprocs instead. Much easier to manage and debug
> than Maintenance Plans.
>
> --
> Tracy McKibben
> MCDBA
> http://www.realsqlguy.com
deploy maintenance plans?
Hi. I have a maintenece plan on my development server that rebuilds
indexes and updates statistics of a certian database that undergoes a
lot of updates of data daily; it also truncates the log file and backs
up the database.
Now, is there any way to script it to deploy it to client computers,
either as is or within a setup routine with names and paths inserted on
the fly?Oh. This is about SQL Server 2005|||Eh? Deploy it to client computers?
What do you mean by "it?"
The maintenance plan?
The database(s) that you back up?
What do you mean by "client computer?"
Desktops?
Servers running SQL Server?
To me, a client computer means a desktop or notebook. These computers do
not have SQL Server installed and they should not need a maintenance plan or
a database deployed to it.
I am guessing that many people are confused by your question. If you can
better explan what you want to do perhaps someone will be able to provide an
answer.
--
Keith Kratochvil
<realgeek@.gmail.com> wrote in message
news:1160060522.143749.302550@.i42g2000cwa.googlegroups.com...
> Hi. I have a maintenece plan on my development server that rebuilds
> indexes and updates statistics of a certian database that undergoes a
> lot of updates of data daily; it also truncates the log file and backs
> up the database.
> Now, is there any way to script it to deploy it to client computers,
> either as is or within a setup routine with names and paths inserted on
> the fly?
>|||> What do you mean by "client computer?"
> Desktops?
> Servers running SQL Server?
> To me, a client computer means a desktop or notebook. These computers do
> not have SQL Server installed and they should not need a maintenance plan or
> a database deployed to it.
>
By it, I mean a maintenance plan, by client computer, I mean client
server, e.g. the place where the application is deployed.
I have an installation script that restores database to a chosen
location from backup provided with installation (the db initially has a
lot of data so I chose that over scripting it), creates and maps logins
etc; I wanted to add maintenance plan creation script to it but I found
no way to script maintenance plan from Management Studio|||realgeek@.gmail.com wrote:
> By it, I mean a maintenance plan, by client computer, I mean client
> server, e.g. the place where the application is deployed.
> I have an installation script that restores database to a chosen
> location from backup provided with installation (the db initially has a
> lot of data so I chose that over scripting it), creates and maps logins
> etc; I wanted to add maintenance plan creation script to it but I found
> no way to script maintenance plan from Management Studio
>
I think you would be better off NOT using Maintenance Plans in this
manner. Write your own sprocs to do backups, DBCC checks, reindexing,
etc, and deploy those sprocs instead. Much easier to manage and debug
than Maintenance Plans.
Tracy McKibben
MCDBA
http://www.realsqlguy.com|||I agree 100%
--
Keith Kratochvil
"Tracy McKibben" <tracy@.realsqlguy.com> wrote in message
news:452B9819.8060707@.realsqlguy.com...
> realgeek@.gmail.com wrote:
>> By it, I mean a maintenance plan, by client computer, I mean client
>> server, e.g. the place where the application is deployed.
>> I have an installation script that restores database to a chosen
>> location from backup provided with installation (the db initially has a
>> lot of data so I chose that over scripting it), creates and maps logins
>> etc; I wanted to add maintenance plan creation script to it but I found
>> no way to script maintenance plan from Management Studio
> I think you would be better off NOT using Maintenance Plans in this
> manner. Write your own sprocs to do backups, DBCC checks, reindexing,
> etc, and deploy those sprocs instead. Much easier to manage and debug
> than Maintenance Plans.
>
> --
> Tracy McKibben
> MCDBA
> http://www.realsqlguy.com
indexes and updates statistics of a certian database that undergoes a
lot of updates of data daily; it also truncates the log file and backs
up the database.
Now, is there any way to script it to deploy it to client computers,
either as is or within a setup routine with names and paths inserted on
the fly?Oh. This is about SQL Server 2005|||Eh? Deploy it to client computers?
What do you mean by "it?"
The maintenance plan?
The database(s) that you back up?
What do you mean by "client computer?"
Desktops?
Servers running SQL Server?
To me, a client computer means a desktop or notebook. These computers do
not have SQL Server installed and they should not need a maintenance plan or
a database deployed to it.
I am guessing that many people are confused by your question. If you can
better explan what you want to do perhaps someone will be able to provide an
answer.
--
Keith Kratochvil
<realgeek@.gmail.com> wrote in message
news:1160060522.143749.302550@.i42g2000cwa.googlegroups.com...
> Hi. I have a maintenece plan on my development server that rebuilds
> indexes and updates statistics of a certian database that undergoes a
> lot of updates of data daily; it also truncates the log file and backs
> up the database.
> Now, is there any way to script it to deploy it to client computers,
> either as is or within a setup routine with names and paths inserted on
> the fly?
>|||> What do you mean by "client computer?"
> Desktops?
> Servers running SQL Server?
> To me, a client computer means a desktop or notebook. These computers do
> not have SQL Server installed and they should not need a maintenance plan or
> a database deployed to it.
>
By it, I mean a maintenance plan, by client computer, I mean client
server, e.g. the place where the application is deployed.
I have an installation script that restores database to a chosen
location from backup provided with installation (the db initially has a
lot of data so I chose that over scripting it), creates and maps logins
etc; I wanted to add maintenance plan creation script to it but I found
no way to script maintenance plan from Management Studio|||realgeek@.gmail.com wrote:
> By it, I mean a maintenance plan, by client computer, I mean client
> server, e.g. the place where the application is deployed.
> I have an installation script that restores database to a chosen
> location from backup provided with installation (the db initially has a
> lot of data so I chose that over scripting it), creates and maps logins
> etc; I wanted to add maintenance plan creation script to it but I found
> no way to script maintenance plan from Management Studio
>
I think you would be better off NOT using Maintenance Plans in this
manner. Write your own sprocs to do backups, DBCC checks, reindexing,
etc, and deploy those sprocs instead. Much easier to manage and debug
than Maintenance Plans.
Tracy McKibben
MCDBA
http://www.realsqlguy.com|||I agree 100%
--
Keith Kratochvil
"Tracy McKibben" <tracy@.realsqlguy.com> wrote in message
news:452B9819.8060707@.realsqlguy.com...
> realgeek@.gmail.com wrote:
>> By it, I mean a maintenance plan, by client computer, I mean client
>> server, e.g. the place where the application is deployed.
>> I have an installation script that restores database to a chosen
>> location from backup provided with installation (the db initially has a
>> lot of data so I chose that over scripting it), creates and maps logins
>> etc; I wanted to add maintenance plan creation script to it but I found
>> no way to script maintenance plan from Management Studio
> I think you would be better off NOT using Maintenance Plans in this
> manner. Write your own sprocs to do backups, DBCC checks, reindexing,
> etc, and deploy those sprocs instead. Much easier to manage and debug
> than Maintenance Plans.
>
> --
> Tracy McKibben
> MCDBA
> http://www.realsqlguy.com
Subscribe to:
Posts (Atom)