tencent cloud

TencentDB for SQL Server

Release Notes and Announcements
Release Notes
Product Announcements
User Guide
Product Introduction
Overview
Product Architecture
Strengths
Use Cases
Regions and AZs
Major Version Lifecycle Explanation
Features and Differences
Instance Types
Instance Specifications
Storage Types
Common Concepts
Network Environment
License Statement
Purchase Guide
Billing Overview
Product Pricing
Purchase Methods
Renewal Instructions
Payment Overdue
Refund
From Pay-as-You-Go to Monthly Subscription
Instance Adjustment Fees Description
Local Backup Space Billing
Cross-Region Backup Billing
Viewing Bill Details
Getting Started
Creating TencentDB for SQL Server Instance
Connecting to TencentDB for SQL Server Instance
Managing TencentDB for SQL Server Instance
Operation Guide
Constraints and Limits
Usage Specifications and Suggestions
Maintaining Instance
Adjusting Instance Configuration
Read-Only Instance
Network and Security
Account Management
Database Management
Data Security
Parameter Configuration
Monitoring and Alarms
Backup and Restoration 
Log Management
Publish-Subscribe
SSIS
Data Migration (New)
Data Migration (Legacy)
Data Synchronization (DTS) 
Practical Tutorial
TencentDB for SQL Server Methods for Regular Maintenance
TencentDB for SQL Server Optimization of Slow SQL
How to Better Use Tempdb
Cross-Account Backup Restoration
Creating VPC for TencentDB for SQL Server
Connecting Kingdee K/3 WISE to TencentDB for SQL Server
Account Permissions and Permission Control
Enabling and Disabling the CDC Feature
Shrinking a Database
API Documentation
History
Introduction
API Category
Making API Requests
Sales and fee related APIs
Instance Management related APIs
Operation and maintenance management related APIs
Network management related APIs
Account management related APIs
Database management related APIs
Security group management related APIs
Data security encryption related APIs
Parameter configuration related APIs
Extended Event related APIs
Log management related APIs
Read only instance management related APIs
Publish and subscribe related APIs
Backup related APIs
Rollback related APIs
Data migration (cold standby migration) related APIs
SQL Server Integration Services (SSIS) related APIs
Data migration (DTS old version) related APIs
Data Types
Error Codes
FAQs
Overview
Model Selection
Pricing and Selection
Connection and Network
Account and Permission
Backup and Rollback
Data Migration
Publish/Subscribe
Read-Only Instance
Version and Architecture Upgrade
Disk Space and Specification Adjustment
Monitoring and Alarms
Log-Related
Parameter Modification
Features
Performance, Space, and Memory-Related FAQs
Service Agreement
Service Level Agreement
Terms of Service
Performance Evaluation
Performance Test Report
Glossary
Contact Us
ドキュメントTencentDB for SQL ServerPractical TutorialTencentDB for SQL Server Methods for Regular Maintenance

TencentDB for SQL Server Methods for Regular Maintenance

PDF
フォーカスモード
フォントサイズ
最終更新日: 2025-12-23 10:45:54
TencentDB for SQL Server, as an enterprise-grade relational database, has its stable operation directly impacting business continuity and data security. Regular maintenance serves as a core approach to ensuring its performance, data integrity, and high availability. This article introduces routine maintenance methods for TencentDB for SQL Server from two aspects: regularly updating statistics and maintaining index fragmentation.

Regularly Update Statistics

SQL Server Query Optimizer uses statistics to create query plans that enhance query performance. For most query scenarios, the Query Optimizer can generate corresponding statistics for optimal query plans. However, in certain scenarios, creating new statistics is necessary to enable the optimizer to produce the best query plan. For example: For large tables with substantial data volume and frequent data changes, when the scope of data modifications does not reach the threshold for automatic updates of statistics, the Query Optimizer may fail to create the highest-performing query plan for the modified data range. This can lead to degraded SQL performance, which may result in business impact.
For this scenario, you can configure the Job in the Agent to regularly update table statistics. Example:




The above screenshot demonstrates the steps to create a Job for updating statistics at 05:00 daily for a specific table in a database. The table to be updated and the scheduled execution time can be evaluated and modified according to business requirements.

Regular Maintenance of Index Fragmentation

For tables with frequent data changes, index fragmentation occurs after prolonged and repeated data modifications. When index fragmentation becomes severe, the efficiency of related SQL queries decreases accordingly. Therefore, regularly checking index fragmentation and performing defragmentation is a crucial Ops task.
For this scenario, you can check indexes in the database with index fragmentation exceeding 50% and generate rebuild scripts.
Note:
Index rebuilding may cause blocking and significant log generation. It is recommended to perform this operation during off-peak business hours and ensure sufficient storage space is available on the instance.
use [dbname]
SET NOCOUNT ON
DECLARE @Objectid INT, @Indexid INT,@schemaname VARCHAR(100),@tablename VARCHAR(300),@ixname VARCHAR(500),@avg_fip float,@command VARCHAR(4000)
DECLARE IX_Cursor CURSOR FOR
SELECT A.object_id,A.index_id,QUOTENAME(SS.name) AS schemaname,QUOTENAME(OBJECT_NAME(B.object_id,B.database_id))as tablename ,QUOTENAME(A.name) AS ixname,B.avg_fragmentation_in_percent AS avg_fip FROM sys.indexes A inner join sys.dm_db_index_physical_stats(DB_ID(),NULL,NULL,NULL,'LIMITED') AS B
ON A.object_id=B.object_id and A.index_id=B.index_id
INNER JOIN sys.objects OS ON A.object_id=OS.object_id
INNER JOIN sys.schemas SS ON OS.schema_id=SS.schema_id
WHERE B.avg_fragmentation_in_percent>10 and B.page_count>20 AND A.index_id>0 AND A.is_disabled<>1
--AND OS.name='book'
ORDER BY tablename,ixname
OPEN IX_Cursor
FETCH NEXT FROM IX_Cursor INTO @Objectid,@Indexid,@schemaname,@tablename,@ixname,@avg_fip
WHILE @@FETCH_STATUS=0
BEGIN
IF @avg_fip>=50.0
BEGIN
SET @command=N'ALTER INDEX '+@ixname+N' ON '+@schemaname+N'.'+ @tablename+N' REBUILD ';
END
--PRINT @command
EXEC(@command)
FETCH NEXT FROM IX_Cursor INTO @Objectid,@Indexid,@schemaname,@tablename,@ixname,@avg_fip
END
CLOSE IX_Cursor
DEALLOCATE IX_Cursor
Configuring the above script as a regularly scheduled Job enables regular maintenance of index fragmentation.
Note:
Methods for Job configuration can refer to the setup approach in Regularly Updating Statistics. Simply modify the script in the steps to the one above.

ヘルプとサポート

この記事はお役に立ちましたか?

フィードバック