Categories
Database Backup

** Discover expert strategies for preventing and resolving MSSQL transaction log full errors (Error 9002). Learn rapid recovery techniques, VLF management, and architectural best practices for DBAs.

ਡੇਟਾਬੇਸ ਐਡਮਿਨਿਸਟ੍ਰੇਟਰਾਂ (DBAs) ਅਤੇ DevOps ਇੰਜੀਨੀਅਰਾਂ ਲਈ ਜੋ Microsoft SQL Server ਦਾ ਪ੍ਰਬੰਧਨ ਕਰਦੇ ਹਨ, ਬਹੁਤ ਘੱਟ ਅਲਰਟ ਇੰਨੀ ਤੁਰੰਤ ਚਿੰਤਾ ਪੈਦਾ ਕਰਦੇ ਹਨ ਜਿੰਨਾ ਕਿ Error 9002: The transaction log for database ‘X’ is full। ਜਦੋਂ ਟ੍ਰਾਂਜੈਕਸ਼ਨ ਲੌਗ ਭਰ ਜਾਂਦਾ ਹੈ ਅਤੇ ਵੱਧ ਨਹੀਂ ਸਕਦਾ, ਤਾਂ ਡੇਟਾਬੇਸ ਅਸਲ ਵਿੱਚ ਸਿਰਫ਼-ਪੜ੍ਹਨਯੋਗ (read-only) ਬਣ ਜਾਂਦਾ ਹੈ। ਸਾਰੇ INSERT, UPDATE, ਅਤੇ DELETE ਓਪਰੇਸ਼ਨ ਰੁਕ ਜਾਂਦੇ ਹਨ, ਐਪਲੀਕੇਸ਼ਨ ਟ੍ਰਾਂਜੈਕਸ਼ਨਾਂ ਅਸਫਲ ਹੋ ਜਾਂਦੀਆਂ ਹਨ, ਅਤੇ ਪ੍ਰੋਡਕਸ਼ਨ ਪੂਰੀ ਤਰ੍ਹਾਂ ਠੱਪ ਹੋ ਜਾਂਦੀ ਹੈ।

SQL Server ਟ੍ਰਾਂਜੈਕਸ਼ਨ ਲੌਗ ਦੇ ਅੰਤਰੀਵ ਆਰਕੀਟੈਕਚਰ ਨੂੰ ਸਮਝਣਾ, ਮੂਲ ਕਾਰਨ ਦਾ ਸਹੀ ਨਿਦਾਨ ਕਰਨਾ, ਅਤੇ ਤੇਜ਼ੀ ਨਾਲ ਰਿਕਵਰੀ ਪ੍ਰਕਿਰਿਆਵਾਂ ਨੂੰ ਲਾਗੂ ਕਰਨਾ ਉੱਚ ਉਪਲਬਧਤਾ (high availability) ਨੂੰ ਬਣਾਈ ਰੱਖਣ ਲਈ ਮਹੱਤਵਪੂਰਨ ਹੁਨਰ ਹਨ। ਇਹ ਵਿਆਪਕ ਗਾਈਡ ਟ੍ਰਾਂਜੈਕਸ਼ਨ ਲੌਗ ਦੇ ਮਕੈਨਿਕਸ, ਐਮਰਜੈਂਸੀ ਵਿੱਚ ਭਰੇ ਹੋਏ ਲੌਗ ਨੂੰ ਕਿਵੇਂ ਹੱਲ ਕਰਨਾ ਹੈ, ਅਤੇ ਇਸਨੂੰ ਦੁਬਾਰਾ ਵਾਪਰਨ ਤੋਂ ਰੋਕਣ ਲਈ ਆਰਕੀਟੈਕਚਰਲ ਵਧੀਆ ਅਭਿਆਸਾਂ ਦੀ ਪੜਚੋਲ ਕਰਦੀ ਹੈ।

SQL Server ਟ੍ਰਾਂਜੈਕਸ਼ਨ ਲੌਗ ਆਰਕੀਟੈਕਚਰ ਨੂੰ ਸਮਝਣਾ

ਭਰੇ ਹੋਏ ਟ੍ਰਾਂਜੈਕਸ਼ਨ ਲੌਗ ਨੂੰ ਪ੍ਰਭਾਵਸ਼ਾਲੀ ਢੰਗ ਨਾਲ ਹੱਲ ਕਰਨ ਲਈ, ਤੁਹਾਨੂੰ ਪਹਿਲਾਂ ਇਹ ਸਮਝਣਾ ਚਾਹੀਦਾ ਹੈ ਕਿ SQL Server ਡੇਟਾ ਨੂੰ ਕਿਵੇਂ ਲਿਖਦਾ ਅਤੇ ਪ੍ਰਬੰਧਿਤ ਕਰਦਾ ਹੈ।

Write-Ahead Logging (WAL)

SQL Server ਇੱਕ Write-Ahead Logging (WAL) ਪ੍ਰੋਟੋਕੋਲ ਦੀ ਵਰਤੋਂ ਕਰਦਾ ਹੈ। ਜਦੋਂ ਵੀ ਕੋਈ ਡੇਟਾ ਸੋਧ ਹੁੰਦੀ ਹੈ, ਤਾਂ ਤਬਦੀਲੀ ਨੂੰ ਪਹਿਲਾਂ ਮੈਮੋਰੀ ਵਿੱਚ ਟ੍ਰਾਂਜੈਕਸ਼ਨ ਲੌਗ ਵਿੱਚ ਲਿਖਿਆ ਜਾਂਦਾ ਹੈ, ਫਿਰ ਡੇਟਾਬੇਸ ਫਾਈਲਾਂ (MDF/NDF) ਵਿੱਚ ਅਸਲ ਡੇਟਾ ਪੰਨਿਆਂ ਨੂੰ ਅਪਡੇਟ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਡਿਸਕ ਉੱਤੇ ਭੌਤਿਕ ਲੌਗ ਫਾਈਲ ਵਿੱਚ ਫਲੱਸ਼ ਕੀਤਾ ਜਾਂਦਾ ਹੈ। ਇਹ ACID (Atomicity, Consistency, Isolation, Durability) ਪਾਲਣਾ ਦੀ ਗਰੰਟੀ ਦਿੰਦਾ ਹੈ, ਇਹ ਯਕੀਨੀ ਬਣਾਉਂਦਾ ਹੈ ਕਿ ਕਰੈਸ਼ ਹੋਣ ਦੀ ਸਥਿਤੀ ਵਿੱਚ, SQL Server ਟ੍ਰਾਂਜੈਕਸ਼ਨਾਂ ਨੂੰ ਦੁਬਾਰਾ ਚਲਾ (roll forward) ਜਾਂ ਵਾਪਸ (roll back) ਕਰ ਸਕਦਾ ਹੈ।

Virtual Log Files (VLFs) ਅਤੇ ਸਰਕੂਲਰ ਲੌਗਿੰਗ

ਅੰਦਰੂਨੀ ਤੌਰ ‘ਤੇ, ਭੌਤਿਕ ਟ੍ਰਾਂਜੈਕਸ਼ਨ ਲੌਗ ਫਾਈਲ (LDF) ਨੂੰ ਛੋਟੇ, ਲਾਜ਼ੀਕਲ ਹਿੱਸਿਆਂ ਵਿੱਚ ਵੰਡਿਆ ਜਾਂਦਾ ਹੈ ਜਿਨ੍ਹਾਂ ਨੂੰ Virtual Log Files (VLFs) ਕਿਹਾ ਜਾਂਦਾ ਹੈ। ਟ੍ਰਾਂਜੈਕਸ਼ਨ ਲੌਗ ਸਰਕੂਲਰ ਤੌਰ ‘ਤੇ ਕੰਮ ਕਰਦਾ ਹੈ। ਜਿਵੇਂ ਹੀ ਲੌਗ ਰਿਕਾਰਡ ਲਿਖੇ ਜਾਂਦੇ ਹਨ, ਉਹ ਇੱਕ VLF ਨੂੰ ਭਰਦੇ ਹਨ ਅਤੇ ਅਗਲੇ ਵੱਲ ਵਧਦੇ ਹਨ।

ਜਦੋਂ ਲੌਗ ਭੌਤਿਕ ਫਾਈਲ ਦੇ ਅੰਤ ਤੱਕ ਪਹੁੰਚਦਾ ਹੈ, ਤਾਂ ਇਹ ਸ਼ੁਰੂਆਤ ਵਿੱਚ ਵਾਪਸ ਜਾਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਦਾ ਹੈ। ਹਾਲਾਂਕਿ, ਇਹ ਸਿਰਫ਼ ਇੱਕ VLF ਨੂੰ ਓਵਰਰਾਈਟ ਕਰ ਸਕਦਾ ਹੈ ਜੇਕਰ ਉਹ VLF ਅਕਿਰਿਆਸ਼ੀਲ (inactive) ਵਜੋਂ ਚਿੰਨ੍ਹਿਤ ਹੈ। ਜੇਕਰ ਸਾਰੇ VLFs ਕਿਰਿਆਸ਼ੀਲ ਹਨ (ਮਤਲਬ ਉਹਨਾਂ ਵਿੱਚ ਅਜਿਹੇ ਲੌਗ ਰਿਕਾਰਡ ਹਨ ਜਿਨ੍ਹਾਂ ਦੀ SQL Server ਨੂੰ ਅਜੇ ਵੀ ਲੋੜ ਹੈ), ਤਾਂ ਲੌਗ ਵਾਪਸ ਨਹੀਂ ਮੁੜ ਸਕਦਾ। ਜੇਕਰ ਆਟੋ-ਗ੍ਰੋਥ ਸਮਰੱਥ ਹੈ ਅਤੇ ਡਿਸਕ ਸਪੇਸ ਉਪਲਬਧ ਹੈ, ਤਾਂ ਭੌਤਿਕ ਫਾਈਲ ਵੱਡੀ ਹੋ ਜਾਂਦੀ ਹੈ। ਜੇਕਰ ਡਿਸਕ ਭਰੀ ਹੋਈ ਹੈ ਜਾਂ ਆਟੋ-ਗ੍ਰੋਥ ਪ੍ਰਤਿਬੰਧਿਤ ਹੈ, ਤਾਂ ਤੁਹਾਨੂੰ Error 9002 ਦਾ ਸਾਹਮਣਾ ਕਰਨਾ ਪਵੇਗਾ।

Log Truncation ਬਨਾਮ Log Shrinking

ਇੱਕ ਆਮ ਗਲਤਫਹਿਮੀ ਇਹ ਹੈ ਕਿ ਲੌਗ ਨੂੰ ਟ੍ਰੰਕੇਟ (truncate) ਕਰਨ ਨਾਲ ਭੌਤਿਕ ਫਾਈਲ ਦਾ ਆਕਾਰ ਘੱਟ ਜਾਂਦਾ ਹੈ।
* Log Truncation: ਕਿਰਿਆਸ਼ੀਲ VLFs ਨੂੰ ਅਕਿਰਿਆਸ਼ੀਲ ਵਜੋਂ ਚਿੰਨ੍ਹਿਤ ਕਰਨ ਦੀ ਪ੍ਰਕਿਰਿਆ, ਜਿਸ ਨਾਲ ਜਗ੍ਹਾ ਦੁਬਾਰਾ ਵਰਤੋਂ ਲਈ ਉਪਲਬਧ ਹੋ ਜਾਂਦੀ ਹੈ। ਇਹ ਡਿਸਕ ਉੱਤੇ LDF ਫਾਈਲ ਦੇ ਆਕਾਰ ਨੂੰ ਨਹੀਂ ਘਟਾਉਂਦਾ ਹੈ।
* Log Shrinking: LDF ਫਾਈਲ ਦੇ ਆਕਾਰ ਨੂੰ ਭੌਤਿਕ ਤੌਰ ‘ਤੇ ਘਟਾਉਣ ਅਤੇ ਓਪਰੇਟਿੰਗ ਸਿਸਟਮ ਨੂੰ ਜਗ੍ਹਾ ਵਾਪਸ ਕਰਨ ਦੀ ਪ੍ਰਕਿਰਿਆ।

Full Recovery ਮਾਡਲ ਵਿੱਚ, ਲੌਗ ਟ੍ਰੰਕੇਸ਼ਨ ਸਿਰਫ਼ ਉਦੋਂ ਹੁੰਦਾ ਹੈ ਜਦੋਂ ਇੱਕ ਟ੍ਰਾਂਜੈਕਸ਼ਨ ਲੌਗ ਬੈਕਅੱਪ ਸਫਲਤਾਪੂਰਵਕ ਪੂਰਾ ਹੋ ਜਾਂਦਾ ਹੈ (ਇਹ ਮੰਨ ਕੇ ਕਿ ਕੋਈ ਹੋਰ ਪ੍ਰਕਿਰਿਆ ਲੌਗ ਨੂੰ ਕਿਰਿਆਸ਼ੀਲ ਨਹੀਂ ਰੱਖ ਰਹੀ ਹੈ)।

“Transaction Log Full” ਗਲਤੀ (Error 9002) ਦਾ ਨਿਦਾਨ

ਜਦੋਂ ਲੌਗ ਭਰ ਜਾਂਦਾ ਹੈ, ਤਾਂ ਤੁਹਾਡਾ ਪਹਿਲਾ ਕਦਮ ਅੰਨ੍ਹੇਵਾਹ ਡਿਸਕ ਸਪੇਸ ਜੋੜਨਾ ਜਾਂ ਫਾਈਲਾਂ ਨੂੰ ਸੁੰਗੜਨਾ ਨਹੀਂ ਹੋਣਾ ਚਾਹੀਦਾ। ਤੁਹਾਨੂੰ ਇਹ ਪਛਾਣਨਾ ਚਾਹੀਦਾ ਹੈ ਕਿ ਲੌਗ ਟ੍ਰੰਕੇਟ ਕਿਉਂ ਨਹੀਂ ਹੋ ਸਕਦਾ। SQL Server sys.databases ਕੈਟਾਲਾਗ ਵਿਊ ਰਾਹੀਂ ਇਹ ਦੱਸਣ ਲਈ ਇੱਕ ਬਿਲਟ-ਇਨ ਵਿਧੀ ਪ੍ਰਦਾਨ ਕਰਦਾ ਹੈ ਕਿ ਲੌਗ ਦੀ ਮੁੜ ਵਰਤੋਂ ਨੂੰ ਕੀ ਰੋਕ ਰਿਹਾ ਹੈ।

ਬੋਟਲਨੇਕ (bottleneck) ਦੀ ਪਛਾਣ ਕਰਨ ਲਈ ਹੇਠ ਲਿਖੀ T-SQL ਕਮਾਂਡ ਚਲਾਓ:

SELECT 
    name AS DatabaseName, 
    recovery_model_desc AS RecoveryModel, 
    log_reuse_wait_desc AS LogReuseWaitReason
FROM sys.databases
WHERE name = 'YourDatabaseName';

ਤੁਸੀਂ ਹੇਠ ਲਿਖਿਆਂ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਆਪਣੇ ਟ੍ਰਾਂਜੈਕਸ਼ਨ ਲੌਗਸ ਦੀ ਮੌਜੂਦਾ ਸਪੇਸ ਵਰਤੋਂ ਦੀ ਜਾਂਚ ਵੀ ਕਰ ਸਕਦੇ ਹੋ:

DBCC SQLPERF(LOGSPACE);

ਆਮ log_reuse_wait_desc ਸਥਿਤੀਆਂ

  1. LOG_BACKUP: ਡੇਟਾਬੇਸ Full ਜਾਂ Bulk-Logged ਰਿਕਵਰੀ ਮਾਡਲ ਵਿੱਚ ਹੈ, ਅਤੇ ਹਾਲ ਹੀ ਵਿੱਚ ਟ੍ਰਾਂਜੈਕਸ਼ਨ ਲੌਗ ਬੈਕਅੱਪ ਨਹੀਂ ਲਿਆ ਗਿਆ ਹੈ। ਇਹ ਸਭ ਤੋਂ ਆਮ ਕਾਰਨ ਹੈ।
  2. ACTIVE_TRANSACTION: ਇੱਕ ਲੰਬੇ ਸਮੇਂ ਤੋਂ ਚੱਲ ਰਹੀ ਟ੍ਰਾਂਜੈਕਸ਼ਨ (ਉਦਾਹਰਨ ਲਈ, ਇੱਕ ਵਿਸ਼ਾਲ ਇੰਡੈਕਸ ਰੀਬਿਲਡ ਜਾਂ ਇੱਕ ਭੁੱਲੀ ਹੋਈ ਅਣ-ਕਮਿਟ ਕੀਤੀ ਟ੍ਰਾਂਜੈਕਸ਼ਨ) ਲੌਗ ਨੂੰ ਕਿਰਿਆਸ਼ੀਲ ਰੱਖ ਰਹੀ ਹੈ।
  3. REPLICATION / CDC: ਟ੍ਰਾਂਜੈਕਸ਼ਨਲ ਰਿਪਲੀਕੇਸ਼ਨ ਜਾਂ ਚੇਂਜ ਡੇਟਾ ਕੈਪਚਰ (CDC) ਸਮਰੱਥ ਹੈ, ਅਤੇ ਲੌਗ ਰੀਡਰ ਏਜੰਟ ਨੇ ਅਜੇ ਤੱਕ ਟ੍ਰਾਂਜੈਕਸ਼ਨਾਂ ਨੂੰ ਪ੍ਰੋਸੈਸ ਨਹੀਂ ਕੀਤਾ ਹੈ।
  4. AVAILABILITY_REPLICA: AlwaysOn Availability Group ਵਿੱਚ, ਇੱਕ ਸੈਕੰਡਰੀ ਰਿਪਲੀਕਾ ਡਿਸਕਨੈਕਟ ਹੈ ਜਾਂ ਬਹੁਤ ਹੌਲੀ ਸਿੰਕ੍ਰੋਨਾਈਜ਼ ਹੋ ਰਿਹਾ ਹੈ, ਜੋ ਪ੍ਰਾਇਮਰੀ ਰਿਪਲੀਕਾ ਨੂੰ ਲੌਗ ਰਿਕਾਰਡਾਂ ਨੂੰ ਉਦੋਂ ਤੱਕ ਬਰਕਰਾਰ ਰੱਖਣ ਲਈ ਮਜਬੂਰ ਕਰਦਾ ਹੈ ਜਦੋਂ ਤੱਕ ਉਹ ਸੈਕੰਡਰੀ ਉੱਤੇ ਹਾਰਡਨ ਨਹੀਂ ਹੋ ਜਾਂਦੇ।

ਤੇਜ਼ ਰਿਕਵਰੀ ਰਣਨੀਤੀਆਂ: ਪ੍ਰੋਡਕਸ਼ਨ ਵਿੱਚ ਸਮੱਸਿਆ ਨੂੰ ਹੱਲ ਕਰਨਾ

ਵਾਪਸ ਕੀਤੇ ਗਏ log_reuse_wait_desc ਦੇ ਆਧਾਰ ‘ਤੇ, ਤੁਹਾਡੀ ਐਮਰਜੈਂਸੀ ਪ੍ਰਤੀਕਿਰਿਆ ਵੱਖਰੀ ਹੋਵੇਗੀ। ਸਭ ਤੋਂ ਆਮ ਦ੍ਰਿਸ਼ਾਂ ਲਈ ਤੇਜ਼ ਰਿਕਵਰੀ ਰਣਨੀਤੀਆਂ ਇੱਥੇ ਹਨ।

ਦ੍ਰਿਸ਼ 1: ਗੁੰਮ ਜਾਂ ਅਸਫਲ ਲੌਗ ਬੈਕਅੱਪ (LOG_BACKUP)

ਜੇਕਰ ਵੇਟ ਟਾਈਪ LOG_BACKUP ਹੈ, ਤਾਂ ਹੱਲ ਸਿੱਧਾ ਹੈ: ਤੁਹਾਨੂੰ ਟ੍ਰਾਂਜੈਕਸ਼ਨ ਲੌਗ ਦਾ ਬੈਕਅੱਪ ਲੈਣਾ ਚਾਹੀਦਾ ਹੈ। 

BACKUP LOG [YourDatabaseName] 
TO DISK = 'N:BackupsYourDatabaseName_EmergencyLog.trn' 
WITH COMPRESSION, STATS = 10;

ਇੱਕ ਵਾਰ ਬੈਕਅੱਪ ਪੂਰਾ ਹੋ ਜਾਣ ‘ਤੇ, ਅਕਿਰਿਆਸ਼ੀਲ VLFs ਟ੍ਰੰਕੇਟ ਹੋ ਜਾਣਗੇ, ਅਤੇ SQL Server ਆਮ ਕਾਰਵਾਈਆਂ ਨੂੰ ਮੁੜ ਸ਼ੁਰੂ ਕਰ ਦੇਵੇਗਾ। ਜੇਕਰ ਤੁਹਾਡੀ ਬੈਕਅੱਪ ਡਰਾਈਵ ਭਰੀ ਹੋਈ ਹੈ, ਤਾਂ ਤੁਹਾਨੂੰ ਇੱਕ ਅਸਥਾਈ ਨੈੱਟਵਰਕ ਸ਼ੇਅਰ ਜਾਂ ਨਲ ਡਿਵਾਈਸ (null device) ਵਿੱਚ ਬੈਕਅੱਪ ਲੈਣ ਦੀ ਲੋੜ ਹੋ ਸਕਦੀ ਹੈ (ਬਹੁਤ ਜ਼ਿਆਦਾ ਨਿਰਾਸ਼ਾਜਨਕ ਜਦੋਂ ਤੱਕ ਡੇਟਾਬੇਸ ਆਸਾਨੀ ਨਾਲ ਦੁਬਾਰਾ ਪੈਦਾ ਕਰਨ ਯੋਗ ਨਾ ਹੋਵੇ, ਕਿਉਂਕਿ ਇਹ ਲੌਗ ਚੇਨ ਨੂੰ ਤੋੜਦਾ ਹੈ):

-- ਚੇਤਾਵਨੀ: ਇਹ ਲੌਗ ਚੇਨ ਨੂੰ ਤੋੜਦਾ ਹੈ ਅਤੇ ਪੁਆਇੰਟ-ਇਨ-ਟਾਈਮ ਰਿਕਵਰੀ ਨਾਲ ਸਮਝੌਤਾ ਕਰਦਾ ਹੈ।
-- ਸਿਰਫ਼ ਤਾਂ ਹੀ ਵਰਤੋ ਜੇਕਰ ਬਿਲਕੁਲ ਜ਼ਰੂਰੀ ਹੋਵੇ ਅਤੇ ਤੁਰੰਤ ਬਾਅਦ ਇੱਕ FULL ਬੈਕਅੱਪ ਲਓ।
BACKUP LOG [YourDatabaseName] TO DISK = 'NUL';

ਦ੍ਰਿਸ਼ 2: ਲੰਬੇ ਸਮੇਂ ਤੋਂ ਚੱਲ ਰਹੀਆਂ ਕਿਰਿਆਸ਼ੀਲ ਟ੍ਰਾਂਜੈਕਸ਼ਨਾਂ (ACTIVE_TRANSACTION)

ਜੇਕਰ ਇੱਕ ਸਿੰਗਲ ਟ੍ਰਾਂਜੈਕਸ਼ਨ ਘੰਟਿਆਂ ਤੋਂ ਚੱਲ ਰਹੀ ਹੈ, ਤਾਂ ਇਹ ਪੂਰੀ ਮਿਆਦ ਲਈ ਲੌਗ ਟ੍ਰੰਕੇਸ਼ਨ ਨੂੰ ਰੋਕਦੀ ਹੈ। ਪਹਿਲਾਂ, ਦੋਸ਼ੀ ਟ੍ਰਾਂਜੈਕਸ਼ਨ ਦੀ ਪਛਾਣ ਕਰੋ:

DBCC OPENTRAN('YourDatabaseName');

ਇਹ ਕਮਾਂਡ ਸਭ ਤੋਂ ਪੁਰਾਣੀ ਕਿਰਿਆਸ਼ੀਲ ਟ੍ਰਾਂਜੈਕਸ਼ਨ ਅਤੇ ਇਸਦੀ ਸਰਵਰ ਪ੍ਰੋਸੈਸ ਆਈਡੀ (SPID) ਵਾਪਸ ਕਰਦੀ ਹੈ। ਤੁਸੀਂ ਡਾਇਨਾਮਿਕ ਮੈਨੇਜਮੈਂਟ ਵਿਊਜ਼ (DMVs) ਨੂੰ ਕੁਐਰੀ ਕਰਕੇ ਇਸ ਬਾਰੇ ਹੋਰ ਵੇਰਵੇ ਇਕੱਠੇ ਕਰ ਸਕਦੇ ਹੋ ਕਿ SPID ਕੀ ਕਰ ਰਿਹਾ ਹੈ:

SELECT 
    s.session_id,
    s.login_name,
    s.host_name,
    r.start_time,
    r.status,
    r.command,
    t.text AS QueryText
FROM sys.dm_exec_sessions s
JOIN sys.dm_exec_requests r ON s.session_id = r.session_id
CROSS APPLY sys.dm_exec_sql_text(r.sql_handle) t
WHERE s.session_id = <SPID_FROM_DBCC_OPENTRAN>;

ਜੇਕਰ ਟ੍ਰਾਂਜੈਕਸ਼ਨ ਇੱਕ ਰੌਗ ਕੁਐਰੀ ਜਾਂ ਰੁਕੀ ਹੋਈ ਪ੍ਰਕਿਰਿਆ ਹੈ, ਤਾਂ ਤੁਹਾਨੂੰ ਲੌਗ ਨੂੰ ਖਾਲੀ ਕਰਨ ਲਈ ਇਸਨੂੰ ਖਤਮ ਕਰਨ ਦੀ ਲੋੜ ਹੋ ਸਕਦੀ ਹੈ। 

KILL <SPID>;

ਨੋਟ: ਇੱਕ ਵਿਸ਼ਾਲ ਟ੍ਰਾਂਜੈਕਸ਼ਨ ਨੂੰ ਮਾਰਨਾ ਇੱਕ ਰੋਲਬੈਕ ਨੂੰ ਚਾਲੂ ਕਰੇਗਾ, ਜਿਸ ਵਿੱਚ ਕਾਫ਼ੀ ਸਮਾਂ ਲੱਗ ਸਕਦਾ ਹੈ ਅਤੇ ਇਹ ਅਸਥਾਈ ਤੌਰ ‘ਤੇ ਵਾਧੂ ਲੌਗ ਗਤੀਵਿਧੀ ਪੈਦਾ ਕਰੇਗਾ। ਰੋਲਬੈਕ ਦੌਰਾਨ SQL Server ਸੇਵਾ ਨੂੰ ਰੀਸਟਾਰਟ ਨਾ ਕਰੋ, ਨਹੀਂ ਤਾਂ ਡੇਟਾਬੇਸ ਰੀਸਟਾਰਟ ਹੋਣ ‘ਤੇ ਰਿਕਵਰੀ ਮੋਡ ਵਿੱਚ ਦਾਖਲ ਹੋ ਜਾਵੇਗਾ।

ਦ੍ਰਿਸ਼ 3: ਐਮਰਜੈਂਸੀ ਸਪੇਸ ਐਲੋਕੇਸ਼ਨ (ਡਿਸਕ 100% ਭਰੀ ਹੋਈ ਹੈ)

ਜੇਕਰ LDF ਫਾਈਲ ਨੇ ਪੂਰੀ ਡਰਾਈਵ ਦੀ ਵਰਤੋਂ ਕਰ ਲਈ ਹੈ, ਤਾਂ ਤੁਸੀਂ ਬੈਕਅੱਪ ਵੀ ਨਹੀਂ ਚਲਾ ਸਕਦੇ ਕਿਉਂਕਿ SQL Server ਨੂੰ ਬੈਕਅੱਪ ਇਵੈਂਟ ਨੂੰ ਰਿਕਾਰਡ ਕਰਨ ਲਈ ਲੌਗ ਸਪੇਸ ਦੀ ਇੱਕ ਛੋਟੀ ਜਿਹੀ ਮਾਤਰਾ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ। ਇਸ ਸਥਿਤੀ ਵਿੱਚ, ਤੁਹਾਨੂੰ ਉਪਲਬਧ ਸਪੇਸ ਵਾਲੀ ਕਿਸੇ ਵੱਖਰੀ ਡਰਾਈਵ ਉੱਤੇ ਇੱਕ ਸੈਕੰਡਰੀ ਲੌਗ ਫਾਈਲ ਜੋੜਨੀ ਚਾਹੀਦੀ ਹੈ।

ALTER DATABASE [YourDatabaseName]
ADD LOG FILE 
(
    NAME = N'YourDatabaseName_Log2',
    FILENAME = N'E:TempLogsYourDatabaseName_Log2.ldf',
    SIZE = 5GB,
    MAXSIZE = 50GB,
    FILEGROWTH = 1GB
);

ਇਹ ਤੁਰੰਤ SQL Server ਨੂੰ ਸਾਹ ਲੈਣ ਲਈ ਜਗ੍ਹਾ ਪ੍ਰਦਾਨ ਕਰਦਾ ਹੈ। ਇੱਕ ਵਾਰ ਡੇਟਾਬੇਸ ਔਨਲਾਈਨ ਹੋ ਜਾਣ ‘ਤੇ, ਇੱਕ ਟ੍ਰਾਂਜੈਕਸ਼ਨ ਲੌਗ ਬੈਕਅੱਪ ਲਓ, ਸੈਕੰਡਰੀ ਲੌਗ ਫਾਈਲ ਨੂੰ ਖਾਲੀ ਕਰੋ, ਅਤੇ ਇਸਨੂੰ ਹਟਾ ਦਿਓ:

-- 1. ਲੌਗ ਨੂੰ ਟ੍ਰੰਕੇਟ ਕਰਨ ਲਈ ਇੱਕ ਲੌਗ ਬੈਕਅੱਪ ਲਓ
BACKUP LOG [YourDatabaseName] TO DISK = '...';

-- 2. ਅਸਥਾਈ ਲੌਗ ਫਾਈਲ ਨੂੰ ਖਾਲੀ ਕਰੋ
DBCC SHRINKFILE (N'YourDatabaseName_Log2', EMPTYFILE);

-- 3. ਅਸਥਾਈ ਲੌਗ ਫਾਈਲ ਨੂੰ ਹਟਾਓ
ALTER DATABASE [YourDatabaseName] REMOVE FILE [YourDatabaseName_Log2];

ਟ੍ਰਾਂਜੈਕਸ਼ਨ ਲੌਗ ਰੋਕਥਾਮ ਅਤੇ ਪ੍ਰਬੰਧਨ ਲਈ ਵਧੀਆ ਅਭਿਆਸ

ਪ੍ਰਤੀਕਿਰਿਆਸ਼ੀਲ ਸਮੱਸਿਆ-ਨਿਪਟਾਰਾ ਤਣਾਅਪੂਰਨ ਹੈ ਅਤੇ SLAs ਨੂੰ ਪ੍ਰਭਾਵਿਤ ਕਰਦਾ ਹੈ। ਐਂਟਰਪ੍ਰਾਈਜ਼ ਡੇਟਾਬੇਸ ਸਥਿਰਤਾ ਲਈ ਕਿਰਿਆਸ਼ੀਲ ਆਰਕੀਟੈਕਚਰਲ ਅਤੇ ਸੰਚਾਲਨ ਸੰਬੰਧੀ ਵਧੀਆ ਅਭਿਆਸਾਂ ਨੂੰ ਲਾਗੂ ਕਰਨਾ ਜ਼ਰੂਰੀ ਹੈ।

1. ਇੱਕ ਮਜ਼ਬੂਤ, ਸਵੈਚਲਿਤ ਬੈਕਅੱਪ ਰਣਨੀਤੀ ਲਾਗੂ ਕਰੋ

ਜੇਕਰ ਕੋਈ ਡੇਟਾਬੇਸ Full ਰਿਕਵਰੀ ਮਾਡਲ ਵਿੱਚ ਹੈ, ਤਾਂ ਅਕਸਰ ਟ੍ਰਾਂਜੈਕਸ਼ਨ ਲੌਗ ਬੈਕਅੱਪ ਲਾਜ਼ਮੀ ਹਨ। ਤੁਹਾਡੇ ਰਿਕਵਰੀ ਪੁਆਇੰਟ ਉਦੇਸ਼ (RPO) ਅਤੇ ਟ੍ਰਾਂਜੈਕਸ਼ਨ ਵਾਲੀਅਮ ਦੇ ਆਧਾਰ ‘ਤੇ, ਲੌਗ ਬੈਕਅੱਪ ਹਰ 5 ਤੋਂ 15 ਮਿੰਟਾਂ ਵਿੱਚ ਹੋਣੇ ਚਾਹੀਦੇ ਹਨ।

CloudSave ਵਰਗੇ ਐਂਟਰਪ੍ਰਾਈਜ਼ ਬੈਕਅੱਪ ਹੱਲ ਇਸ ਪ੍ਰਕਿਰਿਆ ਨੂੰ ਕਾਫ਼ੀ ਸਰਲ ਬਣਾਉਂਦੇ ਹਨ। VDI (Virtual Device Interface) ਰਾਹੀਂ ਸਿੱਧੇ SQL Server ਨਾਲ ਏਕੀਕ੍ਰਿਤ ਹੋ ਕੇ, CloudSave DBAs ਨੂੰ ਨੀਤੀ-ਸੰਚਾਲਿਤ, ਉੱਚ-ਆਵਿਰਤੀ ਵਾਲੇ ਟ੍ਰਾਂਜੈਕਸ਼ਨ ਲੌਗ ਬੈਕਅੱਪ ਕੌਂਫਿਗਰ ਕਰਨ ਦੀ ਇਜਾਜ਼ਤ ਦਿੰਦਾ ਹੈ। ਇਹ ਯਕੀਨੀ ਬਣਾਉਂਦਾ ਹੈ ਕਿ ਲੌਗ ਲਗਾਤਾਰ ਟ੍ਰੰਕੇਟ ਕੀਤੇ ਜਾਂਦੇ ਹਨ, ਸੁਰੱਖਿਅਤ ਢੰਗ ਨਾਲ ਐਨਕ੍ਰਿਪਟ ਕੀਤੇ ਜਾਂਦੇ ਹਨ, ਅਤੇ ਆਫ-ਸਾਈਟ ਜਾਂ ਅਟੱਲ ਕਲਾਉਡ ਸਟੋਰੇਜ ਵਿੱਚ ਸਟੋਰ ਕੀਤੇ ਜਾਂਦੇ ਹਨ, ਜੋ ਗੁੰਝਲਦਾਰ ਕਸਟਮ SQL ਏਜੰਟ ਜੌਬਸ ਦੀ ਲੋੜ ਤੋਂ ਬਿਨਾਂ LOG_BACKUP ਵੇਟ ਸਟੇਟ ਨੂੰ ਰੋਕਦਾ ਹੈ।

2. ਟ੍ਰਾਂਜੈਕਸ਼ਨ ਲੌਗ ਦਾ ਸਹੀ ਆਕਾਰ ਨਿਰਧਾਰਤ ਕਰੋ ਅਤੇ VLFs ਦਾ ਪ੍ਰਬੰਧਨ ਕਰੋ

ਆਪਣੇ ਟ੍ਰਾਂਜੈਕਸ਼ਨ ਲੌਗ ਦੇ ਆਕਾਰ ਦਾ ਪ੍ਰਬੰਧਨ ਕਰਨ ਲਈ ਆਟੋ-ਗ੍ਰੋਥ ‘ਤੇ ਨਿਰਭਰ ਕਰਨਾ ਇੱਕ ਖਤਰਨਾਕ ਐਂਟੀ-ਪੈਟਰਨ ਹੈ। ਆਟੋ-ਗ੍ਰੋਥ ਓਪਰੇਸ਼ਨ ਮਹਿੰਗੇ ਹੁੰਦੇ ਹਨ ਅਤੇ ਟ੍ਰਾਂਜੈਕਸ਼ਨ ਪ੍ਰੋਸੈਸਿੰਗ ਨੂੰ ਰੋਕ ਦਿੰਦੇ ਹਨ ਜਦੋਂ ਤੱਕ ਡਿਸਕ ਜ਼ੀਰੋ-ਇਨੀਸ਼ੀਅਲਾਈਜ਼ ਨਹੀਂ ਹੋ ਜਾਂਦੀ (ਜਦੋਂ ਤੱਕ ਇੰਸਟੈਂਟ ਫਾਈਲ ਇਨੀਸ਼ੀਅਲਾਈਜ਼ੇਸ਼ਨ ਸਮਰੱਥ ਨਾ ਹੋਵੇ, ਜੋ ਲੌਗ ਫਾਈਲਾਂ ‘ਤੇ ਲਾਗੂ ਨਹੀਂ ਹੁੰਦੀ)।

ਇਸ ਤੋਂ ਇਲਾਵਾ, ਅਕਸਰ, ਛੋਟੇ ਆਟੋ-ਗ੍ਰੋਥ (ਉਦਾਹਰਨ ਲਈ, ਇੱਕ ਸਮੇਂ ਵਿੱਚ 10% ਜਾਂ 50MB ਵਧਣਾ) VLF ਫ੍ਰੈਗਮੈਂਟੇਸ਼ਨ ਵੱਲ ਲੈ ਜਾਂਦੇ ਹਨ। ਹਜ਼ਾਰਾਂ ਛੋਟੇ VLFs ਵਾਲਾ ਇੱਕ ਟ੍ਰਾਂਜੈਕਸ਼ਨ ਲੌਗ ਡੇਟਾਬੇਸ ਸਟਾਰਟਅੱਪ ਸਮੇਂ, ਬੈਕਅੱਪ ਪ੍ਰਦਰਸ਼ਨ, ਅਤੇ ਰਿਪਲੀਕੇਸ਼ਨ ਲੇਟੈਂਸੀ ਨੂੰ ਬੁਰੀ ਤਰ੍ਹਾਂ ਘਟਾ ਦੇਵੇਗਾ।

  • ਲੌਗ ਦਾ ਪਹਿਲਾਂ ਤੋਂ ਆਕਾਰ ਨਿਰਧਾਰਤ ਕਰੋ: ਆਪਣੇ ਸਭ ਤੋਂ ਵੱਡੇ ਰੱਖ-ਰਖਾਅ ਓਪਰੇਸ਼ਨਾਂ (ਜਿਵੇਂ ਕਿ ਇੰਡੈਕਸ ਰੀਬਿਲਡ) ਦਾ ਵਿਸ਼ਲੇਸ਼ਣ ਕਰੋ ਅਤੇ LDF ਫਾਈਲ ਨੂੰ ਉਹਨਾਂ ਨੂੰ ਵਧਾਏ ਬਿਨਾਂ ਅਨੁਕੂਲਿਤ ਕਰਨ ਲਈ ਪਹਿਲਾਂ ਤੋਂ ਆਕਾਰ ਦਿਓ।
  • ਸਥਿਰ ਆਟੋ-ਗ੍ਰੋਥ ਸੈੱਟ ਕਰੋ: ਆਟੋ-ਗ੍ਰੋਥ ਨੂੰ ਪ੍ਰਤੀਸ਼ਤ ਤੋਂ ਬਦਲ ਕੇ ਇੱਕ ਸਥਿਰ ਆਕਾਰ (ਉਦਾਹਰਨ ਲਈ, 1GB ਜਾਂ 5GB) ਵਿੱਚ ਕਰੋ ਤਾਂ ਜੋ ਇਹ ਯਕੀਨੀ ਬਣਾਇਆ ਜਾ ਸਕੇ ਕਿ VLFs ਇੱਕ ਸਿਹਤਮੰਦ ਆਕਾਰ ਵਿੱਚ ਬਣਾਏ ਗਏ ਹਨ।

ਤੁਸੀਂ ਹੇਠ ਲਿਖੀ ਕੁਐਰੀ (SQL Server 2017+ ਲਈ) ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਆਪਣੇ VLF ਕਾਉਂਟ ਦੀ ਜਾਂਚ ਕਰ ਸਕਦੇ ਹੋ:

SELECT 
    db_name(database_id) AS DatabaseName,
    COUNT(vlf_sequence_number) AS VLF_Count
FROM sys.dm_db_log_info(DB_ID('YourDatabaseName'));

ਜੇਕਰ ਤੁਹਾਡਾ VLF ਕਾਉਂਟ 500 ਤੋਂ ਵੱਧ ਹੈ, ਤਾਂ ਸ਼ਾਂਤ ਸਮੇਂ ਦੀ ਉਡੀਕ ਕਰਨ, ਲੌਗ ਨੂੰ ਘੱਟੋ-ਘੱਟ ਆਕਾਰ ਤੱਕ ਸੁੰਗੜਨ, ਅਤੇ ਇਸਨੂੰ ਹੱਥੀਂ ਵੱਡੇ ਹਿੱਸਿਆਂ ਵਿੱਚ ਇਸਦੇ ਲੋੜੀਂਦੇ ਆਕਾਰ ਤੱਕ ਵਧਾਉਣ ‘ਤੇ ਵਿਚਾਰ ਕਰੋ।

3. ਇੰਡੈਕਸ ਰੱਖ-ਰਖਾਅ ਓਪਰੇਸ਼ਨਾਂ ਨੂੰ ਅਨੁਕੂਲਿਤ ਕਰੋ

ਇੰਡੈਕਸ ਰੀਬਿਲਡ ਪੂਰੀ ਤਰ੍ਹਾਂ ਲੌਗ ਕੀਤੇ ਓਪਰੇਸ਼ਨ ਹਨ, ਇੱਥੋਂ ਤੱਕ ਕਿ Bulk-Logged ਰਿਕਵਰੀ ਮਾਡਲ ਵਿੱਚ ਵੀ (ਇੰਡੈਕਸ ਦੀ ਕਿਸਮ ‘ਤੇ ਨਿਰਭਰ ਕਰਦਾ ਹੈ)। 500GB ਇੰਡੈਕਸ ਨੂੰ ਦੁਬਾਰਾ ਬਣਾਉਣਾ ਘੱਟੋ-ਘੱਟ 500GB ਟ੍ਰਾਂਜੈਕਸ਼ਨ ਲੌਗ ਰਿਕਾਰਡ ਤਿਆਰ ਕਰੇਗਾ।

ਰੱਖ-ਰਖਾਅ ਦੌਰਾਨ ਲੌਗ ਬਲੋਟ ਨੂੰ ਘਟਾਉਣ ਲਈ:
* ਇੰਡੈਕਸਾਂ ਨੂੰ ਦੁਬਾਰਾ ਬਣਾਉਣ ਵੇਲੇ SORT_IN_TEMPDB = ON ਦੀ ਵਰਤੋਂ ਕਰੋ। ਇਹ ਸੌਰਟਿੰਗ ਪੜਾਅ ਨੂੰ TempDB ਵਿੱਚ ਆਫਲੋਡ ਕਰਦਾ ਹੈ, ਜਿਸ ਨਾਲ ਉਪਭੋਗਤਾ ਡੇਟਾਬੇਸ ਦੇ ਟ੍ਰਾਂਜੈਕਸ਼ਨ ਲੌਗ ‘ਤੇ ਬੋਝ ਘੱਟ ਹੁੰਦਾ ਹੈ।
* ਜਿੱਥੇ ਸੰਭਵ ਹੋਵੇ ਇੰਡੈਕਸ ਰੀਬਿਲਡ ਤੋਂ ਇੰਡੈਕਸ ਰੀਆਰਗਨਾਈਜ਼ ਵਿੱਚ ਬਦਲੋ, ਕਿਉਂਕਿ ਰੀਆਰਗਨਾਈਜ਼ੇਸ਼ਨ ਵਧੇਰੇ ਲੌਗ-ਕੁਸ਼ਲ ਹਨ ਅਤੇ ਪੂਰੇ ਓਪਰੇਸ਼ਨ ਨੂੰ ਰੋਲ ਬੈਕ ਕੀਤੇ ਬਿਨਾਂ ਰੁਕਾਵਟ ਪਾਈ ਜਾ ਸਕਦੀ ਹੈ।
* ਵੱਡੇ DELETE ਜਾਂ UPDATE ਓਪਰੇਸ਼ਨਾਂ ਨੂੰ ਬੈਚ ਕਰੋ। ਇੱਕ ਟ੍ਰਾਂਜੈਕਸ਼ਨ ਵਿੱਚ 10 ਮਿਲੀਅਨ ਕਤਾਰਾਂ ਨੂੰ ਮਿਟਾਉਣ ਦੀ ਬਜਾਏ, ਉਹਨਾਂ ਨੂੰ 50,000 ਦੇ ਬੈਚਾਂ ਵਿੱਚ ਮਿਟਾਓ, ਕਮਿਟ ਕਰੋ ਅਤੇ ਲੌਗ ਬੈਕਅੱਪ ਨੂੰ ਬੈਚਾਂ ਦੇ ਵਿਚਕਾਰ ਲੌਗ ਨੂੰ ਟ੍ਰੰਕੇਟ ਕਰਨ ਦੀ ਇਜਾਜ਼ਤ ਦਿਓ।

4. ਉੱਚ ਉਪਲਬਧਤਾ ਅਤੇ ਰਿਪਲੀਕੇਸ਼ਨ ਟੌਪੋਲੋਜੀ ਦੀ ਨਿਗਰਾਨੀ ਕਰੋ

AlwaysOn Availability Groups ਵਿੱਚ, ਪ੍ਰਾਇਮਰੀ ਰਿਪਲੀਕਾ ਆਪਣੇ ਲੌਗ ਨੂੰ ਉਦੋਂ ਤੱਕ ਟ੍ਰੰਕੇਟ ਨਹੀਂ ਕਰ ਸਕਦਾ ਜਦੋਂ ਤੱਕ ਲੌਗ ਰਿਕਾਰਡ ਸਾਰੇ ਸਿੰਕ੍ਰੋਨਸ ਅਤੇ ਅਸਿੰਕ੍ਰੋਨਸ ਸੈਕੰਡਰੀ ਰਿਪਲੀਕਾ ‘ਤੇ ਹਾਰਡਨ ਨਹੀਂ ਹੋ ਜਾਂਦੇ।

ਜੇਕਰ ਕੋਈ ਸੈਕੰਡਰੀ ਰਿਪਲੀਕਾ ਔਫਲਾਈਨ ਹੋ ਜਾਂਦਾ ਹੈ, ਜਾਂ ਜੇਕਰ ਨੈੱਟਵਰਕ ਬੈਂਡਵਿਡਥ ਪ੍ਰਾਇਮਰੀ ਦੀ ਟ੍ਰਾਂਜੈਕਸ਼ਨ ਉਤਪੱਤੀ ਦਰ ਨਾਲ ਨਹੀਂ ਰਹਿ ਸਕਦੀ, ਤਾਂ ਪ੍ਰਾਇਮਰੀ ਦੀ ਸੈਂਡ ਕਿਊ (send queue) ਵਧ ਜਾਵੇਗੀ, ਅਤੇ ਲੌਗ ਭਰ ਜਾਵੇਗਾ (AVAILABILITY_REPLICA ਵੇਟ ਟਾਈਪ)।

SQLServer:Replica > Log Send Queue ਪਰਫਾਰਮੈਂਸ ਕਾਊਂਟਰ ਲਈ ਮਜ਼ਬੂਤ ਨਿਗਰਾਨੀ ਲਾਗੂ ਕਰੋ। ਜੇਕਰ ਕੋਈ ਸੈਕੰਡਰੀ ਰਿਪਲੀਕਾ ਸਥਾਈ ਤੌਰ ‘ਤੇ ਗੁੰਮ ਹੋ ਜਾਂਦਾ ਹੈ, ਤਾਂ ਤੁਹਾਨੂੰ ਇਸਨੂੰ Availability Group ਤੋਂ ਹਟਾਉਣਾ ਚਾਹੀਦਾ ਹੈ ਜਾਂ ਪ੍ਰਾਇਮਰੀ ਲੌਗ ਨੂੰ ਟ੍ਰੰਕੇਟ ਕਰਨ ਦੀ ਇਜਾਜ਼ਤ ਦੇਣ ਲਈ ਡੇਟਾ ਮੂਵਮੈਂਟ ਨੂੰ ਮੁਅੱਤਲ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ।

ਸਿੱਟਾ

ਭਰੇ ਹੋਏ ਟ੍ਰਾਂਜੈਕਸ਼ਨ ਲੌਗ ਦਾ ਸਾਹਮਣਾ ਕਰਨਾ ਡੇਟਾਬੇਸ ਐਡਮਿਨਿਸਟ੍ਰੇਟਰਾਂ ਲਈ ਇੱਕ ਅਨੁਭਵ ਹੈ, ਪਰ ਇਸਦਾ ਮਤਲਬ ਲੰਬੇ ਸਮੇਂ ਲਈ ਡਾਊਨਟਾਈਮ ਹੋਣਾ ਜ਼ਰੂਰੀ ਨਹੀਂ ਹੈ। Write-Ahead Logging ਅਤੇ VLFs ਦੇ ਮਕੈਨਿਕਸ ਨੂੰ ਸਮਝ ਕੇ, ਤੁਸੀਂ sys.databases ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਤੇਜ਼ੀ ਨਾਲ ਮੂਲ ਕਾਰਨ ਦਾ ਨਿਦਾਨ ਕਰ ਸਕਦੇ ਹੋ ਅਤੇ ਸਹੀ ਤੇਜ਼ ਰਿਕਵਰੀ ਰਣਨੀਤੀ ਲਾਗੂ ਕਰ ਸਕਦੇ ਹੋ।

ਲੰਬੇ ਸਮੇਂ ਦੀ ਸਥਿਰਤਾ ਪ੍ਰਤੀਕਿਰਿਆਸ਼ੀਲ ਫਿਕਸਾਂ ਤੋਂ ਦੂਰ ਜਾਣ ‘ਤੇ ਨਿਰਭਰ ਕਰਦੀ ਹੈ। ਆਪਣੀਆਂ ਲੌਗ ਫਾਈਲਾਂ ਦਾ ਪਹਿਲਾਂ ਤੋਂ ਆਕਾਰ ਨਿਰਧਾਰਤ ਕਰਨਾ, ਰੱਖ-ਰਖਾਅ ਦੇ ਰੁਟੀਨ ਨੂੰ ਅਨੁਕੂਲਿਤ ਕਰਨਾ, ਅਤੇ ਸਖ਼ਤ, ਸਵੈਚਲਿਤ ਲੌਗ ਬੈਕਅੱਪ ਸਮਾਂ-ਸਾਰਣੀ ਨੂੰ ਲਾਗੂ ਕਰਨ ਲਈ CloudSave ਵਰਗੇ ਐਂਟਰਪ੍ਰਾਈਜ਼-ਗ੍ਰੇਡ ਬੈਕਅੱਪ ਪਲੇਟਫਾਰਮਾਂ ਦੀ ਵਰਤੋਂ ਕਰਨਾ ਇਹ ਯਕੀਨੀ ਬਣਾਏਗਾ ਕਿ ਤੁਹਾਡੇ ਟ੍ਰਾਂਜੈਕਸ਼ਨ ਲੌਗ ਸਿਹਤਮੰਦ, ਟ੍ਰੰਕੇਟ ਕੀਤੇ ਹੋਏ, ਅਤੇ ਉੱਚ-ਥ੍ਰੂਪੁੱਟ ਪ੍ਰੋਡਕਸ਼ਨ ਵਰਕਲੋਡ ਦਾ ਸਮਰਥਨ ਕਰਨ ਲਈ ਤਿਆਰ ਰਹਿਣ।

Categories