MSSQL டிரான்ஸாக்ஷன் லாக் நிறைந்துவிடுதல்: தடுப்பு மற்றும் விரைவான மீட்பு உத்திகள்

மைக்ரோசாஃப்ட் SQL சர்வரை நிர்வகிக்கும் தரவுத்தள நிர்வாகிகள் (DBAs) மற்றும் டெவ்ஆப்ஸ் (DevOps) பொறியாளர்களுக்கு, பிழை 9002-ஐ விட அதிக பதற்றத்தை ஏற்படுத்தும் எச்சரிக்கைகள் மிகக் குறைவு: ‘X’ தரவுத்தளத்திற்கான பரிவர்த்தனை பதிவு (transaction log) நிரம்பிவிட்டது. பரிவர்த்தனை பதிவு நிரம்பி, மேலும் வளர முடியாதபோது, தரவுத்தளம் நடைமுறையில் ‘வாசிக்க மட்டுமே’ (read-only) என்ற நிலைக்குச் சென்றுவிடும். அனைத்து INSERT, UPDATE, மற்றும் DELETE செயல்பாடுகளும் நின்றுவிடும், பயன்பாட்டு பரிவர்த்தனைகள் தோல்வியடையும், மற்றும் உற்பத்தி செயல்பாடு முற்றிலும் முடங்கிவிடும்.

SQL சர்வர் பரிவர்த்தனை பதிவின் அடிப்படை கட்டமைப்பைப் புரிந்துகொள்வது, மூல காரணத்தை துல்லியமாகக் கண்டறிவது மற்றும் விரைவான மீட்பு நடைமுறைகளைச் செயல்படுத்துவது ஆகியவை உயர் கிடைக்கும் தன்மையை (high availability) பராமரிக்க முக்கியமான திறன்களாகும். இந்த விரிவான வழிகாட்டி, பரிவர்த்தனை பதிவின் இயக்கவியல், அவசரகாலத்தில் நிரம்பிய பதிவை எவ்வாறு சரிசெய்வது மற்றும் அது மீண்டும் நிகழாமல் தடுக்க கட்டடக்கலை சிறந்த நடைமுறைகள் ஆகியவற்றை ஆராய்கிறது.

SQL சர்வர் பரிவர்த்தனை பதிவு கட்டமைப்பைப் புரிந்துகொள்வது

நிரம்பிய பரிவர்த்தனை பதிவை திறம்பட சரிசெய்ய, SQL சர்வர் எவ்வாறு தரவை எழுதுகிறது மற்றும் நிர்வகிக்கிறது என்பதை நீங்கள் முதலில் புரிந்துகொள்ள வேண்டும்.

ரைட்-அஹெட் லாக்கிங் (Write-Ahead Logging – WAL)

SQL சர்வர் ரைட்-அஹெட் லாக்கிங் (WAL) நெறிமுறையைப் பயன்படுத்துகிறது. தரவு மாற்றம் நிகழும்போதெல்லாம், அந்த மாற்றம் முதலில் நினைவகத்தில் உள்ள பரிவர்த்தனை பதிவில் எழுதப்படும், பின்னர் தரவுத்தள கோப்புகளில் (MDF/NDF) உண்மையான தரவு பக்கங்கள் புதுப்பிக்கப்படுவதற்கு முன்பு வட்டில் உள்ள இயற்பியல் பதிவு கோப்பில் (physical log file) மாற்றப்படும். இது ACID (Atomicity, Consistency, Isolation, Durability) இணக்கத்தன்மையை உறுதி செய்கிறது, இதனால் விபத்து ஏற்பட்டால், SQL சர்வர் பரிவர்த்தனைகளை மீண்டும் இயக்க (roll forward) அல்லது ரத்து செய்ய (roll back) முடியும்.

விர்ச்சுவல் லாக் கோப்புகள் (VLFs) மற்றும் வட்ட பதிவு (Circular Logging)

உள்நாட்டில், இயற்பியல் பரிவர்த்தனை பதிவு கோப்பு (LDF) விர்ச்சுவல் லாக் கோப்புகள் (VLFs) எனப்படும் சிறிய, தர்க்கரீதியான பிரிவுகளாக பிரிக்கப்பட்டுள்ளது. பரிவர்த்தனை பதிவு வட்ட வடிவில் செயல்படுகிறது. பதிவு பதிவுகள் எழுதப்படும்போது, அவை ஒரு VLF-ஐ நிரப்பி அடுத்ததற்கு நகரும்.

பதிவு இயற்பியல் கோப்பின் முடிவை அடையும் போது, அது தொடக்கத்திற்குச் செல்ல முயற்சிக்கும். இருப்பினும், ஒரு VLF செயலற்றதாக (inactive) குறிக்கப்பட்டிருந்தால் மட்டுமே அதை மேலெழுத முடியும். அனைத்து VLF-களும் செயலில் இருந்தால் (அதாவது SQL சர்வருக்கு இன்னும் தேவைப்படும் பதிவு பதிவுகளைக் கொண்டிருந்தால்), பதிவால் வட்டமாகச் செல்ல முடியாது. தானியங்கி-வளர்ச்சி (auto-growth) இயக்கப்பட்டு, வட்டு இடம் இருந்தால், இயற்பியல் கோப்பு வளரும். வட்டு நிரம்பியிருந்தால் அல்லது தானியங்கி-வளர்ச்சி கட்டுப்படுத்தப்பட்டிருந்தால், நீங்கள் பிழை 9002-ஐ எதிர்கொள்வீர்கள்.

பதிவு துண்டிப்பு (Log Truncation) vs. பதிவு சுருக்கம் (Log Shrinking)

பதிவை துண்டிப்பது இயற்பியல் கோப்பின் அளவைக் குறைக்கும் என்பது ஒரு பொதுவான தவறான கருத்து.
* பதிவு துண்டிப்பு (Log Truncation): செயலில் உள்ள VLF-களை செயலற்றதாகக் குறிக்கும் செயல்முறை, இது இடத்தை மீண்டும் பயன்படுத்த அனுமதிக்கிறது. இது வட்டில் உள்ள LDF கோப்பின் அளவைக் குறைக்காது.
* பதிவு சுருக்கம் (Log Shrinking): LDF கோப்பின் அளவை இயற்பியல் ரீதியாகக் குறைத்து, இடத்தை இயக்க முறைமைக்குத் திரும்பக் கொடுக்கும் செயல்முறை.

முழு மீட்பு மாதிரியில் (Full Recovery model), பரிவர்த்தனை பதிவு காப்புப்பிரதி வெற்றிகரமாக முடிந்தால் மட்டுமே பதிவு துண்டிப்பு நிகழும் (வேறு எந்த செயல்முறைகளும் பதிவை செயலில் வைத்திருக்கவில்லை என்று வைத்துக்கொண்டால்).

“பரிவர்த்தனை பதிவு நிரம்பியது” பிழையை (பிழை 9002) கண்டறிதல்

பதிவு நிரம்பியிருக்கும்போது, உங்கள் முதல் படி வட்டு இடத்தை கண்மூடித்தனமாக அதிகரிப்பதோ அல்லது கோப்புகளைச் சுருக்குவதோ அல்ல. பதிவு ஏன் துண்டிக்கப்படவில்லை என்பதை நீங்கள் கண்டறிய வேண்டும். sys.databases பட்டியல் பார்வை (catalog view) மூலம் பதிவு மறுபயன்பாட்டை எது தடுக்கிறது என்பதை SQL சர்வர் உங்களுக்குத் தெரிவிக்கும் உள்ளமைக்கப்பட்ட பொறிமுறையைக் கொண்டுள்ளது.

தடையைக் கண்டறிய பின்வரும் 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: தரவுத்தளம் முழு அல்லது மொத்த-பதிவு மீட்பு மாதிரியில் உள்ளது, மேலும் பரிவர்த்தனை பதிவு காப்புப்பிரதி சமீபத்தில் எடுக்கப்படவில்லை. இதுவே மிகவும் பொதுவான காரணம்.
2. ACTIVE_TRANSACTION: நீண்ட காலம் இயங்கும் பரிவர்த்தனை (எ.கா., மிகப்பெரிய குறியீட்டு மறுசீரமைப்பு அல்லது மறக்கப்பட்ட உறுதிப்படுத்தப்படாத பரிவர்த்தனை) பதிவை செயலில் வைத்திருக்கிறது.
3. REPLICATION / CDC: பரிவர்த்தனை பிரதிபலிப்பு (Transactional Replication) அல்லது சேஞ்ச் டேட்டா கேப்சர் (CDC) இயக்கப்பட்டுள்ளது, மேலும் லாக் ரீடர் ஏஜென்ட் இன்னும் பரிவர்த்தனைகளைச் செயலாக்கவில்லை.
4. AVAILABILITY_REPLICA: AlwaysOn அவையலபிலிட்டி குரூப்பில், ஒரு இரண்டாம் நிலை பிரதி (secondary replica) துண்டிக்கப்பட்டுள்ளது அல்லது மிக மெதுவாக ஒத்திசைக்கப்படுகிறது, இது முதன்மை பிரதிக்கு பதிவு பதிவுகளை இரண்டாம் நிலையில் உறுதிப்படுத்தும் வரை வைத்திருக்க கட்டாயப்படுத்துகிறது.

விரைவான மீட்பு உத்திகள்: உற்பத்தியில் சிக்கலைத் தீர்ப்பது

திரும்பப் பெறப்பட்ட log_reuse_wait_desc-ஐப் பொறுத்து, உங்கள் அவசரகால பதில் மாறுபடும். மிகவும் பொதுவான காட்சிகளுக்கான விரைவான மீட்பு உத்திகள் இங்கே உள்ளன.

காட்சி 1: விடுபட்ட அல்லது தோல்வியுற்ற பதிவு காப்புப்பிரதிகள் (LOG_BACKUP)

காத்திருப்பு வகை LOG_BACKUP ஆக இருந்தால், தீர்வு எளிதானது: நீங்கள் பரிவர்த்தனை பதிவை காப்புப்பிரதி எடுக்க வேண்டும்.

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

காப்புப்பிரதி முடிந்ததும், செயலற்ற VLF-கள் துண்டிக்கப்படும், மேலும் SQL சர்வர் சாதாரண செயல்பாடுகளை மீண்டும் தொடங்கும். உங்கள் காப்புப்பிரதி இயக்கி நிரம்பியிருந்தால், நீங்கள் தற்காலிக நெட்வொர்க் பகிர்வு அல்லது நல் சாதனத்திற்கு (null device) காப்புப்பிரதி எடுக்க வேண்டியிருக்கலாம் (தரவுத்தளம் எளிதில் மீண்டும் உருவாக்கக்கூடியதாக இல்லாவிட்டால் இது மிகவும் தவிர்க்கப்பட வேண்டும், ஏனெனில் இது பதிவு சங்கிலியை உடைக்கிறது):

-- எச்சரிக்கை: இது பதிவு சங்கிலியை உடைத்து, குறிப்பிட்ட நேர மீட்பை சமரசம் செய்கிறது.
-- முற்றிலும் அவசியமானால் மட்டுமே பயன்படுத்தவும் மற்றும் உடனடியாக முழு காப்புப்பிரதியுடன் தொடரவும்.
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 சர்வர் சேவையை மறுதொடக்கம் செய்யாதீர்கள், இல்லையெனில் மறுதொடக்கம் செய்தவுடன் தரவுத்தளம் மீட்பு பயன்முறைக்குச் சென்றுவிடும்.

காட்சி 3: அவசரகால இட ஒதுக்கீடு (வட்டு 100% நிரம்பியுள்ளது)

LDF கோப்பு முழு இயக்கியையும் பயன்படுத்தியிருந்தால், உங்களால் காப்புப்பிரதியைக்கூட இயக்க முடியாது, ஏனெனில் காப்புப்பிரதி நிகழ்வை பதிவு செய்ய SQL சர்வருக்கு மிகச்சிறிய அளவு பதிவு இடம் தேவைப்படுகிறது. இந்த நிலையில், நீங்கள் வேறு இயக்கியில் கூடுதல் பதிவு கோப்பைச் சேர்க்க வேண்டும்.

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

இது உடனடியாக SQL சர்வருக்கு மூச்சுவிட இடமளிக்கிறது. தரவுத்தளம் ஆன்லைனில் வந்தவுடன், பரிவர்த்தனை பதிவு காப்புப்பிரதியை எடுத்து, இரண்டாம் நிலை பதிவு கோப்பை காலி செய்து, அதை அகற்றவும்:

-- 1. பதிவை துண்டிக்க பதிவு காப்புப்பிரதியை எடுக்கவும்
BACKUP LOG [YourDatabaseName] TO DISK = '...';

-- 2. தற்காலிக பதிவு கோப்பை காலி செய்யவும்
DBCC SHRINKFILE (N'YourDatabaseName_Log2', EMPTYFILE);

-- 3. தற்காலிக பதிவு கோப்பை அகற்றவும்
ALTER DATABASE [YourDatabaseName] REMOVE FILE [YourDatabaseName_Log2];

பரிவர்த்தனை பதிவு தடுப்பு மற்றும் நிர்வாகத்திற்கான சிறந்த நடைமுறைகள்

வினைத்திறன் மிக்க சரிசெய்தல் மன அழுத்தத்தை ஏற்படுத்துகிறது மற்றும் SLA-களை பாதிக்கிறது. நிறுவன தரவுத்தள நிலைத்தன்மைக்கு செயலூக்கமான கட்டடக்கலை மற்றும் செயல்பாட்டு சிறந்த நடைமுறைகளைச் செயல்படுத்துவது அவசியம்.

1. வலுவான, தானியங்கி காப்புப்பிரதி உத்தியைச் செயல்படுத்தவும்

ஒரு தரவுத்தளம் முழு மீட்பு மாதிரியில் இருந்தால், அடிக்கடி பரிவர்த்தனை பதிவு காப்புப்பிரதிகள் எடுப்பது கட்டாயமாகும். உங்கள் மீட்பு புள்ளி குறிக்கோள் (RPO) மற்றும் பரிவர்த்தனை அளவைப் பொறுத்து, பதிவு காப்புப்பிரதிகள் ஒவ்வொரு 5 முதல் 15 நிமிடங்களுக்கு ஒருமுறை நடக்க வேண்டும்.

CloudSave போன்ற நிறுவன காப்புப்பிரதி தீர்வுகள் இந்த செயல்முறையை கணிசமாக எளிதாக்குகின்றன. VDI (Virtual Device Interface) வழியாக SQL சர்வர் உடன் நேரடியாக ஒருங்கிணைப்பதன் மூலம், CloudSave தரவுத்தள நிர்வாகிகள் கொள்கை-உந்துதல், உயர்-அதிர்வெண் பரிவர்த்தனை பதிவு காப்புப்பிரதிகளை உள்ளமைக்க அனுமதிக்கிறது. இது பதிவுகள் தொடர்ந்து துண்டிக்கப்படுவதையும், பாதுகாப்பாக குறியாக்கம் செய்யப்படுவதையும், ஆஃப்-சைட் அல்லது மாற்ற முடியாத கிளவுட் சேமிப்பகத்தில் சேமிக்கப்படுவதையும் உறுதி செய்கிறது, இது சிக்கலான தனிப்பயன் SQL ஏஜென்ட் வேலைகள் தேவையில்லாமல் LOG_BACKUP காத்திருப்பு நிலையைத் தடுக்கிறது.

2. பரிவர்த்தனை பதிவை சரியான அளவில் வைத்திருத்தல் மற்றும் VLF-களை நிர்வகித்தல்

உங்கள் பரிவர்த்தனை பதிவு அளவை நிர்வகிக்க தானியங்கி-வளர்ச்சியை நம்பியிருப்பது ஒரு ஆபத்தான எதிர்மறை வடிவமாகும். தானியங்கி-வளர்ச்சி செயல்பாடுகள் விலை உயர்ந்தவை மற்றும் வட்டு பூஜ்ஜிய-தொடக்கமாக இருக்கும்போது பரிவர்த்தனை செயலாக்கத்தை இடைநிறுத்துகின்றன (இன்ஸ்டன்ட் ஃபைல் இனிஷியலைசேஷன் இயக்கப்படாவிட்டால், இது பதிவு கோப்புகளுக்குப் பொருந்தாது).

மேலும், அடிக்கடி, சிறிய தானியங்கி-வளர்ச்சிகள் (எ.கா., 10% அல்லது 50MB அளவில் வளர்வது) VLF துண்டாக்கத்திற்கு (fragmentation) வழிவகுக்கும். ஆயிரக்கணக்கான சிறிய VLF-களைக் கொண்ட பரிவர்த்தனை பதிவு தரவுத்தள தொடக்க நேரங்கள், காப்புப்பிரதி செயல்திறன் மற்றும் பிரதிபலிப்பு தாமதத்தை கடுமையாக பாதிக்கும்.

• பதிவை முன்கூட்டியே அளவிடவும்: உங்கள் மிகப்பெரிய பராமரிப்பு செயல்பாடுகளை (குறியீட்டு மறுசீரமைப்புகள் போன்றவை) பகுப்பாய்வு செய்து, LDF கோப்பை வளராமல் இடமளிக்க முன்கூட்டியே அளவிடவும்.
• நிலையான தானியங்கி-வளர்ச்சியை அமைக்கவும்: தானியங்கி-வளர்ச்சியை சதவீதத்திலிருந்து நிலையான அளவிற்கு (எ.கா., 1GB அல்லது 5GB) மாற்றவும், இதனால் VLF-கள் ஆரோக்கியமான அளவில் உருவாக்கப்படுவதை உறுதிசெய்யலாம்.

பின்வரும் வினவலைப் பயன்படுத்தி உங்கள் VLF எண்ணிக்கையை நீங்கள் சரிபார்க்கலாம் (SQL சர்வர் 2017+ க்கு):

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. குறியீட்டு பராமரிப்பு செயல்பாடுகளை மேம்படுத்தவும்

குறியீட்டு மறுசீரமைப்புகள் முழுமையாக பதிவு செய்யப்பட்ட செயல்பாடுகளாகும், மொத்த-பதிவு மீட்பு மாதிரியில் கூட (குறியீட்டு வகையைப் பொறுத்து). 500GB குறியீட்டை மறுசீரமைப்பது குறைந்தது 500GB பரிவர்த்தனை பதிவு பதிவுகளை உருவாக்கும்.

பராமரிப்பின் போது பதிவு வீக்கத்தைக் குறைக்க:
* குறியீடுகளை மறுசீரமைக்கும்போது SORT_IN_TEMPDB = ON என்பதைப் பயன்படுத்தவும். இது வரிசைப்படுத்தும் கட்டத்தை TempDB-க்கு மாற்றுகிறது, இது பயனர் தரவுத்தளத்தின் பரிவர்த்தனை பதிவின் சுமையைக் குறைக்கிறது.
* குறியீட்டு மறுசீரமைப்பிலிருந்து (rebuilds) குறியீட்டு மறுஒழுங்கமைப்பிற்கு (reorganizes) மாறவும், ஏனெனில் மறுஒழுங்கமைப்புகள் பதிவு-திறன் கொண்டவை மற்றும் முழு செயல்பாட்டையும் ரத்து செய்யாமல் குறுக்கிடப்படலாம்.
* பெரிய DELETE அல்லது UPDATE செயல்பாடுகளை தொகுதிகளாகச் செய்யவும். ஒரு பரிவர்த்தனையில் 10 மில்லியன் வரிசைகளை நீக்குவதற்குப் பதிலாக, அவற்றை 50,000 தொகுதிகளாக நீக்கி, உறுதிப்படுத்தி, தொகுதிகளுக்கு இடையில் பதிவு காப்புப்பிரதிகள் பதிவை துண்டிக்க அனுமதிக்கவும்.

4. உயர் கிடைக்கும் தன்மை மற்றும் பிரதிபலிப்பு இடவியல்களைக் கண்காணிக்கவும்

AlwaysOn அவையலபிலிட்டி குரூப்களில், அனைத்து ஒத்திசைவான மற்றும் ஒத்திசைவற்ற இரண்டாம் நிலை பிரதிகளிலும் பதிவு பதிவுகள் உறுதி செய்யப்படும் வரை முதன்மை பிரதியால் அதன் பதிவை துண்டிக்க முடியாது.

ஒரு இரண்டாம் நிலை பிரதி ஆஃப்லைனில் சென்றால், அல்லது நெட்வொர்க் அலைவரிசையால் முதன்மை பிரதியின் பரிவர்த்தனை உருவாக்க விகிதத்தைத் தக்கவைக்க முடியாவிட்டால், முதன்மை பிரதியின் அனுப்பும் வரிசை வளரும், மேலும் பதிவு நிரம்பிவிடும் (AVAILABILITY_REPLICA காத்திருப்பு வகை).

SQLServer:Replica > Log Send Queue செயல்திறன் கவுண்டருக்காக வலுவான கண்காணிப்பைச் செயல்படுத்தவும். ஒரு இரண்டாம் நிலை பிரதி நிரந்தரமாக இழந்தால், நீங்கள் அதை அவையலபிலிட்டி குரூப்பிலிருந்து அகற்ற வேண்டும் அல்லது முதன்மை பதிவு துண்டிக்கப்படுவதை அனுமதிக்க தரவு நகர்வை இடைநிறுத்த வேண்டும்.

முடிவு

நிரம்பிய பரிவர்த்தனை பதிவை எதிர்கொள்வது தரவுத்தள நிர்வாகிகளுக்கு ஒரு சவாலான அனுபவமாகும், ஆனால் அது நீண்ட கால முடக்கத்திற்கு வழிவகுக்க வேண்டிய அவசியமில்லை. ரைட்-அஹெட் லாக்கிங் மற்றும் VLF-களின் இயக்கவியலைப் புரிந்துகொள்வதன் மூலம், sys.databases-ஐப் பயன்படுத்தி மூல காரணத்தை விரைவாகக் கண்டறிந்து சரியான விரைவான மீட்பு உத்தியைப் பயன்படுத்தலாம்.

நீண்ட கால நிலைத்தன்மை வினைத்திறன் மிக்க தீர்வுகளிலிருந்து விலகிச் செல்வதைச் சார்ந்துள்ளது. உங்கள் பதிவு கோப்புகளை முன்கூட்டியே அளவிடுவது, பராமரிப்பு நடைமுறைகளை மேம்படுத்துவது மற்றும் கடுமையான, தானியங்கி பதிவு காப்புப்பிரதி அட்டவணைகளை அமல்படுத்த CloudSave போன்ற நிறுவன-தர காப்புப்பிரதி தளங்களைப் பயன்படுத்துவது உங்கள் பரிவர்த்தனை பதிவுகள் ஆரோக்கியமாகவும், துண்டிக்கப்பட்டும், உயர்-செயல்திறன் கொண்ட உற்பத்தி பணிச்சுமைகளை ஆதரிக்கத் தயாராகவும் இருப்பதை உறுதி செய்யும்.