Planning and Scheduling Maintenance

create and follow a regular maintenance plan performing regular, ongoing maintenance is crucial to ensuring optimal system performance at a minimum, a maintenance plan should include the following a schedule for deleting records and tables see deleting inactive tables and records docid\ re1ppmikg jkpplm58rp4 running a tuning advisor tool to determine index tuning actions and then performing those actions see database tuning docid\ slsbup2zewgpf4oubdnsu scanning for duplicate indexes and then removing the duplicates see checking for duplicate indexes docid\ slsbup2zewgpf4oubdnsu configuring database auto growth see setting the value for the database auto growth parameter docid\ slsbup2zewgpf4oubdnsu depending on your system requirements, it is likely that you will perform additional activities as part of a maintenance plan the following is an example maintenance plan month maintenance task january evaluate the current archival plan and modify it as necessary record performance metrics to establish a baseline run the microsoft sql tuning advisor to determine recommended index changes apply recommended index changes scan for and delete duplicate indexes check for license renewal requirements february evaluate the current archival plan and modify it as necessary troubleshoot errors reported in the event log and message queuing march evaluate the current archival plan and modify it as necessary audit log level and location settings review database auto growth and if necessary reset it to an appropriate static value april evaluate the current archival plan and modify it as necessary run the microsoft sql tuning advisor to determine recommended index changes apply recommended index changes scan for and delete duplicate indexes may evaluate the current archival plan and modify it as necessary troubleshoot errors reported in the event log and message queuing june evaluate the current archival plan and modify it as necessary record performance metrics and compare them with the recorded baseline july evaluate the current archival plan and modify it as necessary run the microsoft sql tuning advisor to determine recommended index changes apply recommended index changes scan for and delete duplicate indexes august evaluate the current archival plan and modify it as necessary troubleshoot errors reported in the event log and message queuing september evaluate the current archival plan and modify it as necessary review database auto growth and if necessary reset it to an appropriate static value october evaluate the current archival plan and modify it as necessary run the microsoft sql tuning advisor to determine recommended index changes apply recommended index changes scan for and delete duplicate indexes november evaluate the current archival plan and modify it as necessary troubleshoot errors reported in the event log and message queuing december evaluate the current archival plan and modify it as necessary record performance metrics and compare them with the recorded baseline update infrastructure design plans and other documents update system growth expectations about reviewing, closing, and deleting records it is not uncommon for systems to have hundreds of thousands of active incident records that no longer need to be open and active for example, if an incident has not been modified for several months, it can probably be closed dashboard parts and saved searches may query these inactive records daily closing records that are older than a specified age (for example, three months) prevents them from being queried by dashboard parts and saved searches, which can significantly improve dashboard and search loading performance deleting closed records can also reduce the load on database server infrastructure additionally, deleting workflow history and instance tables prevents the workflow engine from having to query them we highly recommend that you implement a regularly occurring process to identify records that can be closed and deleted you can use service level agreements to automatically trigger a notification when an active record has been open for a specified amount of time to do this, assign a default service level agreement to all services that do not have an active one in the service level agreement, set the escalation to notify the owner when an active incident record has been open and active for a certain number of days deleting closed and inactive records can reduce the load on database sever infrastructure see deleting inactive tables and records docid\ re1ppmikg jkpplm58rp4