0% found this document useful (0 votes)
15 views6 pages

DocLink Database Maintenance Guide

The document outlines best practices for maintaining the DocLink database, emphasizing the importance of data and log file management, index fragmentation, statistics, corruption detection, backups, and maintenance plans. It highlights that on-premise customers are responsible for their database maintenance, while cloud customers receive regular maintenance from the operations team. Additionally, it provides contact information for technical support and resources for further assistance.
Copyright
© All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
15 views6 pages

DocLink Database Maintenance Guide

The document outlines best practices for maintaining the DocLink database, emphasizing the importance of data and log file management, index fragmentation, statistics, corruption detection, backups, and maintenance plans. It highlights that on-premise customers are responsible for their database maintenance, while cloud customers receive regular maintenance from the operations team. Additionally, it provides contact information for technical support and resources for further assistance.
Copyright
© All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd

DocLink Database Best Practices

Updated March 4, 2024


Contents
Customer Support .......................................................................................................................................... 3
Database Best Practices................................................................................................................................. 4
Data and Log File Management ............................................................................................................... 4
Index Fragmentation ................................................................................................................................. 5
Statistics ...................................................................................................................................................... 5
Corruption Detection ................................................................................................................................. 5
Backups ....................................................................................................................................................... 6
Maintenance Plan ...................................................................................................................................... 6

DOCLINK DATABASE BEST PRACTICES 2


Customer Support

Technical Support
If we can help in any way, please contact us by email at support@[Link]. Any comments, thoughts,
or enhancement ideas you would like to share regarding the products can also be directed to this email
address.

Please also consider visiting us at our Support Portal webpage [Link] where you can
submit questions and issues to the Support team, as well as access DocLink documentation, Knowledge
Base articles, training videos and more!

Support Contact Information


Support can be reached at:
Email: support@[Link]
Support Portal Webpage: [Link]
Phone: 800.997.9921 x1259
+1.949.727.1248 x 1259

Support Life Cycle


DocLink Support strives to provide installation, configuration, and workaround assistance to customers on
any version of the DocLink product, but our development team will only provide code changes and hotfixes
for the current DocLink version and the previous product version (current version – 1).
Note: A hotfix is a modification to the DocLink software to address specific critical problems.

DOCLINK DATABASE BEST PRACTICES 3


Database Best Practices
Keeping your DocLink database healthy can prevent poor application performance or even downtime and
data loss. The followings are best practices for configuring the DocLink database within SQL.

Please note that for DocLink On Premise customers (On Premise refers to having a server within your
organization that runs the DocLink services and features), database maintenance is beyond the scope of
DocLink Support and the responsibility of each individual customer to manage their server(s) and
database(s) and to employ regular database maintenance. For DocLink Cloud customers, our Operations
team employs regular, weekly database maintenance actions.

For DocLink On Premise customers, DocLink Support can review your database to see if it is need of
maintenance and suggest appropriate actions, but database maintenance and management is ultimately
the responsibility of your IT Staff or IT Provider. If you do not have staff that are able to provide database
maintenance, DocLink Professional Services can assist you with setting up and performing database
maintenance, as part of a project. Contact Support if you have any questions or would like to arrange for
Professional Services to assist you with database maintenance.

It is suggested that database maintenance and full backups take place during “off hours”. It is
best to perform or schedule these actions when users are either not in the system, or during low
use periods. Please also keep in mind other resource intensive actions, such as server backups,
anti-virus scans, Windows Updates, etc., that are scheduled or being manually performed and
try not overlap those activities with your DocLink database maintenance and backup activities.

Data and Log File Management


SQL Server has two main files per database a Data file and a Log file. The Data file is where data is stored
and the Log file sequentially logs all database transactions.
• Data and log files should reside on their own physical disks, isolated from application data.
• Configure auto-growth by file size vs. percentage. The size of file growth should be set high
enough that the database is not constantly growing throughout the day. The appropriate growth
size should be determined by monitoring data and log used space within the DocLink database
files. By monitoring the data and log usage you can determine the growth size that will prevent
database files from regularly growing. The data file will continue to grow over time. The log file
should not grow over time. The size of the log file should be maintained through backup, which
will release free space for new transaction to be logged. A DocLink system with high transactions
will average about 10-15 GB per year. A system with which is constantly running ERM Capture,
Barcode, Import, etc. can be consider as a high transaction system. In this scenario, auto-growth
should be between 20 - 30 GB. DocLink system with lower transaction can be as little as 1 - 2 GB.
In this scenario growing between 2 - 4 GB would be sufficient.
• Do not enable auto-shrink. (ALTER DATABASE MyDatabase SET AUTO_SHRINK OFF;)

DOCLINK DATABASE BEST PRACTICES 4


Index Fragmentation
The process of writing, modification, and deletion of data inevitability will cause index fragmentation. A
proper maintenance plan should include steps to remove index fragmentation (see Maintenance Plan below).
• Schedule a regular rebuilding of indexes. This can be performed nightly or weekly using a
maintenance plan.

SQL script to detect the level of index fragmentation in the database

USE doclink2 SELECT object_name(indexinfo.object_id) , indexinfo.index_id , indexinfo.index_type_desc ,


indexinfo.index_level , indexinfo.avg_fragmentation_in_percent ,
indexinfo.avg_page_space_used_in_percent , indexinfo.page_count FROM
sys.dm_db_index_physical_stats(db_id(N'doclink2'), null, null, null , 'sampled') AS indexinfo INNER JOIN
[Link] i ON i.object_id = indexinfo.object_id AND i.index_id = indexinfo.index_id ORDER BY
avg_fragmentation_in_percent DESC

Any tables that are more than 50% fragmented should be reindexed to optimize them.

Information on Reorganizing and Rebuilding Indexes:


[Link]
indexes?view=sql-server-2017

Statistics
Statistic is the distribution of data values for columns within a table or index. Query Processor uses
statistics to determine how a query should be executed. A poor query plan can result when statistics are
outdated. A proper maintenance plan should include steps to update statistics (see Maintenance Plan
below).
• Turn on AUTO_CREATE_STATISTICS and AUTO_UPDATE_STATISTICS

Corruption Detection
Data corruption can occur for many reasons. This can be anywhere from file-system drivers, device-drivers,
RAID controllers, cables, network, and/or disk drives. Another common cause of data corruption is a power
failure while the disk drive is performing a write operation. To identify possible data corruption, use
checksum, torn page, and schedule DBCC CHECKDB after a Full Backup.
• ALTER DATABASE MyDatabase SET PAGE_VERIFY CHECKSUM;
• ALTER DATABASE MyDatabase SET TORN_PAGE_DETECTION ON;
• DBCC CHECKDB

DOCLINK DATABASE BEST PRACTICES 5


Backups
The duration of backups should be a business decision based on how much data you are willing to lose.
Generally, anything longer than a daily full backup will be complimented with differential backup (even on
daily full backup differential backup is a common practice).

Transaction Log Backups should be used for the highest level of recoverability. This will allow a recovery
to any point in time. A transaction log backup can only be performed when the database recovery model
is set to FULL or BULK_LOGGED. An example of this could be full database backup every day, a differential
database backup every four hours, and a log backup every half hour.

A common configuration mistake is to have the database recovery model set to FULL and not have the
proper backup plan configured. This misconfiguration can cause the log file to grow to exceptionally large
sizes or grow until the drive is full. When the database recovery model is set to FULL the transaction log
backups will free up space in the log file for new transactions to be logged.

Finally, backups need to be stored in a separate location. Ideally, the storage of backups should be stored
in the following priority based on a business disaster recovery plan:

1. An off-site location.
2. On a different server
3. On a separate physical drive.

Maintenance Plan
Maintenance plans create a workflow of the tasks required to make sure that your database is optimized,
is regularly backed up, and is free of inconsistencies. The Maintenance Plan Wizard also creates core
maintenance plans. Creating a plan manually will give you much more flexibility. See link below for creation
of a Maintenance Plan:
[Link]

DOCLINK DATABASE BEST PRACTICES 6

Common questions

Powered by AI

For managing data and log files in a SQL Server environment, it's essential to ensure these files reside on their own physical disks isolated from application data, configure auto-growth by file size instead of percentage, and set an appropriate growth size by monitoring data and log usage. It is important to prevent the database from growing constantly throughout the day. The log file size should be maintained through regular backups, allowing space for new transactions. Auto-shrink should be disabled to avoid potential fragmentation and performance issues .

For DocLink On Premise customers, maintaining the server and database is the customer's responsibility. They must implement regular maintenance like backups and index management. In contrast, DocLink Cloud customers benefit from regular, weekly database maintenance performed by the Operations team. Both arrangements necessitate customer actions to ensure database health, with On Premise requiring more direct oversight .

Index fragmentation occurs due to the writing, modification, and deletion of data. To address this, a maintenance plan should include regular rebuilding of indexes. This can be done nightly or weekly to reduce fragmentation. A SQL script can detect the fragmentation level, and any tables more than 50% fragmented should be reindexed. Effective index management ensures optimization and improved database performance .

The recommended backup strategy includes a daily full backup complemented by differential backups and transaction log backups for finer recoverability. Differential backups are usually taken periodically throughout the day, while transaction log backups are essential for point-in-time recovery and are necessary when the database recovery model is set to FULL or BULK_LOGGED. The transaction log backups prevent log files from growing excessively by freeing up space for new transactions to be logged. These strategies ensure minimal data loss and optimal recovery options .

Regularly updating statistics in an SQL database is crucial because outdated statistics can lead to poor query plans, negatively impacting database performance. The Query Processor uses statistics to determine the optimal execution strategy for queries. To automate this process and ensure statistics are current, the settings AUTO_CREATE_STATISTICS and AUTO_UPDATE_STATISTICS should be turned on, facilitating automatic updates and creation of statistics as needed .

Database maintenance plans play a critical role in optimizing databases, ensuring regular backups, and maintaining consistency. While Maintenance Plan Wizard can automate core tasks, creating plans manually offers greater flexibility to tailor tasks precisely to the database's needs. A customized plan can incorporate specific actions like index rebuilding or statistics updates schedules to better maintain database health .

Data corruption in database systems can be caused by issues with file-system drivers, device-drivers, RAID controllers, cables, networks, disk drives, or power failures during disk write operations. Corruption detection mechanisms include setting PAGE_VERIFY to CHECKSUM, enabling TORN_PAGE_DETECTION, and scheduling regular DBCC CHECKDB executions after full backups. These practices help identify and prevent corruption, thereby maintaining data integrity .

Storing database backups in multiple locations adds layers of security within a business's disaster recovery plan. Prioritize off-site backup storage to protect against data loss during local disasters, followed by storage on a different server or separate physical drive. This strategy minimizes the risk of data unavailability and ensures business continuity by providing reliable options for data recovery .

Database maintenance and backup activities should be scheduled during off-hours when users are not actively using the system or during periods of low activity. It's crucial to avoid overlapping these tasks with other resource-intensive actions like server backups, anti-virus scans, and Windows Updates. This scheduling ensures that performance is not adversely impacted and that maintenance can be performed without inconveniencing users .

When setting up the auto-growth feature, configure it by file size rather than percentage to prevent the database from growing too frequently. It's essential to monitor data usage to determine the appropriate growth size to accommodate expected transaction volumes, especially in high transaction systems. Monitoring helps balance the need to avoid excessive growth and manage file sizes efficiently, preventing performance issues .

You might also like