මෙය බොහෝ සංසදවල සහ වෙබය පුරා පොදු ප්‍රශ්නයක් ලෙස පෙනේ, සාමාන්‍යයෙන් මෙවැනි ශබ්ද කරන බොහෝ ආකෘති වලින් එය මෙහි අසනු ලැබේ:

SQL සේවාදායකයේ -

• ගනුදෙනු ලොගය එතරම් විශාල වීමට හේතු මොනවාද?
• මගේ ලොග් ගොනුව එතරම් විශාල වන්නේ ඇයි?
• මෙම ගැටළුව ඇතිවීම වලක්වා ගත හැකි ක්‍රම මොනවාද?
• මූලික හේතුව සමඟ මා සොයා බලා මගේ ගනුදෙනු ලොග් ගොනුව සෞඛ්‍ය සම්පන්න ප්‍රමාණයකට දැමීමට අවශ්‍ය වූ විට මා කුමක් කළ යුතුද?

කෙටි පිළිතුරක්:

ඔබට බොහෝ විට දීර් running කාලයක් තිස්සේ ක්‍රියාත්මක වන ගනුදෙනුවක් (දර්ශක නඩත්තු කිරීම, විශාල කණ්ඩායම මකාදැමීම හෝ යාවත්කාලීන කිරීම?) හෝ ඔබ සිටින්නේ “පෙරනිමි” (පෙරනිමියෙන් අදහස් කරන දෙයට වඩා පහළින්) ප්‍රතිසාධන මාදිලියේ වන Fullඅතර ලොග් උපස්ථයක් ගෙන නොමැත (හෝ ඒවා නිතරම ප්‍රමාණවත් නොවේ).

එය ප්‍රතිසාධන ආකෘති ගැටළුවක් නම්, සරල පිළිතුර වනුයේ Simpleඔබට වේලාව යථා තත්ත්වයට පත් කිරීම සහ සාමාන්‍ය ලොග් උපස්ථ අවශ්‍ය නොවේ නම් ප්‍රතිසාධන ප්‍රකාරයට මාරුවීමයි. කෙසේවෙතත්, බොහෝ අය ප්‍රතිසාධන ආකෘති තේරුම් නොගෙන ඔවුන්ගේ පිළිතුර බවට පත් කරති. එය වැදගත් වන්නේ ඇයිද යන්න තේරුම් ගැනීමට කියවා ඔබ කරන දේ තීරණය කරන්න. ඔබට ලොග් උපස්ථ ලබා ගැනීම ආරම්භ කර Fullනැවත යථා තත්ත්වයට පත්විය හැකිය.

වෙනත් හේතු තිබිය හැකි නමුත් මේවා වඩාත් සුලභ ය. මෙම පිළිතුර වඩාත් පොදු හේතු දෙකට කිමිදීමට පටන් ගන්නා අතර හේතු සහ හේතුව පිටුපස පසුබිම පිළිබඳ තොරතුරු මෙන්ම වෙනත් හේතු ගවේෂණය කරයි.

දීර් Answer පිළිතුර: ලොගය දිගටම වර්ධනය වීමට හේතු විය හැකි අවස්ථා මොනවාද? හේතු බොහොමයක් ඇත, නමුත් සාමාන්‍යයෙන් මෙම හේතු පහත දැක්වෙන රටාවන් දෙකකි: ප්‍රතිසාධන ආකෘති පිළිබඳ වරදවා වටහා ගැනීමක් හෝ දිගුකාලීන ගනුදෙනු තිබේ. විස්තර සඳහා කියවන්න.

ප්‍රධාන හේතුව 1/2: ප්‍රතිසාධන ආකෘති තේරුම් නොගැනීම

( තුළ සිටීම පූර්ණ මුදාගැනීම ප්රකාරය හා ගැනීම නොවේ ලොග් අමතර පිටපත් - මෙය වඩාත් පොදු හේතුව - මෙම ගැටලුව මුහුනදී සිටින අතිමහත් බහුතරය වේ. )

මෙම පිළිතුර SQL සේවාදායක ප්‍රතිසාධන ආකෘතිවල ගැඹුරු කිමිදීමක් නොවන අතර, ප්‍රතිසාධන ආකෘති පිළිබඳ මාතෘකාව මෙම ගැටළුවට ඉතා වැදගත් වේ.

SQL සේවාදායකයේ, ප්‍රතිසාධන ආකෘති තුනක් ඇත :

• Full,
• Bulk-Logged හා
• Simple.

අපි Bulk-Loggedදැන් නොසලකා හරිමු එය දෙමුහුන් ආකෘතියක් යැයි අපි වර්ග කරමු. මෙම ආකෘතියේ සිටින බොහෝ අය හේතුවක් ඇතුව සිටින අතර ප්‍රතිසාධන ආකෘති තේරුම් ගනී.

අප සැලකිලිමත් වන දෙදෙනා සහ ඔවුන්ගේ ව්‍යාකූලත්වය මෙම ගැටලුව ඇති පුද්ගලයින්ගෙන් බහුතරයකට හේතුව Simpleසහ Full.

මැදිහත් වීම: පොදුවේ ප්‍රතිසාධනය

ප්‍රතිසාධන ආකෘති ගැන කතා කිරීමට පෙර: පොදුවේ ප්‍රතිසාධනය ගැන කතා කරමු. ඔබට මෙම මාතෘකාව සමඟ වඩාත් ගැඹුරට යාමට අවශ්‍ය නම්, පෝල් රැන්ඩල්ගේ බ්ලොගය සහ ඔබට අවශ්‍ය පරිදි එහි බොහෝ ලිපි කියවන්න . මෙම ප්‍රශ්නය සඳහා:

1. බිඳ වැටීම / නැවත ආරම්භ
   කිරීම ගනුදෙනු ලොග් ගොනුවේ එක් අරමුණක් වන්නේ බිඳ වැටීම / නැවත ආරම්භ කිරීම ය . බිඳවැටීමකට හෝ නැවත ආරම්භ කිරීමට පෙර සිදු කරන ලද (ඉදිරියට පෙරළීම / නැවත කිරීම) සිදු කිරීම සහ බිඳවැටීමකින් හෝ නැවත ආරම්භ කිරීමෙන් පසුව ආරම්භ කරන ලද නමුත් අවසන් නොකළ වැඩ සඳහා (පෙරළීම / අහෝසි කිරීම). ගනුදෙනුවක් ආරම්භ වූ නමුත් කිසි විටෙකත් අවසන් නොවූ බව දැකීම ගනුදෙනු ලොගයේ කාර්යය වේ (ගනුදෙනුව සිදු වීමට පෙර පෙරළීම හෝ බිඳ වැටීම / නැවත ආරම්භ කිරීම සිදුවිය). එවැනි තත්වයක් තුළ සුවය ලැබීමේදී "හේයි .. මෙය කිසි විටෙකත් අවසන් වී නැත, එය නැවත පෙරළමු" යනුවෙන් පැවසීම ලොගයේ කාර්යය වේ . ඔබ යමක් අවසන් කර ඇති බවත් ඔබේ සේවාදායක යෙදුමට එය අවසන් වී ඇති බවත් (එය ඔබගේ දත්ත ගොනුවට තවම තද කර නොතිබුණද) දැකීම ලොගයේ කාර්යය වේ."හේයි .. මෙය සැබවින්ම සිදු විය, අපි එය ඉදිරියට පෙරළමු, යෙදුම් එය සිතන ආකාරයට සකස් කරමු" නැවත ආරම්භ කිරීමෙන් පසුව. දැන් තවත් බොහෝ දේ ඇති නමුත් එය ප්‍රධාන අරමුණයි.

2. ලක්ෂ්‍යයේ කාල ප්‍රතිසාධනය
   ගණුදෙනු ලොග් ගොනුවක අනෙක් අරමුණ වන්නේ දත්ත සමුදායක් තුළ ඇති “අපොයි” නිසා නියමිත වේලාවට යථා තත්ත්වයට පත්වීමේ හැකියාව අපට ලබා දීම හෝ දෘඩාංග අසමත්වීමකදී ප්‍රතිසාධන ලක්ෂ්‍යයක් සහතික කිරීමයි. දත්ත සමුදායක දත්ත සහ / හෝ ලොග් ගොනු සම්බන්ධ කිරීම. මෙම ගනුදෙනු ලොගයේ ප්‍රතිසාධනය සඳහා ආරම්භ කර අවසන් කර ඇති ගනුදෙනු වල වාර්තා තිබේ නම්, SQL සේවාදායකයට මෙම තොරතුරු භාවිතා කර ගැටළුවක් සිදුවීමට පෙර දත්ත ගබඩාවක් ලබා ගත හැකිය. නමුත් එය සැමවිටම අපට ලබා ගත හැකි විකල්පයක් නොවේ. එය ක්‍රියාත්මක කිරීම සඳහා අපගේ දත්ත සමුදාය නිවැරදි ප්‍රතිසාධන ආකෘතියක් තුළ තිබිය යුතු අතර, අපි ලොග් උපස්ථ ගත යුතුය .

ප්‍රතිසාධන ආකෘති

ප්‍රතිසාධන ආකෘති වෙත:

• සරල ප්‍රතිසාධන ආකෘතිය
  එබැවින් ඉහත හැඳින්වීමත් සමඟ Simple Recoveryපළමුව ආකෘතිය ගැන කතා කිරීම පහසුය . මෙම ආකෘතියේ දී, ඔබ SQL සේවාදායකයට මෙසේ කියයි: "ඔබේ ගනුදෙනු ලොග් ගොනුව බිඳවැටීම සහ නැවත යථා තත්ත්වයට පත් කිරීම සඳහා මම ඔබ සමඟ හොඳින් සිටිමි ..." (ඔබට ඇත්ත වශයෙන්ම එහි වෙනත් විකල්පයක් නොමැත. ACID ගුණාංග සොයා බලන්න, එය ඉක්මනින් අර්ථවත් විය යුතුය.) "... නමුත් එම බිඳවැටීම / නැවත යථා තත්ත්වයට පත් කිරීම සඳහා ඔබට එය තවදුරටත් අවශ්‍ය නොවන විට, ඉදිරියට ගොස් ලොග් ගොනුව නැවත භාවිතා කරන්න."

  SQL සේවාදායකය මෙම ඉල්ලීමට සරල ප්‍රතිසාධනයෙන් සවන් දෙන අතර එය බිඳවැටීම / නැවත ආරම්භ කිරීම සඳහා අවශ්‍ය තොරතුරු පමණක් තබා ගනී. දත්ත ගොනුවට (වැඩි හෝ අඩු) දත්ත දැඩි කර ඇති නිසා එය නැවත ලබා ගත හැකි බව SQL සේවාදායකයට සහතික වූ පසු, ened න කර ඇති දත්ත තවදුරටත් ලොගයේ අවශ්‍ය නොවන අතර එය කප්පාදු කිරීම සඳහා සලකුණු කර ඇත - එයින් අදහස් වන්නේ එය නැවත භාවිතා වන බවයි.

• සම්පුර්ණ ප්‍රතිසාධන මාදිලිය
  සමඟ Full Recovery, ඔබ SQL සේවාදායකයට කියන්නේ ඔබේ ලොග් ගොනුව පවතින තාක් කල් හෝ ලොග් උපස්ථයකින් ආවරණය වන නිශ්චිත ස්ථානයකට නිශ්චිත වේලාවකට යථා තත්ත්වයට පත් වීමට ඔබට අවශ්‍ය බවය. මෙම අවස්ථාවේදී SQL සේවාදායකය සරල ප්‍රතිසාධන මාදිලියේ ලොග් ගොනුව කප්පාදු කිරීම ආරක්ෂිත වන ස්ථානයට ළඟා වූ විට, එය එසේ නොකරනු ඇත. ඒ වෙනුවට එය ලොග් ගොනුව දිගටම වර්ධනය වීමට ඉඩ දෙන අතර සාමාන්‍ය තත්වයන් යටතේ ඔබ ලොග් උපස්ථයක් ගන්නා තෙක් (හෝ ඔබේ ලොග් ගොනු ධාවකයේ ඉඩ ප්‍රමාණවත් නොවන) එය දිගටම වර්ධනය වීමට ඉඩ දෙයි .

සරල සිට පූර්ණ දක්වා මාරුවීම සඳහා ගොචා ඇත.

මෙහි නීති සහ ව්‍යතිරේක පවතී. අපි ගැඹුරින් දිගුකාලීන ගනුදෙනු ගැන කතා කරමු.

නමුත් සම්පූර්ණ ප්‍රතිසාධන ප්‍රකාරය සඳහා මතක තබා ගත යුතු එක් අවවාදයක් මෙයයි: ඔබ Full Recoveryප්‍රකාරයට මාරුවුවද, නමුත් කිසි විටෙකත් ආරම්භක පූර්ණ උපස්ථයක් නොගන්නේ නම් , SQL සේවාදායකයා ඔබේ ඉල්ලීමට ගරු නොකරනු ඇත Full Recovery. ඔබ Simpleසම්පූර්ණ ප්‍රතිසාධන ආකෘතියට මාරුවී ඔබේ පළමු පියවර ගන්නා තෙක් ඔබේ ගනුදෙනු ලොගය දිගටම ක්‍රියාත්මක වේ Full Backup.

ලොග් උපස්ථ නොමැතිව සම්පූර්ණ ප්‍රතිසාධන ආකෘතිය නරක ය.

ඉතින්, පාලනයකින් තොරව ලොග් වර්ධනය සඳහා වඩාත් පොදු හේතුව කුමක්ද? පිළිතුර: කිසිදු ලොග් උපස්ථයක් නොමැතිව සම්පූර්ණ ප්‍රතිසාධන මාදිලියේ සිටීම.

මෙය සෑම විටම මිනිසුන්ට සිදු වේ.

මෙය එතරම් පොදු වැරැද්දක් වන්නේ ඇයි?

එය සැමවිටම සිදුවන්නේ ඇයි? මන්ද සෑම නව දත්ත ගබඩාවක්ම එහි ආරම්භක ප්‍රතිසාධන ආකෘති සැකසුම ලබා ගන්නේ ආදර්ශ දත්ත ගබඩාව දෙස බැලීමෙනි.

මාදිලියේ ආරම්භක ප්‍රතිසාධන ආකෘති සැකසුම සැමවිටම Full Recovery Model- යමෙකු එය වෙනස් කරන තුරු සහ හැර. එබැවින් ඔබට "පෙරනිමි ප්‍රතිසාධන ආකෘතිය" යැයි පැවසිය හැකිය Full. බොහෝ අය මේ ගැන නොදන්නා අතර ඔවුන්ගේ දත්ත සමුදායන් Full Recovery Modelකිසිදු ලොග් උපස්ථයක් නොමැතිව ක්‍රියාත්මක වන අතර එම නිසා ගනුදෙනු ලොග් ගොනුවක් අවශ්‍ය ප්‍රමාණයට වඩා විශාලය. ඔබේ සංවිධානය සහ එහි අවශ්‍යතා සඳහා ක්‍රියා නොකරන විට පෙරනිමි වෙනස් කිරීම වැදගත් වන්නේ මේ නිසා ය)

ලොග් උපස්ථ ඉතා අඩු ප්‍රමාණයක් සහිත සම්පූර්ණ ප්‍රතිසාධන ආකෘතිය නරක ය.

ලොග් උපස්ථ නිතර නිතර නොගැනීමෙන් ඔබටද මෙහි කරදරයක් විය හැකිය.
දිනකට ලොග් උපස්ථයක් ගැනීම හොඳ යැයි හැඟේ, එය යථා තත්වයට පත් කිරීම සඳහා අඩු ප්‍රතිස්ථාපන විධාන අවශ්‍ය වේ, නමුත් ඉහත සාකච්ඡාව මතකයේ තබා ගනිමින්, ඔබ ලොග් උපස්ථ ලබා ගන්නා තෙක් එම ලොග් ගොනුව දිගටම වර්ධනය වෙමින් වර්ධනය වේ.

මට අවශ්‍ය ලොග් උපස්ථ සංඛ්‍යාතය සොයා ගන්නේ කෙසේද?

ඔබේ ලොග් උපස්ථ සංඛ්‍යාතය කරුණු දෙකක් මතකයේ තබා ගත යුතුය:

1. ප්‍රතිසාධන අවශ්‍යතා - මෙය පළමුව විය යුතුය. ඔබේ ගනුදෙනු ලොගය නරක අතට හැරෙන විට හෝ ඔබේ ලොග් උපස්ථයට බලපාන බරපතල දූෂණයක් සිදුවුවහොත්, දත්ත කොපමණ ප්‍රමාණයක් අහිමි විය හැකිද? එම අංකය මිනිත්තු 10-15 ට වඩා වැඩි නොවේ නම්, ඔබ සෑම විනාඩි 10-15 කට වරක්, සාකච්ඡාවේ අවසානයට ලොග් උපස්ථය ගත යුතුය.
2. ලොග් වර්ධනය - එදින පහසුවෙන් ප්‍රතිනිර්මාණය කිරීමේ හැකියාව නිසා ඔබේ සංවිධානයට වැඩි දත්ත ප්‍රමාණයක් අහිමි වීම හොඳ නම්, ඔබට විනාඩි 15 කට වඩා අඩු වාර ගණනක් ලොග් උපස්ථයක් තිබීම හොඳ විය හැකිය. සෑම පැය 4 කට වරක් ඔබේ සංවිධානය හොඳ විය හැකිය. නමුත් ඔබ පැය 4 ක් තුළ කොපමණ ගනුදෙනු ජනනය කරනවාද යන්න සොයා බැලිය යුතුය. එම පැය හතර තුළ ලොගය දිගටම වර්ධනය වීමට ඉඩ දීමෙන් ලොග් ගොනුවක් විශාල වේ ද? එයින් අදහස් කරන්නේ ඔබේ ලොග් උපස්ථ සඳහා වැඩි කාලයක් ගතවේද?

ප්‍රධාන හේතුව 2/2: දිගුකාලීන ගනුදෙනු

( "මගේ ප්‍රතිසාධන ආකෘතිය හොඳයි! ලොගය තවමත් වර්ධනය වෙමින් පවතී! )

මෙය පාලනයකින් තොරව සහ පාලනයකින් තොරව ලොග් වර්ධනයට හේතුවක් විය හැකිය. ප්‍රතිසාධන මාදිලිය කුමක් වුවත් එය බොහෝ විට පැමිණෙන්නේ "නමුත් මම සිටින්නේ සරල ප්‍රතිසාධන මාදිලියේ - මගේ ලොගය තවමත් වර්ධනය වන්නේ ඇයි?!"

මෙහි හේතුව සරල ය: මා ඉහත විස්තර කළ පරිදි SQL මෙම ගනුදෙනු ලොගය ප්‍රතිසාධන අරමුණු සඳහා භාවිතා කරන්නේ නම්, එය ගනුදෙනුවක ආරම්භය දක්වා නැවත දැකිය යුතුය.

ඔබට ගනුදෙනුවක් තිබේ නම් එය බොහෝ කාලයක් ගත වේ නම් හෝ බොහෝ වෙනස්කම් සිදු කරයි නම්, විවෘත ගනුදෙනු වල තවමත් පවතින හෝ එම ගනුදෙනුව ආරම්භ වූ දින සිට ආරම්භ වී ඇති කිසිදු වෙනසක් සඳහා ලොග්ට මුරපොලෙහි කප්පාදු කළ නොහැක.

මෙයින් අදහස් කරන්නේ විශාල මකාදැමීමක්, එක් මකාදැමීමේ ප්‍රකාශයක පේළි මිලියන ගණනක් මකා දැමීම එක් ගනුදෙනුවක් වන අතර එම සම්පූර්ණ මකාදැමීම සිදු වන තුරු ලොගයට කිසිදු කැපීමක් කළ නොහැකි බවයි. තුළ Full Recovery Model, මෙම මකාදැමීම ලොග් වී ඇති අතර එය බොහෝ ලොග් වාර්තා විය හැකිය. නඩත්තු කවුළු තුළ දර්ශක ප්‍රශස්තිකරණ කටයුතු සමඟ එකම දේ. දුර්වල ගනුදෙනු කළමනාකරණය සහ විවෘත ගනුදෙනු දෙස බලා නොසිටීම ඔබට සහ ඔබේ ලොග් ගොනුවට සැබවින්ම හානියක් විය හැකි බවද එයින් අදහස් වේ.

මෙම දිගුකාලීන ගනුදෙනු පිළිබඳව මට කුමක් කළ හැකිද?

ඔබට මෙහි ඔබව බේරා ගත හැකිය:

• ඔබගේ නඩත්තු කිරීම හෝ දන්නා විශාල මෙහෙයුම් වැනි නරකම අවස්ථාව සඳහා ඔබගේ ලොග් ගොනුව නිසි ලෙස ගණනය කිරීම. ඔබ ඔබේ ලොග් ගොනුව වැඩෙන විට කිම්බර්ලි ට්‍රිප් විසින් මෙම මාර්ගෝපදේශය (සහ ඇය ඔබට යවන සබැඳි දෙක) වෙත අවධානය යොමු කළ යුතුය . නිවැරදි ප්‍රමාණය මෙහි ඉතා වැදගත් වේ.
• ඔබේ ගනුදෙනු භාවිතය නැරඹීම. ඔබගේ යෙදුම් සේවාදායකයේ ගනුදෙනුවක් ආරම්භ නොකර SQL සේවාදායකය සමඟ දීර් conversation සංවාදයක් ආරම්භ කර අවදානම දිගු වේලාවක් විවෘතව තබන්න.
• ඔබගේ ඩීඑම්එල් ප්‍රකාශවල ගම්‍ය වන ගනුදෙනු නැරඹීම . උදාහරණයක් ලෙස: UPDATE TableName Set Col1 = 'New Value'ගනුදෙනුවක්. මම එහි තැබුවේ නැත BEGIN TRAN, මට අවශ්‍ය නැත, එය තවමත් සිදු වූ විට ස්වයංක්‍රීයව සිදු වන එක් ගනුදෙනුවකි. එබැවින් පේළි විශාල සංඛ්‍යාවක මෙහෙයුම් සිදු කරන්නේ නම්, එම මෙහෙයුම් වඩාත් කළමනාකරණය කළ හැකි කැබලිවලට සම්බන්ධ කර නැවත යථා තත්ත්වයට පත්වීමට කාලය ලබා දෙන්න. නැතහොත් ඒ සමඟ කටයුතු කිරීමට සුදුසු ප්‍රමාණය සලකා බලන්න. නැතහොත් තොග පැටවුම් කවුළුවක් තුළ ප්‍රතිසාධන ආකෘති වෙනස් කිරීම පිළිබඳව සොයා බලන්න.

මෙම හේතු දෙක ලොග් නැව්ගත කිරීම සඳහා ද අදාළ වේද?

කෙටි පිළිතුර: ඔව්. දිගු පිළිතුර පහතින්.

ප්‍රශ්නය: "මම ලොග් නැව්ගත කිරීම භාවිතා කරමි, එබැවින් මගේ ලොග් උපස්ථ ස්වයංක්‍රීය වේ ... මම තවමත් ගනුදෙනු ලොග් වර්ධනය දකින්නේ ඇයි?"

පිළිතුර: කියවන්න.

ලොග් නැව්ගත කිරීම යනු කුමක්ද?

ලොග් නැව්ගත කිරීම යනු එය පෙනෙන ආකාරයටමයි - ඔබ ඩීආර් අරමුණු සඳහා ඔබේ ගනුදෙනු ලොග් උපස්ථ වෙනත් සේවාදායකයකට යවනු ලැබේ. යම් ආරම්භයක් ඇති නමුත් ඉන් පසුව ක්‍රියාවලිය තරමක් සරල ය:

• එක් සේවාදායකයක ලොගය උපස්ථ කිරීමට රැකියාවක්,
• එම ලොග් උපස්ථය පිටපත් කිරීමේ කාර්යයක් සහ
• ගමනාන්ත සේවාදායකයේ ( NORECOVERYහෝ STANDBY) ප්‍රතිසාධනයකින් තොරව එය ප්‍රතිස්ථාපනය කිරීමේ කාර්යයකි .

ඔබ සැලසුම් කර ඇති පරිදි දේවල් සිදු නොවන්නේ නම් ඒවා නිරීක්ෂණය කිරීමට සහ අනතුරු ඇඟවීමට සමහර රැකියා තිබේ.

සමහර අවස්ථා වලදී, ඔබට අවශ්‍ය වන්නේ ලොග් නැව්ගත කිරීම දිනකට එක් වරක් හෝ සෑම තෙවන දිනකටම හෝ සතියකට වරක් පමණි. ඒක හොඳයි. නමුත් ඔබ සියලු රැකියා වල (ලොග් උපස්ථ සහ පිටපත් කිරීමේ රැකියා ඇතුළුව) මෙම වෙනස සිදු කරන්නේ නම් එයින් අදහස් වන්නේ ඔබ ලොග් උපස්ථයක් ලබා ගැනීම සඳහා ඒ කාලය පුරාම බලා සිටින බවයි. එයින් අදහස් කරන්නේ ඔබට ලොග් බැකප් විශාල ප්‍රමාණයක් ලැබෙනු ඇති බවයි - මන්ද ඔබ ලොග් උපස්ථ නොමැතිව සම්පූර්ණ ප්‍රතිසාධන මාදිලියේ සිටින නිසා - සහ බොහෝ විට එයින් අදහස් කරන්නේ විශාල ලොග් ගොනුවක් හරහා පිටපත් කිරීමයි. ඔබ කළ යුත්තේ ප්‍රතිස්ථාපන කාර්යයේ කාලසටහන පමණක් වන අතර ලොග් උපස්ථ සහ පිටපත් නිතර නිතර සිදුවීමට ඉඩ දෙන්න, එසේ නොමැතිනම් මෙම පිළිතුරෙහි විස්තර කර ඇති පළමු නිකුතුවෙන් ඔබ පීඩා විඳිනු ඇත.

තත්ව කේත හරහා සාමාන්‍ය දෝශ නිරාකරණය

මේ දෙක හැර වෙනත් හේතු තිබේ, නමුත් මේවා වඩාත් සුලභ ය. හේතුව කුමක් වුවත්: මෙම පැහැදිලි කළ නොහැකි ලොග් වර්ධනයට / කප්පාදුවේ lack නතාවයට ඔබේ හේතුව විශ්ලේෂණය කර ඒවා මොනවාදැයි බැලීමට ඔබට ක්‍රමයක් තිබේ.

sys.databasesනාමාවලි දර්ශනය විමසීමෙන් ඔබේ ලොග් ගොනුව කප්පාදු කිරීම / නැවත භාවිතා කිරීම සඳහා රැඳී සිටීමට හේතුව විස්තර කරන තොරතුරු ඔබට දැකගත හැකිය.

නමින් තීරුව ඇත log_reuse_waitහේතුව කේතය ක බැලීම ID සහ සමග log_reuse_wait_descරැක හේතුව විස්තරයක් සමඟ තීරුව. යොමු කරන ලද පොත් වලින් මාර්ගගත ලිපියෙන් බහුතරයක් හේතු (ඔබ දැකීමට ඉඩ ඇති හේතු සහ අපට හේතු පැහැදිලි කළ හැකිය. අතුරුදහන් වූවන් භාවිතයෙන් තොර හෝ අභ්‍යන්තර භාවිතය සඳහා) රැඳී සිටීම පිළිබඳ සටහන් කිහිපයක් සමඟ ඇල අකුරු :

• 0 = කිසිවක් නැත
  එය පෙනෙන දේ .. බලා නොසිටිය යුතුය

• 1 = මුරපොල
  මුරපොලක් සිදුවන තෙක් බලා සිටීම. මෙය සිදුවිය යුතු අතර ඔබ හොඳින් විය යුතුය - නමුත් පසුකාලීන පිළිතුරු හෝ සංස්කරණයන් සඳහා මෙහි සොයා බැලීමට සමහර අවස්ථා තිබේ.

• 2 = ලොග් උපස්ථය
  ලොග් උපස්ථයක් සිදුවන තෙක් ඔබ බලා සිටී. එක්කෝ ඔබ ඒවා උපලේඛනගත කර ඇති අතර එය ඉක්මනින් සිදුවනු ඇත, නැතහොත් මෙහි විස්තර කර ඇති පළමු ගැටළුව ඔබට ඇති අතර එය නිවැරදි කරන්නේ කෙසේදැයි ඔබ දැන් දනී

• 3 = සක්‍රීය උපස්ථ හෝ ප්‍රතිස්ථාපනය
  දත්ත ගබඩාවේ උපස්ථ හෝ ප්‍රතිස්ථාපන ක්‍රියාවලිය ක්‍රියාත්මක වේ

• 4 = සක්‍රීය ගනුදෙනුව ලොගය උපස්ථ කිරීමට පෙර
  සක්‍රිය ගනුදෙනුවක් සම්පූර්ණ කළ යුතුය (එක්කෝ - ROLLBACKහෝ COMMIT). මෙම පිළිතුරෙහි විස්තර කර ඇති දෙවන හේතුව මෙයයි.

• 5 = දත්ත සමුදා
  දර්පණය එක්කෝ ඉහළ කාර්ය සාධනයක් සහිත දර්පණ තත්වයක් තුළ දර්පණයක් පිටුපසින් හෝ යම් ප්‍රමාදයක් යටතේ හෝ යම් හේතුවක් නිසා දර්පණය විරාමයක් ඇත

• 6 =
  අනුරූකරණය මෙයට හේතු විය හැකි අනුරූකරණයේ ගැටළු තිබිය හැකිය - ලොග් රීඩර් ඒජන්තයක් ක්‍රියාත්මක නොවීම, දත්ත සමුදායක් යැයි සිතමින් එය තවදුරටත් නොපවතින ලෙස සලකුණු කර ඇත. ඔබට මෙම හේතුව ද දැකිය හැකි අතර, එය ලොග් පා er කයා විසින් ගනුදෙනු පරිභෝජනය කරන ආකාරයටම, ඔබ නියම වේලාවට බලා සිටින නිසා එය සාමාන්‍ය දෙයකි

• 7 = දත්ත සමුදා ස්නැප්ෂොට් නිර්මාණය ඔබ දත්ත සමුදා සැණින් ඡායාරූපයක් නිර්මාණය
  කරමින් සිටී, සැණෙකින් ඡායාරූපයක් නිර්මාණය වන විට නියම මොහොත දෙස බැලුවහොත් ඔබට මෙය පෙනෙනු ඇත.

• 8 = ලොග් ස්කෑන්
  මෙය සදහටම ක්‍රියාත්මක වීම පිළිබඳ ගැටලුවක් මට තවම හමු වී නැත. ඔබ දිගු කාලයක් හා නිතර නිතර බැලුවහොත් මෙය සිදුවන බව ඔබට පෙනෙනු ඇත, නමුත් එය අධික ගනුදෙනු ලොග් වර්ධනයට හේතුවක් නොවිය යුතුය, මා දැක ඇති.

• 9 = සැමවිටම ලබා ගත හැකි කණ්ඩායම් ද්විතියික අනුරුව මෙම දත්ත ගබඩාවේ ගනුදෙනු ලොග් වාර්තා අනුරූප ද්විතියික දත්ත ගබඩාවකට යොදවයි. තවමත් පැහැදිලි විස්තරය ගැන ..

වැඩිපුරම ඡන්දය ප්‍රකාශ කළ යෝජනාව ඇතුළුව, ස්ටැක් පිටාර ගැලීම පිළිබඳ කිසිදු පිළිතුරක් ගැන මම සෑහීමකට පත් නොවන නිසාත්, මයික්ගේ පිළිතුරට පිළිතුරු නොදෙන කාරණා කිහිපයක් ඇති නිසාත්, මම සිතුවෙමි මගේ ආදානය ද මෙහි ඇත. මම මෙම පිළිතුරේ පිටපතක් ද එහි තැබුවෙමි.

ලොග් ගොනුවක් කුඩා කිරීම සැබවින්ම ඔබ නැවත සිදුවනු ඇතැයි අපේක්ෂා නොකරන අනපේක්ෂිත වර්ධනයක් ඇති වූ අවස්ථා සඳහා වෙන් කළ යුතුය. ලොග් ගොනුව නැවත එකම ප්‍රමාණයට වර්ධනය වේ නම්, එය තාවකාලිකව හැකිලීමෙන් බොහෝ දේ ඉටු නොවේ. දැන්, ඔබේ දත්ත ගබඩාවේ ප්‍රතිසාධන අරමුණු මත පදනම්ව, ඔබ ගත යුතු ක්‍රියාමාර්ග මේවාය.

පළමුව, සම්පූර්ණ උපස්ථයක් ගන්න

යමක් වැරදුනහොත් එය යථා තත්වයට පත් කළ හැකි බවට සහතික නොකර ඔබේ දත්ත ගබඩාවේ කිසිඳු වෙනසක් නොකරන්න.

ඔබ නියමිත වේලාවට යථා තත්ත්වයට පත්වීම ගැන සැලකිලිමත් වන්නේ නම්

(සහ නියමිත වේලාවට යථා තත්ත්වයට පත්වීමෙන්, මම අදහස් කරන්නේ පූර්ණ හෝ අවකල්‍ය උපස්ථයක් හැර වෙනත් ඕනෑම දෙයකට නැවත පැමිණීමට හැකිවීම ගැන ඔබ සැලකිලිමත් වන බවයි.)

ඔබගේ දත්ත සමුදාය FULLප්‍රතිසාධන ප්‍රකාරයේදී විය හැක. එසේ නොවේ නම්, එය එසේ බවට වග බලා ගන්න:

ALTER DATABASE yourdb SET RECOVERY FULL;

ඔබ නිතිපතා සම්පූර්ණ උපස්ථ ලබා ගත්තද, ඔබ ලොග් උපස්ථයක් සිදු කරන තුරු ලොග් ගොනුව වර්ධනය වී වර්ධනය වේ - මෙය ඔබේ ආරක්ෂාව සඳහා මිස අනවශ්‍ය ලෙස ඔබේ තැටියේ ආහාරයට නොගැනීමට. ඔබගේ ප්‍රතිසාධන අරමුණු අනුව ඔබ නිතරම මෙම ලොග් උපස්ථ සිදු කළ යුතුය. නිදසුනක් වශයෙන්, ව්‍යසනයකදී ඔබට විනාඩි 15 කට නොඅඩු දත්ත අහිමි කර ගත හැකි යැයි පවසන ව්‍යාපාර රීතියක් ඔබට තිබේ නම්, සෑම විනාඩි 15 කට වරක්ම ලොගය උපස්ථ කරන රැකියාවක් ඔබට තිබිය යුතුය. වර්තමාන වේලාව මත පදනම්ව කාලරාමුගත ගොනු නාම ජනනය කරන ස්ක්‍රිප්ටයක් මෙන්න (නමුත් නඩත්තු සැලසුම් ආදියෙන් ඔබට මෙය කළ හැකිය. නඩත්තු සැලසුම් වල හැකිලීමේ විකල්ප කිසිවක් තෝරා නොගන්න, ඒවා භයානක ය).

DECLARE @path NVARCHAR(255) = N'\\backup_share\log\yourdb_' 
  + CONVERT(CHAR(8), GETDATE(), 112) + '_'
  + REPLACE(CONVERT(CHAR(8), GETDATE(), 108),':','')
  + '.trn';

BACKUP LOG foo TO DISK = @path WITH INIT, COMPRESSION;

\\backup_share\වෙනස් යටි ගබඩා උපාංගයක් නියෝජනය කරන වෙනත් යන්ත්‍රයක තිබිය යුතු බව සලකන්න . මේවා එකම යන්ත්‍රයකට (හෝ එකම යටි තැටි භාවිතා කරන වෙනත් යන්ත්‍රයකට හෝ එකම භෞතික ධාරකයේ ඇති වෙනත් වීඑම් එකකට) උපස්ථ කිරීම සැබවින්ම ඔබට උදව් නොකරයි, මන්ද යන්ත්‍රය පුපුරා ගියහොත් ඔබට ඔබේ දත්ත ගබඩාව අහිමි වී ඇත සහ එහි උපස්ථ. ඔබගේ ජාල යටිතල ව්‍යුහය මත පදනම්ව, එය දේශීයව උපස්ථ කිරීමට වැඩි තේරුමක් ඇති අතර පසුව ඒවා තිරය පිටුපස වෙනත් ස්ථානයකට මාරු කරයි; කෙසේ වෙතත්, ඔබට හැකි ඉක්මනින් ඒවා ප්‍රාථමික දත්ත සමුදා යන්ත්‍රයෙන් ඉවත් කිරීමට අවශ්‍යය.

දැන්, ඔබ නිතිපතා ලොග් උපස්ථ ධාවනය කළ පසු, ලොග් ගොනුව මේ වන විට පුපුරවා හරින ඕනෑම දෙයකට වඩා සාධාරණ දෙයකට හැකිලීම සාධාරණ විය යුතුය. ලොග් ගොනුව 1 MB වන තෙක් නැවත නැවතත් ධාවනය වීම මෙයින් අදහස් නොකෙරේ SHRINKFILE- ඔබ නිතරම ලොගය උපස්ථ කරගත්තද, සිදුවිය හැකි සමගාමී ගනුදෙනු වල එකතුවට එය තවමත් ඉඩ දිය යුතුය. SQL සේවාදායකයට ලිපිගොනු ශුන්‍ය කළ යුතු බැවින් (ක්ෂණික ගොනු ආරම්භ කිරීම සක්‍රිය කර ඇති විට දත්ත ගොනු මෙන් නොව), සහ මෙය සිදු වන විට පරිශීලක ගනුදෙනු බලා සිටිය යුතුය. ඔබට මෙම වර්ධනය-හැකිලීම-වැඩීම-හැකිලීමේ පුරුද්ද හැකිතාක් අඩු කිරීමට අවශ්‍ය වන අතර, ඔබේ පරිශීලකයින් ඒ සඳහා මුදල් ගෙවීමට ඔබට අවශ්‍ය නැත.

හැකිලීමට පෙර ඔබට ලොගය දෙවරක් උපස්ථ කිරීමට අවශ්‍ය විය හැකි බව සලකන්න (ස්තූතියි රොබට්).

එබැවින්, ඔබේ ලොග් ගොනුව සඳහා ප්‍රායෝගික ප්‍රමාණයක් ඉදිරිපත් කළ යුතුය. ඔබේ පද්ධතිය ගැන වැඩි යමක් නොදැන මෙහි ඇති කිසිවෙකුට ඔබට එය පැවසිය නොහැක, නමුත් ඔබ නිතරම ලොග් ගොනුව හැකිලෙමින් එය නැවත වර්ධනය වෙමින් තිබේ නම්, හොඳ දිය සලකුණක් එය තිබූ විශාලතම ප්‍රමාණයට වඩා 10-50% වැඩි විය හැකිය. . එය 200 MB දක්වා වන බව කියමු, පසුව ඔබට අවශ්‍ය ඕනෑම ස්වයංක්‍රීය වර්ධන සිදුවීම් 50 MB විය යුතුය, එවිට ඔබට ලොග් ගොනු ප්‍රමාණය මේ ආකාරයෙන් සකස් කළ හැකිය:

USE [master];
GO
ALTER DATABASE Test1 
  MODIFY FILE
  (NAME = yourdb_log, SIZE = 200MB, FILEGROWTH = 50MB);
GO

ලොග් ගොනුව දැනට> 200 MB නම්, ඔබට මෙය පළමුව ධාවනය කිරීමට අවශ්‍ය විය හැකි බව සලකන්න:

USE yourdb;
GO
DBCC SHRINKFILE(yourdb_log, 200);
GO

නියමිත වේලාවට යථා තත්ත්වයට පත්වීම ගැන ඔබ තැකීමක් නොකරන්නේ නම්

මෙය පරීක්ෂණ දත්ත ගබඩාවක් නම්, සහ නියමිත වේලාවට යථා තත්ත්වයට පත්වීම ගැන ඔබ තැකීමක් නොකරන්නේ නම්, ඔබේ දත්ත සමුදාය SIMPLEප්‍රතිසාධන ප්‍රකාරයේ ඇති බවට ඔබ සහතික විය යුතුය .

ALTER DATABASE yourdb SET RECOVERY SIMPLE;

දත්ත සමුදාය SIMPLEප්‍රතිසාධන මාදිලියේ තැබීමෙන් සියලු ගනුදෙනු පිළිබඳ වාර්තාවක් තබා ගැනීම සඳහා වර්ධනය වීම වෙනුවට SQL සේවාදායකය ලොග් ගොනුවේ කොටස් නැවත භාවිතා කිරීමට වග බලා ගනී (අත්‍යවශ්‍යයෙන්ම අක්‍රීය ගනුදෙනු ඉවත් කිරීම) ( FULLඔබ ලොගය උපස්ථ කරන තෙක් ප්‍රතිසාධනය වැනි ). CHECKPOINTසිදුවීම් ලොගය පාලනය කිරීමට උපකාරී වන අතර ඔබ CHECKPOINTs අතර ටී-ලොග් ක්‍රියාකාරකම් විශාල ප්‍රමාණයක් ජනනය නොකරන්නේ නම් එය වර්ධනය වීමට අවශ්‍ය නොවන බවට වග බලා ගන්න .

ඊළඟට, මෙම ලොග් වර්ධනය සැබවින්ම සිදුවී ඇත්තේ අසාමාන්‍ය සිදුවීමක් නිසා යැයි කියන්න (එනම්, වාර්ෂික වසන්තය පිරිසිදු කිරීම හෝ ඔබේ විශාලතම දර්ශක නැවත ගොඩනැඟීම), සාමාන්‍ය එදිනෙදා භාවිතය නිසා නොවේ. ඔබ ලොග් ගොනුව හාස්‍යජනක ලෙස කුඩා ප්‍රමාණයකට හැකිලී ඇත්නම් සහ ඔබේ සාමාන්‍ය ක්‍රියාකාරකම් වලට සරිලන සේ SQL සේවාදායකයට එය නැවත වර්ධනය කළ යුතු නම්, ඔබ ලබාගත්තේ කුමක්ද? ඔබ නිදහස් කළ තැටි අවකාශය තාවකාලිකව පමණක් භාවිතා කිරීමට ඔබට හැකි වූවාද? ඔබට ක්ෂණික විසඳුමක් අවශ්‍ය නම්, ඔබට පහත සඳහන් දෑ ක්‍රියාත්මක කළ හැකිය:

USE yourdb;
GO
CHECKPOINT;
GO
CHECKPOINT; -- run twice to ensure file wrap-around
GO
-- 200 MB
DBCC SHRINKFILE(yourdb_log, 200);
GO

එසේ නොමැතිනම් සුදුසු ප්‍රමාණයක් සහ වර්ධන වේගයක් නියම කරන්න. ලක්ෂ්‍ය කාල ප්‍රතිසාධන නඩුවේ උදාහරණයට අනුව, ඔබට එකම කේතය සහ තර්කනය භාවිතා කර ගොනු විශාලත්වය සුදුසු දැයි තීරණය කර සාධාරණ ස්වයංක්‍රීය වර්ධන පරාමිතීන් සැකසිය හැකිය.

ඔබට කිරීමට අවශ්‍ය නැති සමහර දේවල්

• TRUNCATE_ONLYවිකල්පය සමඟ ලොගය උපස්ථ කර ඉන්පසුSHRINKFILE . එකක් සඳහා, මෙම TRUNCATE_ONLYවිකල්පය අවලංගු කර ඇති අතර එය SQL සේවාදායකයේ වත්මන් අනුවාද වල තවදුරටත් නොපවතී. දෙවනුව, ඔබ FULLප්‍රතිසාධන ආකෘතියේ සිටී නම්, මෙය ඔබගේ ලොග් දාමය විනාශ කරන අතර නව පූර්ණ උපස්ථයක් අවශ්‍ය වේ.

• දත්ත සමුදාය වෙන් කරන්න, ලොග් ගොනුව මකා දමා නැවත අමුණන්න . මෙය කෙතරම් භයානක විය හැකිදැයි මට අවධාරණය කළ නොහැක. ඔබේ දත්ත ගබඩාව නැවත ඉහළට නොඑනු ඇත, එය සැකකරුවෙකු ලෙස මතු විය හැකිය, ඔබට උපස්ථයකට ආපසු යාමට සිදු විය හැකිය (ඔබට එකක් තිබේ නම්) යනාදිය.

• "හැකිලෙන දත්ත සමුදාය" විකල්පය භාවිතා කරන්න . DBCC SHRINKDATABASEඒ සඳහා නඩත්තු සැලසුම් විකල්පය නරක අදහස් වේ, විශේෂයෙන් ඔබට අවශ්‍ය වන්නේ ලොග් ගැටළුවක් විසඳීමට පමණි. ඔබට අවශ්‍ය පරිදි සකස් කිරීමට අවශ්‍ය ගොනුව ඉලක්ක කර ස්වාධීනව සකස් කරන්න, භාවිතා කරමින් DBCC SHRINKFILEහෝ ALTER DATABASE ... MODIFY FILE(ඉහත උදාහරණ).

• ලොග් ගොනුව 1 MB දක්වා හැකිලෙන්න . මෙය සිත් ඇදගන්නා සුළු පෙනුමක් ඇති හෙයින්, ඒයි, SQL සේවාදායකය මට එය යම් යම් අවස්ථා වලදී කිරීමට ඉඩ දෙන අතර, එය නිදහස් කරන සියලු අවකාශය දෙස බලයි! ඔබගේ දත්ත සමුදාය කියවීමට පමණක් නොව (එය ඔබ භාවිතා කරන ලෙස සලකුණු කළ යුතුය ALTER DATABASE), මෙය නියත වශයෙන්ම බොහෝ අනවශ්‍ය වර්ධන සිදුවීම් වලට තුඩු දෙනු ඇත, මන්ද ප්‍රතිසාධන ආකෘතිය නොසලකා ලොග් වත්මන් ගනුදෙනු සඳහා ඉඩ ලබා දිය යුතු බැවිනි. තාවකාලිකව එම අවකාශය නිදහස් කිරීමේ තේරුම කුමක්ද, SQL සේවාදායකයට එය සෙමින් හා වේදනාකාරී ලෙස ආපසු ලබා ගත හැකිය.

• දෙවන ලොග් ගොනුවක් සාදන්න . මෙය ඔබගේ තැටිය පුරවා ඇති ධාවකය සඳහා තාවකාලිකව සහනයක් ලබා දෙනු ඇත, නමුත් මෙය හරියට සිදුරු සහිත පෙනහළු පටි ආධාරයෙන් සවි කිරීමට උත්සාහ කිරීමක් වැනිය. තවත් විභව ගැටළුවක් එකතු කරනවා වෙනුවට ඔබ ගැටළු සහිත ලොග් ගොනුව සමඟ කෙලින්ම කටයුතු කළ යුතුය. සමහර ගනුදෙනු ලොග් ක්‍රියාකාරකම් වෙනත් ධාවකයකට හරවා යැවීම හැරුණු විට, දෙවන ලොග් ගොනුවක් ඇත්ත වශයෙන්ම ඔබ වෙනුවෙන් කිසිවක් නොකරයි (දෙවන දත්ත ගොනුවක් මෙන් නොව), මන්දයත් වරකට එක් ගොනුවක් පමණක් භාවිතා කළ හැකි බැවිනි. පෝල් රැන්ඩල් විසින් පසුකාලීනව බහු ලොග් ලිපිගොනු ඔබට දෂ්ට කළ හැක්කේ මන්දැයි පැහැදිලි කරයි .

ක්‍රියාශීලී වන්න

ඔබගේ ලොග් ගොනුව කුඩා ප්‍රමාණයකට හැකිලී එය තනිවම කුඩා අනුපාතයකට ස්වයංක්‍රීයව වැඩීමට ඉඩ දෙනවා වෙනුවට, එය තරමක් විශාල ප්‍රමාණයකට සකසන්න (ඔබේ විශාලතම සමගාමී ගනුදෙනු සමූහයේ එකතුවට සරිලන පරිදි) සහ සාධාරණ ස්වයංක්‍රීය වර්ධනයක් සකසන්න පසුබෑමක් ලෙස සැකසීම, එමඟින් තනි ගනුදෙනු තෘප්තිමත් කිරීම සඳහා කිහිප වතාවක් වර්ධනය වීමට අවශ්‍ය නොවන අතර සාමාන්‍ය ව්‍යාපාර මෙහෙයුම් වලදී එය වර්ධනය වීමට සාපේක්ෂව දුර්ලභ වනු ඇත.

මෙහි ඇති නරකම සැකසුම් වන්නේ 1 MB වර්ධනයක් හෝ 10% ක වර්ධනයකි. විනෝදජනකයි, මේවා SQL සේවාදායකයේ පෙරනිමි වේ (මම පැමිණිලි කර ඇති අතර කිසිදු ප්‍රයෝජනයක් නැති ලෙස ඉල්ලා සිටිමි ) - දත්ත ගොනු සඳහා 1 MB, සහ ලොග් ගොනු සඳහා 10%. මෙම දිනය හා වයස තුළ කලින් තිබූ දේ ඉතා කුඩා වන අතර දෙවැන්න සෑම විටම දිගු හා දිගු සිදුවීම් වලට මග පාදයි (කියන්න, ඔබේ ලොග් ගොනුව 500 MB වේ, පළමු වර්ධනය 50 MB වේ, ඊළඟ වර්ධනය 55 MB වේ, ඊළඟ වර්ධනය 60 MB වේ , ආදිය. - සහ මන්දගාමී I / O මත, මාව විශ්වාස කරන්න, ඔබ මෙම වක්‍රය සැබවින්ම දකිනු ඇත).

වැඩිදුර කීයවීම

කරුණාකර මෙහි නවත්වන්න එපා; ලොග් ලිපිගොනු හැකිලීම පිළිබඳව ඔබ දකින බොහෝ උපදෙස් සහජයෙන්ම නරක සහ විනාශකාරී විය හැකි අතර, තැටි අවකාශය නිදහස් කිරීමට වඩා දත්ත අඛණ්ඩතාව ගැන වැඩි සැලකිල්ලක් දක්වන සමහර අය සිටිති.

• 2009 දී මා විසින් ලියන ලද බ්ලොග් සටහනක්, "ලොග් ගොනුව හැකිලෙන ආකාරය මෙන්න" යන ලිපි කිහිපයක් දුටු විට පළ වේ.

• මීට වසර හතරකට පෙර බ්‍රෙන්ට් ඕසාර් විසින් ලියන ලද බ්ලොග් සටහනක්, විවිධ සම්පත් වෙත යොමු කරමින්, SQL සේවාදායක සඟරා ලිපියකට ප්‍රතිචාර වශයෙන් ප්‍රකාශයට පත් නොකළ යුතුව තිබුණි .

• පෝල් රැන්ඩල්ගේ බ්ලොග් සටහනක් ටී-ලොග් නඩත්තු කිරීම වැදගත් වන්නේ ඇයි සහ ඔබේ දත්ත ගොනු හැකිලීමට නොයන්නේ ඇයිද යන්න පැහැදිලි කරයි .

• මයික් වොල්ෂ්ට ඉහළ පිළිතුරක් ඇත, ඇත්ත වශයෙන්ම, මෙම කරුණු සමහරක් ආවරණය කරයි, ඔබේ ලොග් ගොනුව වහාම හැකිලීමට ඔබට නොහැකි වීමට හේතු ද ඇතුළුව .

ඔබගේ ලොග් ගොනුවේ අන්තර්ගතය ද ඔබට දැක ගත හැකිය. එය සිදු කිරීම සඳහා, ඔබට ApexSQL ලොග්fn_dblog වැනි ලේඛනගත නොකළ හෝ ගනුදෙනු ලොග් කියවනය භාවිතා කළ හැකිය .

එහෙත් එය සමස්ත ප්රතිසංවිධානය වෙන්නේ නෑ, නමුත් එය සියලු DML සහ විවිධ DDL සිද්ධීන් පෙන්නුම්: ALTER, CREATE, DROP, කොකා සක්රීය / අක්රීය, ප්රතිපාදන / අවලංගු කරන්න අවසර, වස්තුව ප්රතිනම්කෙරුම්.

වියාචනය: මම ApexSQL සඳහා සහායක ඉංජිනේරුවරයෙකු ලෙස වැඩ කරමි

ලොග් වර්ධනය වී තැටිය පුරවන සියලුම ඩීබීඒ සඳහා පාහේ මුහුණ දෙන ගැටළුව මෙයයි.

Log ගනුදෙනු ලොගය මෙතරම් විශාල වීමට හේතු මොනවාද?

1. දිගු ක්‍රියාකාරී ගනුදෙනුව
2. දර්ශකය නැවත ගොඩ නැගීම, නැවත සංවිධානය කිරීම, තොග ඇතුළත් කිරීම, මකා දැමීම වැනි ඉහළ ල ging ු-සටහන් ගනුදෙනු.
3. ලොග් එක රඳවාගෙන ඇති ලොග් අවකාශය මුදා හැරීමට ඉඩ නොදෙන, ප්‍රතිවර්තනය, දර්පණය වැනි ඕනෑම එච්.ඒ.

Log මගේ ලොග් ගොනුව එතරම් විශාල වන්නේ ඇයි?

කප්පාදු කිරීමෙන් ල logs ු-සටහන් තබා ගන්නේ කුමක් දැයි දැන ගැනීමට වගුවේ ඇති log_reuse_wait_desසී තීරුව පරීක්ෂා කරන්න sys.databases:

select name, log_reuse_wait_desc 
from sys.databases

Problem මෙම ගැටළුව ඇතිවීම වලක්වා ගත හැකි ක්‍රම මොනවාද?

ල logs ු-සටහන් නැවත භාවිතා කිරීමෙන් වළක්වන යමක් නොමැති නම් ලොග් උපස්ථ මඟින් ලොග් වර්ධනය පාලනය කිරීමට උපකාරී වේ.

The මූලික හේතුව සමඟ මා සොයා බලා මගේ ගනුදෙනු ලොග් ගොනුව සෞඛ්‍ය සම්පන්න ප්‍රමාණයකට දැමීමට අවශ්‍ය වූ විට මා කුමක් කළ යුතුද?

ඇත්ත වශයෙන්ම එයට හේතුව කුමක්දැයි ඔබ හඳුනාගෙන තිබේ නම් පහත පිටුවෙහි විස්තර කර ඇති පරිදි එය නිවැරදි කිරීමට උත්සාහ කරන්න.

https://www.brentozar.com/archive/2016/03/my-favor-system-column-log_reuse_night_desc/

අසාමාන්‍ය තත්වයක් හැරෙන්නට නිසි ලොග් උපස්ථ උපලේඛනගත කිරීම ලොග් වර්ධනය සමඟ කටයුතු කිරීමේ හොඳම ක්‍රමය වේ.