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

DocLink Database Best Practices

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)
19 views6 pages

DocLink Database Best Practices

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
You are on page 1/ 6

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 [email protected]. 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 https://doclinkportal.com, 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: [email protected]
Support Portal Webpage: https://doclinkportal.com
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
sys.indexes 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:


https://docs.microsoft.com/en-us/sql/relational-databases/indexes/reorganize-and-rebuild-
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:
http://msdn.microsoft.com/en-us/library/ms189953.aspx

DOCLINK DATABASE BEST PRACTICES 6

You might also like