डाटाबेस भ्रष्टाचार हरेक SQL Server प्रशासकको दुःस्वप्न। जब महत्वपूर्ण व्यापार डेटा पहुँचयोग्य वा अविश्वसनीय हुन्छ, cost विनाशकारी हुन सक्छ। यो विस्तृत गाइडले डाटाबेस स्वास्थ्य कायम राख्न र भ्रष्टाचार रोक्न DBCC CHECKDB प्रयोग गर्ने बारे जान्न आवश्यक पर्ने सबै कुराहरू समेट्छ, साथै मानक उपकरणहरू पर्याप्त नभएको बेलाको लागि उन्नत रिकभरी समाधानहरू पनि समावेश गर्दछ।
४. को महत्व SQL Server डाटाबेस स्वास्थ्य
१.१ के डाटाबेस भ्रष्टाचार Costव्यवसायहरू
आज, मost व्यवसायहरूले आफ्नो महत्वपूर्ण डेटा डाटाबेसमा भण्डारण गर्छन्। जब डेटाबेस भ्रष्टाचार हुन्छ, परिणामहरू विनाशकारी हुन्छन्:
- आर्थिक घाटा डेटा नोक्सानीका कारण वार्षिक औसत $२.३ मिलियन, जसमा हार्डवेयर विफलता र भ्रष्टाचार मुख्य कारणहरू हुन् (EMC Corporation)
- व्यवसाय बन्द हुने दरहरू हार्डवेयर विफलताका कारण डेटा नोक्सान भोगिरहेका ५०% साना व्यवसायहरू दुई वर्ष भित्रै व्यवसायबाट बाहिरिने देखाउँछन्, जबकि विनाशकारी डेटा नोक्सान भएका ९४% व्यवसायहरू बाँच्न सक्दैनन्।
- डेटा भ्रष्टाचार आवृत्ति वार्षिक रूपमा २०% मिसन-क्रिटिकल अनुप्रयोगहरूलाई असर गर्छ, जसले गर्दा व्यापार निरन्तरतामा अवरोध आउँछ (गार्टनर अनुसन्धान)
- हार्डवेयरसँग सम्बन्धित भ्रष्टाचार हार्ड ड्राइभ क्र्यास र सिस्टम फेलियर्स मार्फत हुने सबै डाटा हराउने घटनाहरूको ६७% हो, जसमा ४०% डाटा हराउने प्रत्यक्ष रूपमा हार्डवेयर खराबीका कारण हुन्छ।
- सफ्टवेयर भ्रष्टाचार गosts गम्भीरता र दायरा अनुसार हजारौंदेखि लाखौं डलरसम्मको दायरा, ८२% व्यवसायहरूले अनियोजित बन्दको सामना गरिरहेका छन् जहाँ भ्रष्टाचार प्रमुख कारण थियो।
१.२ नियमित स्वास्थ्य जाँच किन महत्वपूर्ण छ
सम्भावित रोगहरू चाँडै पत्ता लगाउन मानिसहरूलाई नियमित स्वास्थ्य जाँचको आवश्यकता पर्दछ। त्यस्तै गरी, डाटाबेसहरूलाई पनि नियमित स्वास्थ्य जाँचको आवश्यकता पर्दछ:
- सम्भावित भ्रष्टाचारलाई चाँडै पत्ता लगाउनुहोस् र तुरुन्तै सम्हाल्नुहोस्, जसले गर्दा समस्याहरू गम्भीर र व्यापक हुनबाट रोकिन्छन्, जसले व्यवसायको लागि विनाशकारी परिणामहरू निम्त्याउन सक्छ।
- डाटाबेस इष्टतम कार्यसम्पादनमा सञ्चालन भएको सुनिश्चित गर्नुहोस्।
- सीost डाटाबेस प्रकोप पछि प्रतिक्रियाशील डाटा रिकभरीको तुलनामा सक्रिय डाटाबेस स्वास्थ्य जाँचको संख्या धेरै कम छ।
१.३ डाटाबेस इन्टिग्रिटी कमाण्डहरूको परिचय
SQL Server डाटाबेस स्वास्थ्य कायम राख्नको लागि धेरै निर्मित आदेशहरू प्रदान गर्दछ, जसमा DBCC CHECKDB एम को रूपमा सेवा गर्दैost व्यापक अखण्डता जाँच उपकरण उपलब्ध छ। यी आदेशहरूले तपाईंको डाटाबेस संरचनाको विभिन्न पक्षहरू प्रमाणित गर्न सँगै काम गर्छन्, व्यक्तिगत तालिकाहरूदेखि सम्पूर्ण डाटाबेस स्थिरतासम्म, तपाईंको डाटा सुरक्षित र पहुँचयोग्य राख्ने पूर्ण मर्मत रणनीति बनाउँछन्।
२. DBCC CHECKDB भनेको के हो?
DBCC CHECKDB is SQL Serverडाटाबेसको अखण्डता प्रमाणित गर्न र भ्रष्टाचारका समस्याहरू पहिचान गर्नको लागि यो प्राथमिक उपकरण हो।
- यो T-SQL कथन हो, GUI उपकरण होइन।
- तपाईं यसलाई सामान्य विधिहरू मार्फत कार्यान्वयन गर्न सक्नुहुन्छ, जस्तै SQL Server व्यवस्थापन स्टुडियो (SSMS), SQL Server एजेन्ट, SQLCMD, आदि।
२.१ तपाईंको डाटाबेसमा CHECKDB ले वास्तवमा के जाँच गर्छ
जब तपाईं DBCC CHECKDB चलाउनुहुन्छ, आदेशले तपाईंको डाटाबेस संरचनामा धेरै प्रमाणीकरण तहहरू प्रदर्शन गर्दछ:
- पृष्ठ चेकसम प्रमाणीकरण भौतिक भ्रष्टाचार र हार्डवेयर-सम्बन्धित समस्याहरू पत्ता लगाउन
- अनुक्रमणिका स्थिरता प्रमाणीकरण उचित डेटा पुन: प्राप्ति र क्वेरी प्रदर्शन सुनिश्चित गर्न
- आवंटन संरचना जाँचहरू सही ठाउँ प्रयोग र पृष्ठ विनियोजन पुष्टि गर्न
- सन्दर्भात्मक अखण्डता परीक्षण सम्बन्धित तालिकाहरू र विदेशी कुञ्जी सम्बन्धहरू बीच
- प्रणाली तालिका स्थिरता प्रमाणीकरण सुनिश्चित गर्न SQL Serverआन्तरिक मेटाडेटा विश्वसनीय रहन्छ।
- डेटा पृष्ठ लिंकेज प्रमाणीकरण उचित पृष्ठ श्रृंखला अखण्डता पुष्टि गर्न
- डाटाबेस स्कीमा स्थिरता वस्तु परिभाषा र निर्भरताहरू मान्य गर्न
यी व्यापक जाँचहरूले प्रयोगकर्ता डेटा र प्रणाली संरचना दुवैलाई समेट्छन्, जसले गर्दा तपाईंको डाटाबेसको स्वास्थ्य स्थितिमा पूर्ण दृश्यता प्रदान गर्दछ।
३. DBCC CHECKDB चलाउँदै: चरण-दर-चरण
२.१ आवश्यक शर्तहरू
कुनै पनि DBCC CHECKDB अपरेशन कार्यान्वयन गर्नु अघि तल चेकलिस्ट दिइएको छ:
- डाटाबेस ब्याकअप पूरा गर्नुहोस् - भ्रष्टाचार पत्ता लागेमा वा मर्मत कार्यहरू आवश्यक परेमा तपाईंको सुरक्षा जालको रूपमा अखण्डता जाँचहरू चलाउनु अघि पूर्ण ब्याकअप सिर्जना गर्नुहोस्।
- उचित अनुमतिहरू - DBCC CHECKDB आदेशहरू कार्यान्वयन गर्न तपाईंलाई sysadmin वा db_owner अनुमतिहरू चाहिन्छ।
- पर्याप्त प्रणाली स्रोतहरू:
- मेमोरी: डाटाबेस आकारको २५%
- Tempdb स्पेस: डाटाबेस आकारको १०-१५%
- CPU: मर्मतसम्भारको समयमा ५०-७०% उपलब्धता
- I/O: भारी पढ्ने कार्यहरू अपेक्षा गर्नुहोस्
- डाटाबेस पहुँचयोग्यता - तपाईंको डाटाबेस पहुँचयोग्य छ र प्रतिबन्धित अवस्थामा छैन भनी प्रमाणित गर्नुहोस्, किनकि CHECKDB लाई सबै डाटाबेस पृष्ठहरूमा पढ्ने पहुँच आवश्यक पर्दछ।
3.2 आधारभूत आदेश
उनीहरुost आधारभूत DBCC CHECKDB कमाण्डमा तीन सामान्य भिन्नताहरू समावेश छन्:
(१) हालको डाटाबेस जाँच गर्नुहोस् (कुनै प्यारामिटर छैन):
DBCC CHECKDB
(२) नामद्वारा डाटाबेस जाँच गर्नुहोस्:
DBCC CHECKDB ('YourDatabaseName')
(3) ID द्वारा डाटाबेस जाँच गर्नुहोस्:
DBCC CHECKDB(5) -- Replace 5 with your database ID
यो आधारभूत आदेशले निर्दिष्ट डाटाबेसको पूर्ण अखण्डता जाँच गर्दछ, सबै तालिकाहरू, अनुक्रमणिकाहरू, र प्रणाली संरचनाहरूको जाँच गर्दछ। कुनै खाली ठाउँ नभएको मानक नामहरू भएका डाटाबेसहरूको लागि, तपाईंले उद्धरणहरू छोड्न सक्नुहुन्छ। यो आदेश पूरा नभएसम्म चल्नेछ, प्रगति सन्देशहरू र अन्तिम परिणामहरू प्रदर्शन गर्दै। यो आधारभूत वाक्य रचनाले साना डाटाबेसहरूको लागि वा तपाईंसँग पर्याप्त मर्मत समय उपलब्ध हुँदा पूर्ण रूपमा काम गर्दछ।
तल DBCC CHECKDB चलाउने स्क्रिनसट छ SQL Server व्यवस्थापन स्टुडियो (SSMS):
३.३ पूर्ण विकल्पहरू
DBCC CHECKDB का लागि पूर्ण विकल्पहरू तल दिइएका छन्:
श्रेणी | विकल्प | विवरण | DBCC CHECKDB उदाहरण |
---|---|---|---|
मरम्मत विकल्प | REPAIR_REBUILD |
डेटा नोक्सान बिना मर्मत (जस्तै, अनुक्रमणिका पुनर्निर्माण) | DBCC CHECKDB ('MyDB', REPAIR_REBUILD) |
REPAIR_FAST |
मर्मत छैन। पछाडिको अनुकूलता मात्र | DBCC CHECKDB ('MyDB', REPAIR_FAST) |
|
REPAIR_ALLOW_DATA_LOSS |
सबै त्रुटिहरू मर्मत गर्दछ (डेटा हराउन सक्छ) | DBCC CHECKDB ('CorruptDB', REPAIR_ALLOW_DATA_LOSS) |
|
स्कोप नियन्त्रण | NOINDEX |
क्लस्टर नगरिएको अनुक्रमणिका जाँचहरू छोड्छ | DBCC CHECKDB ('LargeDB', NOINDEX) |
PHYSICAL_ONLY |
भौतिक भण्डारण अखण्डता (पृष्ठहरू/रेकर्डहरू) मात्र जाँच गर्छ। | DBCC CHECKDB ('ProdDB', PHYSICAL_ONLY) |
|
DATA_PURITY |
तार्किक स्तम्भ-मान त्रुटिहरूको लागि जाँच गर्दछ (जस्तै, अमान्य मितिहरू) | DBCC CHECKDB ('OldDB', DATA_PURITY) |
|
EXTENDED_LOGICAL_CHECKS |
गहन तार्किक जाँचहरू (अनुक्रमित दृश्यहरू, XML/स्थानिक अनुक्रमणिकाहरू) | DBCC CHECKDB ('ComplexDB', EXTENDED_LOGICAL_CHECKS) |
|
आउटपुट नियन्त्रण | ALL_ERRORMSGS |
सबै त्रुटिहरू देखाउँछ (पूर्वनिर्धारित: प्रति वस्तु २००) | DBCC CHECKDB ('MyDB', ALL_ERRORMSGS) |
NO_INFOMSGS |
जानकारीमूलक सन्देशहरू लुकाउँछ | DBCC CHECKDB ('MyDB', NO_INFOMSGS) |
|
प्रदर्शन | TABLOCK |
टेबल लकहरू प्रयोग गर्दछ (TempDB प्रयोग घटाउँछ तर लेखन रोक्छ) | DBCC CHECKDB ('BigDB', TABLOCK) |
MAXDOP = number |
समानान्तर सेटिङहरूलाई ओभरराइड गर्छ | DBCC CHECKDB ('MyDB', MAXDOP = 2) |
|
उपयोगिता | ESTIMATEONLY |
आवश्यक पर्ने TempDB ठाउँ अनुमान गर्दछ। (वास्तविक जाँच छैन) | DBCC CHECKDB ('MyDB', ESTIMATEONLY) |
४. आफ्नो नतिजा बुझ्ने
DBCC CHECKDB ले यसको कार्यान्वयन सफलतापूर्वक पूरा भयो वा भएन भन्ने आधारमा फरक नतिजाहरू उत्पादन गर्नेछ। तिनीहरूलाई विस्तृत रूपमा व्याख्या गरौं।
४.१ CHECKDB कार्यान्वयन सफलतापूर्वक सम्पन्न भयो
यदि DBCC CHECKDB कार्यान्वयन सफलतापूर्वक पूरा भयो भने, यसले तपाईंको डाटाबेसको स्वास्थ्य स्थितिको आधारमा विभिन्न प्रकारका परिणामहरू रिपोर्ट गर्नेछ।
४.१.१ कुनै समस्या भेटिएन
यदि DBCC CHECKDB ले कुनै समस्या फेला पारेन भने, तपाईंले निम्न जस्तै आउटपुट देख्नुहुनेछ:
CHECKDB found 0 allocation errors and 0 consistency errors in database 'YourDatabase'.
DBCC execution completed. If DBCC printed error messages, contact your system administrator.
यो नतिजाले तपाईंको डाटाबेसले सबै जाँच गरिएका संरचनाहरूमा पूर्ण अखण्डता कायम राखेको संकेत गर्छ।
४.१.२ भ्रष्टाचार त्रुटिहरू फेला परे
जब पनि DBCC CHECKDB ले भ्रष्टाचार त्रुटि पत्ता लगाउँछ, यसले निम्न संरचना भएको त्रुटि सन्देश रिपोर्ट गर्नेछ:
गम्भीरता स्तर गाइड:
- २ 16०-११,००० स्तर: प्रयोगकर्ता-सुधार गर्न सकिने त्रुटिहरू, प्रायः सानो भ्रष्टाचार
- २ 20०-११,००० स्तर: प्रणाली त्रुटिहरू, गम्भीर भ्रष्टाचार जसमा तत्काल ध्यान दिनु आवश्यक छ
- स्तर २: घातक त्रुटिहरू, डाटाबेस पहुँचयोग्य नहुन सक्छ।
सामान्य त्रुटिहरू समावेश छन्:
- पृष्ठ चेकसम विफलताहरू (सन्देश ८२४)
- आवंटन त्रुटिहरू (सन्देश ८९२८)
- अनुक्रमणिका स्थिरता समस्याहरू (सन्देश ८९६४)
सन्देश संरचना बुझ्नाले प्रतिक्रिया कार्यहरूलाई प्राथमिकता दिन र उपयुक्त पुनर्प्राप्ति रणनीतिहरू निर्धारण गर्न मद्दत गर्दछ।
४.१.३ सामान्य सूचनात्मक र चेतावनी सन्देशहरू
सबै DBCC CHECKDB आउटपुटले गम्भीर समस्याहरू संकेत गर्दैन। यसले केही जानकारीमूलक र चेतावनी सन्देशहरू पनि आउटपुट गर्न सक्छ, जसमा समावेश छन्:
- मर्मत विवरणहरू - सानातिना समस्याहरू समाधान गर्न मर्मत आदेशहरू सुझाव दिने सन्देशहरू
- आवंटन चेतावनीहरू - डेटा पहुँचलाई असर नगर्ने ठाउँ बाँडफाँडको बारेमा चेतावनीहरू
- कार्यसम्पादन सिफारिसहरू - अनुक्रमणिका मर्मत र अनुकूलनको लागि सुझावहरू
- जानकारीमूलक सूचनाहरू - तत्काल कारबाही आवश्यक नपर्ने सामान्य स्थिति सन्देशहरू
यी सन्देशहरूले मूल्यवान मर्मत मार्गदर्शन प्रदान गर्दछन्, साथै तत्काल कारबाही आवश्यक पर्ने गम्भीर भ्रष्टाचार र नियमित मर्मतसम्भार अवधिमा सम्बोधन गर्न सकिने सानातिना समस्याहरू बीचको भिन्नता छुट्याउँछन्।
उदाहरण चेतावनी सन्देश:
DBCC results for 'InventoryDatabase'.
Msg 2570, Level 16, State 3, Line 1
Page (2:8452), slot 17 in object ID 485577333, index ID 0, partition ID 72057594038845456,
alloc unit ID 72057594042515968 (type "In-row data").
Column "ProductPrice" value is out of range for data type "decimal". Update column to a legal value.
There are 45892 rows in 1247 pages for object "Products".
CHECKDB found 0 allocation errors and 1 consistency errors in table 'Products' (object ID 485577333).
CHECKDB found 0 allocation errors and 1 consistency errors in database 'InventoryDatabase'.
४.२ CHECKDB कार्यान्वयन रद्द हुन्छ
यदि विभिन्न कारणले गर्दा CHECKDB कार्यान्वयनको क्रममा रद्द भयो भने, यसले त्रुटि सन्देश रिपोर्ट गर्नेछ र तलको राज्य कोड सहित त्रुटि लग थप्नेछ:
राज्य | विवरण |
---|---|
0 |
त्रुटि नम्बर ८९३० उठाइएको थियो। यसले मेटाडेटामा भ्रष्टाचार भएको संकेत गर्छ जसले DBCC आदेश समाप्त गर्यो। |
1 |
त्रुटि नम्बर ८९६७ उठाइएको थियो। आन्तरिक DBCC त्रुटि थियो। |
2 |
आपतकालीन मोड डाटाबेस मर्मतको क्रममा एउटा विफलता भयो। |
3 |
यसले मेटाडेटामा भ्रष्टाचार भएको संकेत गर्छ जसले DBCC आदेश समाप्त गर्यो। |
4 |
एउटा दाबी वा पहुँच उल्लङ्घन पत्ता लाग्यो। |
5 |
एउटा अज्ञात त्रुटि भयो जसले DBCC आदेश समाप्त गर्यो। |
उदाहरण त्रुटि सन्देश:
Failed:(-1073548784) Executing the query "DBCC CHECKDB('InventoryDB') WITH NO_INFOMSGS" failed with the following error: "There is insufficient system memory to run this query.Check terminated. A failure was detected while collecting facts. Possibly tempdb out of space or a system table is inconsistent. Check previous errors.". Possible failure reasons: Problems with the query, "ResultSet" property not set correctly, parameters not set correctly, or connection not established correctly.
or
2024-11-18 09:52:41.38 spid35 I/O error (bad page ID) detected during read at offset 0x00000024886000 in file 'C:\Data\MSSQL\DATA\SalesDatabase.mdf'.
उदाहरण त्रुटि लग:
11/15/2024 09:23:17,spid52,Unknown,DBCC CHECKDB (SalesDatabase) WITH all_errormsgs no_infomsgs executed by CORP\dbadmin terminated abnormally due to error state 3. Elapsed time: 1 hours 32 minutes 18 seconds.
यस्तो अवस्थामा, तपाईं वैकल्पिक उन्नत विकल्पहरू प्रयास गर्न सक्नुहुन्छ जस्तै DataNumen SQL Recovery तपाईंको डाटाबेसमा भएको भ्रष्टाचार समाधान गर्न।
५. भ्रष्टाचार त्रुटिहरू समाधान गर्ने
५.१ ब्याकअप र रिस्टोर: सबैभन्दा सुरक्षित समाधान
जब DBCC CHECKDB ले भ्रष्टाचार त्रुटिहरू पहिचान गर्छ, सफा ब्याकअपबाट पुनर्स्थापना गर्नु सबैभन्दा सुरक्षित र m हो।ost भरपर्दो समाधान। यो दृष्टिकोणले डेटा अखण्डताको ग्यारेन्टी दिन्छ जबकि अन्तर्निहित भ्रष्टाचार कारणहरूलाई हटाउँछ। पुनर्स्थापना गर्नु अघि, ब्याकअप अखण्डता प्रमाणित गर्नुहोस् पुन: भण्डारण प्रमाणित गर्नुहोस् आदेशहरू, र डेटा हानि कम गर्न पोइन्ट-इन-टाइम रिकभरी विकल्पहरू विचार गर्नुहोस्। मूल कारण विश्लेषणको लागि भ्रष्टाचार विवरणहरू दस्तावेज गर्नुहोस्, किनकि हार्डवेयर समस्याहरू वा सफ्टवेयर बगहरू पुनरावृत्ति रोक्न थप ध्यान आवश्यक पर्न सक्छ।
५.२ पृष्ठ-स्तरीय भ्रष्टाचार समाधानहरू
साना डेटा भागहरूलाई असर गर्ने पृथक पृष्ठ भ्रष्टाचारको लागि, SQL Server इन्टरप्राइज संस्करणले पृष्ठ पुनर्स्थापना क्षमताहरू प्रदान गर्दछ जसले पूर्ण डाटाबेस पुनर्स्थापना बिना विशिष्ट क्षतिग्रस्त पृष्ठहरू मर्मत गर्दछ। यो उन्नत प्रविधिलाई पूर्ण पुनर्प्राप्ति मोडेल र हालको लग ब्याकअपहरू आवश्यक पर्दछ।
चरण-दर-चरण पृष्ठ पुनर्स्थापना प्रक्रिया:
- बिग्रिएको पृष्ठ पहिचान गर्नुहोस् CHECKDB त्रुटि सन्देशबाट (जस्तै, पृष्ठ १:२५६)
- हालको लग ब्याकअप लिनुहोस् हालसालैका कारोबारहरू कैद गर्न:
BACKUP LOG YourDatabase TO DISK = 'C:\Backups\YourDB_Log.trn'
- बिग्रिएको पृष्ठ पुनर्स्थापित गर्नुहोस् म बाटost हालसालैको पूर्ण ब्याकअप:
RESTORE DATABASE YourDatabase PAGE = '1:256'
FROM DISK = 'C:\Backups\YourDB_Full.bak'
- भिन्न ब्याकअप लागू गर्नुहोस् (यदि उपलब्ध छ भने):
RESTORE DATABASE YourDatabase PAGE = '1:256'
FROM DISK = 'C:\Backups\YourDB_Diff.bak'
- सबै लग ब्याकअपहरू लागू गर्नुहोस् क्रमशः, भर्खरै सिर्जना गरिएको सहित:
RESTORE LOG YourDatabase FROM DISK = 'C:\Backups\YourDB_Log1.trn'
RESTORE LOG YourDatabase FROM DISK = 'C:\Backups\YourDB_Log2.trn'
-- Continue for all log backups in order
RESTORE LOG YourDatabase FROM DISK = 'C:\Backups\YourDB_Log.trn'
- अन्तिम लग ब्याकअप लिनुहोस् र पुनर्स्थापना गर्नुहोस् पृष्ठलाई हालको अवस्थामा ल्याउन:
BACKUP LOG YourDatabase TO DISK = 'C:\Backups\YourDB_Final.trn'
RESTORE LOG YourDatabase FROM DISK = 'C:\Backups\YourDB_Final.trn'
गैर-महत्वपूर्ण डेटाको लागि विकल्प: यदि भ्रष्टाचारले गैर-महत्वपूर्ण डेटालाई असर गर्छ भने, तपाईंले भ्रष्ट संरचनाहरू पुनर्निर्माण गर्नु अघि नयाँ तालिकाहरूमा अप्रभावित पङ्क्तिहरू निर्यात गर्न सक्नुहुन्छ:
-- Export good data to a new table
SELECT * INTO YourTable_Backup
FROM YourTable
WHERE NOT EXISTS (SELECT 1 FROM corrupt_page_list WHERE page_id = target_page)
-- Drop and recreate the corrupted table
DROP TABLE YourTable
-- Recreate table structure and reload clean data
५.३ सूचकांक भ्रष्टाचार द्रुत समाधानहरू
अन्तर्निहित तालिका डेटालाई असर नगरी अनुक्रमणिका संरचनाहरू पुन: सिर्जना गर्ने पुनर्निर्माण कार्यहरूमा अनुक्रमणिका भ्रष्टाचारले प्रायः राम्रो प्रतिक्रिया दिन्छ:
ALTER INDEX ALL ON YourTable REBUILD
यो दृष्टिकोण विशेष गरी गैर-क्लस्टर गरिएको सूचकांक भ्रष्टाचारको लागि राम्रोसँग काम गर्दछ, किनकि पुनर्निर्माणले स्रोत तालिका डेटाबाट सूचकांक पृष्ठहरू पुन: उत्पन्न गर्दछ, प्रभावकारी रूपमा भ्रष्टाचार हटाउँदै सबै मौलिक जानकारी सुरक्षित गर्दछ।
६. REPAIR_REBUILD र REPAIR_ALLOW_DATA_LOSS प्रयोग गर्नुहोस्
यदि अघिल्ला सबै विधिहरू असफल भए वा सम्भव नभएमा, तपाईंले डाटाबेस मर्मत गर्न REPAIR_REBUILD र REPAIR_ALLOW_DATA_LOSS विकल्पहरू प्रयोग गर्न सक्नुहुन्छ।
६.१ मर्मत_पुनर्निर्माण (सुरक्षित विकल्प):
- यसको लागि प्रयोग गर्नुहोस्: अनुक्रमणिका भ्रष्टाचार र सानातिना विनियोजन त्रुटिहरू
- डाटा सुरक्षा: डेटा नमेटाईकन भ्रष्टाचार समाधान गर्ने प्रयास
- जोखिम स्तर: कम - डेटा हराउने अपेक्षा गरिएको छैन
- सामान्य परिदृश्यहरू: क्लस्टर नभएको सूचकांक भ्रष्टाचार, सामान्य मेटाडेटा समस्याहरू
- आदेश उदाहरण:
DBCC CHECKDB('YourDB', REPAIR_REBUILD)
६.२ मर्मत_गर्नुहोस्_डेटा_हानि (अन्तिम उपाय):
- यसको लागि प्रयोग गर्नुहोस्: ब्याकअपहरू उपलब्ध नभएको बेला गम्भीर भ्रष्टाचार
- डाटा सुरक्षा: डाटाबेस कार्यक्षमता पुनर्स्थापित गर्न दूषित डेटा मेटाउन सक्छ
- जोखिम स्तर: उच्च - स्थायी डेटा हराउन सम्भव छ
- सामान्य परिदृश्यहरू: पृष्ठ भ्रष्टाचार, प्रणाली तालिका क्षति, आवंटन श्रृंखला त्रुटिहरू
- आदेश उदाहरण:
DBCC CHECKDB('YourDB', REPAIR_ALLOW_DATA_LOSS)
६.३ यी विकल्पहरूको लागि उत्तम अभ्यासहरू:
- सधैं परीक्षण गर्नुहोस् सम्भव भएसम्म डाटाबेस प्रतिलिपिहरूमा मर्मत कार्यहरू
- सधैं ब्याकअप लिनुहोस् यी विकल्पहरू चलाउनु अघि
- सबै परिवर्तनहरू कागजात गर्नुहोस् अनुपालन र समस्या निवारण उद्देश्यका लागि
- डाटाबेसलाई एकल-प्रयोगकर्ता मोडमा सेट गर्नुहोस् मर्मत कार्य सञ्चालन गर्नु अघि
सामान्यतया, हामीले प्रयास गर्नुपर्छ मर्मत_पुनर्निर्माण पहिलो विकल्प। यदि यो असफल भयो भने, प्रयास गर्नुहोस् REPAIR_ALLOW_DATA_LOSS विकल्प।
६.४ REPAIR_ALLOW_DATA_LOSS परिणामहरू
६.४.१ डाटा हराएको अवस्थामा पनि मर्मत सफल हुन्छ
कहिलेकाँही REPAIR_ALLOW_DATA_LOSS विकल्प सफल हुनेछ, तर केही डेटा l छost मर्मत पछि।
तल केही नमुना सन्देशहरू छन्:
CHECKDB found 0 allocation errors and 103 consistency errors in database ‘SalesDatabase’.
CHECKDB fixed 0 allocation errors and 103 consistency errors in database ‘SalesDatabase’.
DBCC execution completed. If DBCC printed error messages, contact your system administrator.
Msg 8909, Level 16, State 1, Line 8
Table error: Object ID 0, index ID -1, partition ID 0, alloc unit ID 45035996309880832 (type Unknown), page ID (1:553) contains an incorrect page ID in its page header. The PageId in the page header = (0:0).
The error has been repaired.
Msg 8939, Level 16, State 98, Line 8
Table error: Object ID 0, index ID -1, partition ID 0, alloc unit ID 111464090777419776 (type Unknown), page (0:0). Test (IS_OFF (BUF_IOERR, pBUF->bstat)) failed. Values are 2057 and -1.
Could not repair this error.
यो किनभने DBCC CHECKDB ले केही क्षतिग्रस्त रेकर्डहरू त्यागेर डाटाबेस ठीक गर्छ, तर वास्तवमा, most ती मध्ये अझै पनि मार्फत पुन: प्राप्त गर्न सकिन्छ DataNumen SQL Recovery.
नमुना फाइलहरू:
SQL Server संस्करण | दूषित MDF फाइल | MDF फाइल द्वारा निश्चित DataNumen SQL Recovery |
SQL Server 2014 | त्रुटि10_1.mdf (Msg ८९०९ त्यसपछि Msg ८९३९) (६०० रेकर्ड lost REPAIR_ALLOW_DATA_LOSS सँग) | त्रुटि10_1_fixed.mdf (कुनै रेकर्ड छैन lost) |
SQL Server 2014 | त्रुटि10_2.mdf (Msg ८९०९ त्यसपछि Msg ८९३९) (६००० रेकर्ड (५०%) lost REPAIR_ALLOW_DATA_LOSS सँग) | त्रुटि10_2_fixed.mdf (केवल १०० रेकर्डहरू lost) |
SQL Server 2014 | त्रुटिmdf (१०० रेकर्ड lost REPAIR_ALLOW_DATA_LOSS सँग) | त्रुटि7_fixed.mdf (केवल एउटा रेकर्ड lost) |
६.४.२ मर्मत असफल - व्यावसायिक समाधान विचार गर्नुहोस्
If REPAIR_ALLOW_DATA_LOSS असफल भएमा, यसले एक वा धेरै त्रुटि सन्देशहरू आउटपुट गर्नेछ।
तल केही उदाहरणहरू दिइएका छन्:
DBCC results for ‘MyDatabase’.
CHECKDB found 0 allocation errors and 0 consistency errors in database ‘MyDatabase’.
Msg 824, Level 24, State 2, Line 8
SQL Server detected a logical consistency-based I/O error: incorrect checksum (expected: 0xea8a9a2f; actual: 0x37adbff8). It occurred during a read of page (1:28) in database ID 39 at offset 0x00000000038000 in file ‘MyDatabase.mdf’. Additional messages in the SQL Server error log or system event log may provide more detail. This is a severe error condition that threatens database integrity and must be corrected immediately. Complete a full database consistency check (DBCC CHECKDB). This error can be caused by many factors; for more information, see SQL Server Books Online.
Msg 7909, Level 20, State 1, Line 8
The emergency-mode repair failed.You must restore from backup.
Msg 8992, Level 16, State 1, Line 8
Check Catalog Msg 3852, State 1: Row (object_id=69) in sys.objects (type=S ) does not have a matching row (object_id=69,column_id=1) in sys.columns.
Msg 8945, Level 16, State 1, Line 8
Table error: Object ID 41, index ID 1 will be rebuilt.
Could not repair this error.
Msg 2510, Level 16, State 17, Line 8
DBCC checkdb error: This system table index cannot be recreated.
Repair: The Nonclustered index successfully rebuilt for the object “sysidxstats” in database “MyDatabase”.
Msg 8921, Level 16, State 1, Line 8
Check terminated. A failure was detected while collecting facts. Possibly tempdb out of space or a system table is inconsistent. Check previous errors.
Msg 8998, Level 16, State 2, Line 8
Page errors on the GAM, SGAM, or PFS pages prevent allocation integrity checks in database ID 39 pages from (1:0) to (1:8087). See other errors for cause.
CHECKDB found 1 allocation errors and 0 consistency errors not associated with any single object.
Msg 2575, Level 16, State 1, Line 8
The Index Allocation Map (IAM) page (1:157) is pointed to by the next pointer of IAM page (0:0) in object ID 3, index ID 1, partition ID 196608, alloc unit ID 196608 (type In-row data), but it was not detected in the scan.
Could not repair this error.
CHECKDB found 1 allocation errors and 0 consistency errors in table ‘sys.sysrscols’ (object ID 3).
Msg 8948, Level 16, State 3, Line 8
Database error: Page (1:295) is marked with the wrong type in PFS page (1:1). PFS status 0x70 expected 0x60.
The error has been repaired.
Msg 8905, Level 16, State 1, Line 8
Extent (1:296) in database ID 39 is marked allocated in the GAM, but no SGAM or IAM has allocated it.
The error has been repaired.
Msg 5028, Level 16, State 4, Line 4
The system could not activate enough of the database to rebuild the log.
Msg 5125, Level 24, State 2, Line 2
File ‘C:Program FilesMicrosoft SQL ServerMSSQL12.SQL2014MSSQLDATASalesDatabase.mdf’ appears to have been truncated by the operating system. Expected size is 5120 KB but actual size is 5112 KB.
Msg 3414, Level 21, State 1, Line 2
An error occurred during recovery, preventing the database ‘SalesDatabase’ (39:0) from restarting. Diagnose the recovery errors and fix them, or restore from a known good backup. If errors are not corrected or expected, contact Technical Support.
Msg 3313, Level 21, State 1, Line 2
During redoing of a logged operation in database ‘SalesDatabase’, an error occurred at log record ID (135:752:2). Typically, the specific failure is previously logged as an error in the Windows Event Log service. Restore the database from a full backup, or repair the database.
यी परिदृश्यहरूमा, तपाईंले व्यावसायिक समाधान प्रयोग गर्न आवश्यक छ जस्तै DataNumen SQL Recovery तपाईंको डाटाबेस ठीक गर्न।
नमुना फाइलहरू
SQL Server संस्करण | दूषित MDF फाइल | MDF फाइल द्वारा निश्चित DataNumen SQL Recovery |
SQL Server 2014 | त्रुटि1_3.mdf (एकल सन्देश ८२४) | त्रुटि1_3_fixed.mdf |
SQL Server 2014 | त्रुटि1_1.mdf (निरन्तर सन्देश ८२४ त्रुटिहरू) | त्रुटि1_1_fixed.mdf |
SQL Server 2014 | त्रुटि1_2.mdf ((सन्देश ८२४ र त्यसपछि ७९०९ सन्देश) | त्रुटि1_2_fixed.mdf |
SQL Server 2014 | त्रुटि4_1.mdf (सन्देश ८९९२ र त्यसपछि ३८५२) | त्रुटि4_1_fixed.mdf |
SQL Server 2014 | त्रुटि4_2.mdf (सन्देश ८९९२ र त्यसपछि ३८५२) | त्रुटि4_2_fixed.mdf |
SQL Server 2014 | त्रुटि5.mdf (सन्देश ८९४५) | त्रुटि5_fixed.mdf |
SQL Server 2014 | त्रुटि6.mdf (सन्देश ८९४५) | त्रुटि6_fixed.mdf |
SQL Server 2014 | त्रुटि2.mdf (सन्देश ८९४५) | त्रुटि2_fixed.mdf |
SQL Server 2014 | त्रुटि11.mdf (सन्देश ८९४५) | त्रुटि11_fixed.mdf |
SQL Server 2014 | त्रुटि3.mdf (सन्देश ८९४५) | त्रुटि3_fixed.mdf |
SQL Server 2014 | त्रुटिmdf (सन्देश ८९४५) | त्रुटि_fixed.mdf |
SQL Server 2014 | त्रुटि9.mdf (सन्देश ८९४५) | त्रुटि9_fixed.mdf |
४. उत्तम अभ्यासहरू
६.१ नियमित CHECKDB सञ्चालनको तालिका बनाउने
उच्च-कारोबार प्रणालीहरूको लागि दैनिक जाँचहरू सहित, महत्वपूर्ण उत्पादन डाटाबेसहरूको लागि साप्ताहिक DBCC CHECKDB कार्यान्वयन लागू गर्नुहोस्। कार्यसम्पादन प्रभावलाई कम गर्न कम-उपयोग अवधिहरूमा सञ्चालनहरू तालिकाबद्ध गर्नुहोस्, र डाटाबेस आकार र मर्मतसम्भार विन्डोजहरूमा आधारित पूर्ण जाँचहरू र PHYSICAL_ONLY विकल्पहरू बीच घुमाउने विचार गर्नुहोस्। स्वचालित तालिकाबद्धता मार्फत SQL Server एजेन्टले केन्द्रीकृत अनुगमन र सतर्कता क्षमताहरू प्रदान गर्दै निरन्तर कार्यान्वयन सुनिश्चित गर्दछ।
६.२ कार्यसम्पादन प्रभाव व्यवस्थापन
DBCC CHECKDB सञ्चालनहरूले महत्त्वपूर्ण प्रणाली स्रोतहरू उपभोग गर्छन्, सम्भावित रूपमा समवर्ती प्रयोगकर्ता गतिविधिलाई असर गर्छ। कार्यसम्पादन प्रभाव ढाँचाहरू बुझ्न जाँचको क्रममा CPU उपयोग, मेमोरी खपत, र डिस्क I/O निगरानी गर्नुहोस्। मासिक मर्मतसम्भार विन्डोहरूको लागि पूर्ण प्रमाणीकरण आरक्षित गर्दै, नियमित जाँचहरूको लागि NOINDEX विकल्पहरू प्रयोग गर्ने विचार गर्नुहोस्। अखण्डता जाँच अवधिहरूमा अपेक्षाहरू व्यवस्थापन गर्न क्वेरी टाइमआउट एक्सटेन्सनहरू र प्रयोगकर्ता सञ्चार रणनीतिहरू लागू गर्नुहोस्।
६.३ मर्मतसम्भार विन्डो योजना
ब्याकअप अपरेशन, इन्डेक्स पुनर्निर्माण, र तथ्याङ्क अद्यावधिकहरू जस्ता अन्य मर्मत गतिविधिहरूसँग DBCC CHECKDB तालिकाको समन्वय गर्नुहोस्। कार्यसम्पादन गिरावट वा टाइमआउट समस्याहरू निम्त्याउन सक्ने स्रोत-गहन अपरेशनहरूलाई ओभरल्याप गर्नबाट बच्नुहोस्। डाटाबेस आकार वृद्धि अनुमानहरूमा आधारित मर्मत विन्डोहरू योजना गर्नुहोस्, डेटा भोल्युम बढ्दै जाँदा पूर्ण अखण्डता प्रमाणीकरणको लागि पर्याप्त समय सुनिश्चित गर्दै।
६.४ स्वचालित अनुगमन र सतर्कता
कन्फिगर गर्नुहोस् SQL Server DBCC CHECKDB ले भ्रष्टाचार पहिचान गर्दा प्रशासकहरूलाई तुरुन्तै सूचित गर्न एजेन्ट अलर्टहरू। लग पार्सिङ समाधानहरू लागू गर्नुहोस् जसले अखण्डता जाँच परिणामहरू निकाल्छ र वर्गीकृत गर्दछ, प्रवृत्ति विश्लेषण र सक्रिय समस्या पहिचान सक्षम पार्छ। विभिन्न भ्रष्टाचार गम्भीरता स्तरहरूको लागि प्रतिक्रिया समयसीमा र जिम्मेवार कर्मचारीहरू परिभाषित गर्ने एस्केलेसन प्रक्रियाहरू सिर्जना गर्नुहोस्।
७. DBCC चेकटेबल: हल्का तौलको विकल्प
७.१ CHECKDB को सट्टा CHECKTABLE कहिले प्रयोग गर्ने
DBCC CHECKTABLE ले व्यक्तिगत तालिकाहरूको लागि केन्द्रित अखण्डता जाँच प्रदान गर्दछ, यसलाई आदर्श बनाउँछ tarविशिष्ट डाटाबेस वस्तुहरूको समस्या निवारण र मर्मतसम्भार प्राप्त भयो। विशेष तालिकाहरूसँग कार्यसम्पादन समस्याहरूको अनुसन्धान गर्दा, पूर्ण डाटाबेस जाँचहरू बीच महत्वपूर्ण व्यापार तालिकाहरू प्रमाणीकरण गर्दा, वा समय सीमाहरूले पूर्ण डाटाबेस प्रमाणीकरणलाई रोक्दा CHECKTABLE प्रयोग गर्नुहोस्। यो दृष्टिकोण विशेष गरी ठूला डाटाबेसहरूमा मूल्यवान साबित हुन्छ जहाँ पूर्ण CHECKDB सञ्चालनहरू उपलब्ध मर्मतसम्भार विन्डोहरू भन्दा बढी हुन्छन्।
७.२ DBCC चेकटेबल वाक्य रचना र उदाहरणहरू
आधारभूत CHECKTABLE आदेश tarविशिष्ट तालिकाहरू प्राप्त गर्दछ:
DBCC CHECKTABLE('YourTable')
CHECKDB जस्तै, CHECKTABLE ले कार्यसम्पादन अनुकूलनको लागि NOINDEX र भ्रष्टाचार समाधानको लागि मर्मत प्यारामिटरहरू सहित विभिन्न विकल्पहरूलाई समर्थन गर्दछ। तपाईं सटीक तालिका पहिचानको लागि स्कीमा नामहरू पनि निर्दिष्ट गर्न सक्नुहुन्छ:
DBCC CHECKTABLE('SchemaName.TableName', NOINDEX)
यो targeted दृष्टिकोणले व्यापारिक घण्टाको समयमा प्रणाली कार्यसम्पादन कायम राख्दै दानादार अखण्डता प्रमाणीकरणलाई अनुमति दिन्छ।
७.३ ठूला डाटाबेसहरूको लागि कार्यसम्पादन लाभहरू
CHECKTABLE सञ्चालनहरू पूर्ण डाटाबेस जाँचहरू भन्दा धेरै छिटो पूरा हुन्छन्, जसले गर्दा महत्वपूर्ण तालिकाहरूको बारम्बार अखण्डता प्रमाणीकरण सक्षम हुन्छ। यो दृष्टिकोणले साप्ताहिक वा मासिक तालिकाहरूको लागि व्यापक CHECKDB सञ्चालनहरू आरक्षित गर्दा आवश्यक व्यापार तालिकाहरूको दैनिक प्रमाणीकरणलाई अनुमति दिन्छ। कम स्रोत खपतले CHECKTABLE लाई न्यूनतम प्रयोगकर्ता प्रभावको साथ उत्पादन वातावरण कार्यान्वयनको लागि उपयुक्त बनाउँछ।
८. जब CHECKDB असफल हुन्छ
DBCC CHECKDB विभिन्न परिदृश्यहरूमा असफल हुनेछ, जसमा समावेश छन्:
- DBCC CHECKDB कार्यान्वयन असामान्य रूपमा समाप्त हुन्छ
- DBCC CHECKDB कार्यान्वयन सफलतापूर्वक सम्पन्न भयो, तर मरम्मत विकल्प डाटाबेस मर्मत गर्न असफल।
यी परिदृश्यहरूमा, हामीलाई डाटाबेसमा भएका भ्रष्टाचारहरू समाधान गर्न मद्दत गर्न थप व्यावसायिक उपकरणको आवश्यकता पर्दछ।
१.१ को परिचय DataNumen SQL Recovery
DataNumen SQL Recovery थप उन्नत क्षमताहरू प्रदान गर्दछ:
- उत्तम रिकभरी दर उद्योगमा।
- गम्भीर रूपमा दूषित डाटाबेस फाइलहरू पुन: प्राप्ति गर्नुहोस्।
- तालिकाहरू, अनुक्रमणिकाहरू, दृश्यहरू, ट्रिगरहरू, नियमहरू, र पूर्वनिर्धारितहरू सहित सबै डाटाबेस वस्तुहरू पुन: प्राप्ति गर्नुहोस्।
- भण्डारण प्रक्रियाहरू, स्केलर प्रकार्यहरू, इनलाइन तालिका-मूल्य कार्यहरू, र मल्टिस्टेटमेन्ट तालिका-मूल्य कार्यहरू पुन: प्राप्त गर्नुहोस्।
- स्थायी रूपमा मेटाइएका रेकर्डहरू पुन: प्राप्ति गर्नुहोस्।
- गुप्तिकरण गरिएका वस्तुहरू डिक्रिप्ट गर्नुहोस् SQL Server डाटाबेस
- ब्याचमा MDF फाइलहरू मर्मत गर्नुहोस्।
- व्यापक मरम्मत विकल्प।
- उन्नत लगिङ र रिपोर्टिङ।
- सबैको लागि समर्थन SQL Server संस्करणहरु।
- प्राविधिक समर्थन उपलब्धता
- नियमित अपडेट र सुधारहरू
८.२ सफलता दर तुलना
रिकभरी सफलता दरहरू महत्त्वपूर्ण रूपमा भिन्न छन्:
- DBCC चेकDB र चेकटेबल: 1.27% औसत रिकभरी दर
- DataNumen: 92.6% रिकभरी दर
तल एक पूर्ण प्रतिस्पर्धात्मक तुलना छ:
८.३ गम्भीर भ्रष्टाचारबाट पुन:प्राप्ति
गम्भीर अवस्थाहरूको लागि उन्नत क्षमताहरू:
- भौतिक रूपमा क्षतिग्रस्त भण्डारणबाट पुनःप्राप्ति
- ढाँचा गरिएका ड्राइभहरू वा क्र्यास भएका प्रणालीहरूबाट रिकभरी
- डिस्क छविहरू, ब्याकअप फाइलहरू, भर्चुअल मेसिन डिस्क फाइलहरू, टेम्पोबाट पुन: प्राप्ति गर्नुहोस्rary फाइलहरू, आदि।
८.५ व्यावसायिक समाधानहरू कहिले विचार गर्ने
- हालसालै ब्याकअप उपलब्ध छैन
- DBCC CHECKDB असफल भयो
- गम्भीर भ्रष्टाचार परिदृश्यहरू
- महत्वपूर्ण व्यापार डेटासँग व्यवहार गर्दै
- जब समय महत्वपूर्ण छ
- जब अधिकतम रिकभरी आवश्यक छ
FA. प्राय: सोधिने प्रश्नहरू
१०.१ आधारभूत प्रयोग प्रश्नहरू
प्रश्न: मैले कति पटक DBCC CHECKDB चलाउनु पर्छ?
A: महत्वपूर्ण उत्पादन डाटाबेसहरूको लागि, साप्ताहिक रूपमा CHECKDB चलाउनुहोस्। उच्च-कारोबार प्रणालीहरूको लागि, PHYSICAL_ONLY विकल्प प्रयोग गरेर दैनिक जाँचहरू विचार गर्नुहोस्, साप्ताहिक रूपमा पूर्ण जाँचहरू सहित। विकास डाटाबेसहरू मासिक रूपमा जाँच गर्न सकिन्छ।
प्रश्न: के म प्रत्यक्ष उत्पादन डाटाबेसमा DBCC CHECKDB चलाउन सक्छु?
A: हो, DBCC CHECKDB प्रयोगकर्ताहरूलाई ब्लक नगरी अनलाइन डाटाबेसमा चल्न सक्छ। यद्यपि, यसले महत्त्वपूर्ण स्रोतहरू खपत गर्छ, त्यसैले कम-गतिविधि अवधिहरूमा यसलाई तालिकाबद्ध गर्नुहोस् र प्रणाली कार्यसम्पादन निगरानी गर्नुहोस्।
प्रश्न: CHECKDB र CHECKTABLE मा के फरक छ?
A: CHECKDB ले सम्पूर्ण डाटाबेसको जाँच गर्छ, जबकि CHECKTABLE ले व्यक्तिगत तालिकाहरूमा ध्यान केन्द्रित गर्छ। CHECKTABLE को लागि प्रयोग गर्नुहोस् tarसमस्या निवारण प्राप्त भयो वा जब तपाईंलाई सम्पूर्ण डाटाबेस स्क्यान नगरी विशेष तालिकाहरू जाँच गर्न आवश्यक पर्दछ।
१०.२ कार्यसम्पादन र स्रोत प्रश्नहरू
प्रश्न: मेरो ठूलो डाटाबेसमा DBCC CHECKDB ले किन यति धेरै समय लिइरहेको छ?
A: CHECKDB अवधि डाटाबेसको आकार, हार्डवेयर कार्यसम्पादन र प्रयोग गरिएका विकल्पहरूमा निर्भर गर्दछ। छिटो जाँचको लागि PHYSICAL_ONLY प्रयोग गर्नुहोस्, वा गैर-क्लस्टर गरिएको अनुक्रमणिकाहरू छोड्न NOINDEX प्रयोग गर्नुहोस्। समर्पित स्रोतहरूसँग मर्मतसम्भारको समयमा विन्डोहरू चलाउने विचार गर्नुहोस्।
प्रश्न: CHECKDB लाई कति tempdb ठाउँ चाहिन्छ?
A: सामान्यतया, CHECKDB सञ्चालनको क्रममा tempdb को लागि तपाईंको डाटाबेस आकारको १०-१५% छुट्याउनुहोस्। सटीक अनुमान प्राप्त गर्न ESTIMATEONLY विकल्प प्रयोग गर्नुहोस्: DBCC CHECKDB('YourDB') WITH ESTIMATEONLY
प्रश्न: के म चलिरहेको CHECKDB अपरेशन रद्द गर्न सक्छु?
A: हो, तपाईंले सत्र ID मा रहेको KILL आदेश प्रयोग गरेर CHECKDB रद्द गर्न सक्नुहुन्छ। यद्यपि, रद्द गर्नाले डाटाबेसको अखण्डताको बारेमा कुनै जानकारी प्रदान गर्दैन, र तपाईंले यसलाई पछि फेरि चलाउनु पर्नेछ।
१०.३ प्रश्नहरू ह्यान्डल गर्दा त्रुटि
प्रश्न: CHECKDB ले त्रुटिहरू फेला पार्यो - के म आत्तिनु पर्छ?
A: नआत्तिनुहोस्, तर छिटो काम गर्नुहोस्। पहिले, CHECKDB सफलतापूर्वक पूरा भयो तर भ्रष्टाचार फेला पर्यो कि परेन, वा CHECKDB आफैं चल्न असफल भयो कि परेन भनेर निर्धारण गर्नुहोस्। त्रुटिहरूले केवल गैर-क्लस्टर गरिएको अनुक्रमणिका (कम महत्वपूर्ण) वा तालिका डेटा (अधिक गम्भीर) लाई असर गर्छ कि पर्दैन जाँच गर्नुहोस्।
प्रश्न: मैले REPAIR_ALLOW_DATA_LOSS कहिले प्रयोग गर्नुपर्छ?
A: जब तपाईंसँग कुनै प्रयोगयोग्य ब्याकअपहरू छैनन् र कुल डाटाबेस नोक्सानको तुलनामा डेटा नोक्सान स्वीकार्य हुन्छ, तब मात्र अन्तिम उपायको रूपमा। सधैं पहिले ब्याकअपबाट पुनर्स्थापना गर्ने प्रयास गर्नुहोस्, किनकि मर्मत कार्यहरूले स्थायी डेटा नोक्सान निम्त्याउन सक्छ।
प्रश्न: "डाटाबेसमा स्थिरता त्रुटिहरू" बनाम "आवंटन त्रुटिहरू" को अर्थ के हो?
A: आवंटन त्रुटिहरूले कसरी असर गर्छ SQL Server डिस्क स्पेस प्रयोग ट्र्याक गर्दछ, जबकि स्थिरता त्रुटिहरूले डेटा वा अनुक्रमणिका संरचनाहरूमा समस्याहरू संकेत गर्दछ। दुवैलाई ध्यान दिन आवश्यक छ, तर स्थिरता त्रुटिहरूले सामान्यतया डेटा पहुँचलाई प्रत्यक्ष रूपमा असर गर्छ।
१०.४ ब्याकअप र रिकभरी प्रश्नहरू
प्रश्न: के मैले मेरो ब्याकअपहरूमा CHECKDB चलाउनु पर्छ?
A: अवश्य पनि! सर्भरहरू परीक्षण गर्न ब्याकअपहरू पुनर्स्थापित गरेपछि CHECKDB चलाउनुहोस्। यसले ब्याकअपको अखण्डता प्रमाणित गर्छ र तपाईं वास्तवमा भ्रष्टाचारबाट पुन: प्राप्ति गर्न सक्नुहुन्छ भन्ने कुरा सुनिश्चित गर्दछ। सम्भव भएमा यो प्रक्रिया स्वचालित गर्नुहोस्।
प्रश्न: मेरो ब्याकअप पनि बिग्रिएको छ - अब के गर्ने?
A: पुरानो ब्याकअपहरू प्रयास गर्नुहोस् जबसम्म तपाईंले सफा ब्याकअप फेला पार्नुहुन्न। यदि कुनै सफा ब्याकअपहरू अवस्थित छैनन् भने, व्यावसायिक रिकभरी समाधानहरू विचार गर्नुहोस् जस्तै DataNumen SQL Recoveryभविष्यमा हुने घटनाहरूलाई रोक्न भ्रष्टाचारको समयरेखा दस्तावेज गर्नुहोस्।
प्रश्न: के पूर्ण डाटाबेस रिकभरी बिना पृष्ठ पुनर्स्थापनाले भ्रष्टाचार समाधान गर्न सक्छ?
A: हो, तर केवल SQL Server पूर्ण रिकभरी मोडेल र हालको लग ब्याकअपहरू सहितको इन्टरप्राइज संस्करण। पृष्ठ पुनर्स्थापनाले पृथक पृष्ठ भ्रष्टाचारको लागि काम गर्छ तर उचित प्रक्रियाहरू पालना गर्दै सावधानीपूर्वक कार्यान्वयन आवश्यक पर्दछ।
१०.५ समस्या निवारण प्रश्नहरू
प्रश्न: CHECKDB "ठाउँ बाहिर" त्रुटिहरूको साथ असफल भइरहेको छ - म के गर्न सक्छु?
A: tempdb ठाउँ खाली गर्नुहोस्, tempdb लाई छिटो भण्डारणमा सार्नुहोस्, वा tempdb को प्रयोग घटाउन TABLOCK विकल्प प्रयोग गर्नुहोस्। स्रोत आवश्यकताहरू कम गर्न NOINDEX वा PHYSICAL_ONLY सँग CHECKDB चलाउने विचार गर्नुहोस्।
प्रश्न: CHECKDB आउटपुटबाट कुन तालिकामा भ्रष्टाचार छ भनेर म कसरी पहिचान गर्ने?
A: त्रुटि सन्देशहरूमा "वस्तु ID" नम्बरहरू खोज्नुहोस्, त्यसपछि प्रयोग गर्नुहोस्: SELECT OBJECT_NAME(object_id)
तालिका नामहरू फेला पार्न। त्रुटि सन्देशहरूमा सटीक स्थान पहिचानको लागि पृष्ठ र स्लट नम्बरहरू पनि समावेश छन्।
प्रश्न: के हार्डवेयर समस्याहरूले CHECKDB लाई गलत सकारात्मक रिपोर्ट गर्न सक्छ?
A: हो, हार्डवेयर असफल हुँदा (विशेष गरी भण्डारण) CHECKDB रनहरू बीच देखा पर्ने र गायब हुने बीच-बीचमा भ्रष्टाचार हुन सक्छ। यदि त्रुटिहरू असंगत छन् भने, आफ्नो I/O उपप्रणालीको अनुसन्धान गर्नुहोस् र ढाँचाहरू पुष्टि गर्न धेरै जाँचहरू चलाउनुहोस्।
१०.६ उन्नत कन्फिगरेसन प्रश्नहरू
प्रश्न: कुन ट्रेस फ्ल्यागहरूले CHECKDB कार्यसम्पादन सुधार गर्न सक्छ?
A: ट्रेस फ्ल्याग २५६२ ले CHECKDB लाई एकल ब्याचको रूपमा चलाएर कार्यसम्पादन सुधार गर्न सक्छ। डाटाबेस फाइलहरू छुट्टाछुट्टै डिस्कमा हुँदा ट्रेस फ्ल्याग २५४९ ले मद्दत गर्छ। यी सावधानीपूर्वक प्रयोग गर्नुहोस् र पहिले गैर-उत्पादनमा परीक्षण गर्नुहोस्।
प्रश्न: म CHECKDB अनुगमन र सतर्कता कसरी स्वचालित गर्न सक्छु?
A: प्रयोग SQL Server त्रुटि नम्बर ८९३०, ८९३९, र अन्यका लागि एजेन्ट अलर्टहरू। CHECKDB परिणामहरू निकाल्न लग पार्सिङ लागू गर्नुहोस्, र कुनै पनि भ्रष्टाचार पत्ता लागेमा सूचनाहरू सिर्जना गर्नुहोस्। ओला हेलेनग्रेनको स्क्रिप्टहरू जस्ता मर्मत समाधान फ्रेमवर्कहरू प्रयोग गर्ने विचार गर्नुहोस्।
प्रश्न: के मैले EXTENDED_LOGICAL_CHECKS विकल्प प्रयोग गर्नुपर्छ?
A: यदि तपाईंलाई जटिल तार्किक भ्रष्टाचारको शंका छ र पर्याप्त कार्यसम्पादन ओभरहेड छ भने मात्र। यो विकल्पले अनुक्रमित दृश्यहरू, XML अनुक्रमणिकाहरू, र स्थानिय अनुक्रमणिकाहरूमा अतिरिक्त जाँचहरू गर्दछ तर कार्यान्वयन समयलाई उल्लेखनीय रूपमा बढाउँछ।
11। निष्कर्षमा
२.६ मुख्य बुँदाहरूको सारांश
९.१.१ आवश्यक DBCC CHECKDB आदेशहरूको सारांश
व्यापक डाटाबेस जाँचको लागि आधारभूत DBCC CHECKDB वाक्य रचनामा निपुण हुनुहोस्, कार्यसम्पादन अनुकूलनको लागि NOINDEX र PHYSICAL_ONLY विकल्पहरू प्रयोग गर्नुहोस्, र CHECKTABLE बुझ्नुहोस्। targeted तालिका प्रमाणीकरण। यी आधारभूत आदेशहरूले सक्रिय डाटाबेस मर्मतसम्भारको जग बनाउँछन्, जसले गर्दा प्रारम्भिक भ्रष्टाचार पत्ता लगाउने र व्यवस्थित अखण्डता अनुगमन सक्षम हुन्छ।
९.१.२ महत्वपूर्ण उत्तम अभ्यासहरूको सम्झना
अखण्डता जाँचहरू चलाउनु अघि सधैं हालको ब्याकअपहरू कायम राख्नुहोस्, डाटाबेसको आलोचनात्मकताको आधारमा नियमित CHECKDB सञ्चालनहरू तालिकाबद्ध गर्नुहोस्, र तत्काल भ्रष्टाचार अलर्टहरूको लागि स्वचालित अनुगमन लागू गर्नुहोस्। याद राख्नुहोस् कि नियमित अनुगमन मार्फत रोकथामले प्रतिक्रियाशील दृष्टिकोणहरूलाई पार गर्छ, र मानक उपकरणहरू अपर्याप्त साबित हुँदा व्यावसायिक रिकभरी समाधानहरूले मूल्यवान ब्याकअप विकल्पहरू प्रदान गर्दछ।
९.२ DBCC CHECKDB बनाम उन्नत समाधानहरू कहिले प्रयोग गर्ने
नियमित अखण्डता अनुगमन र सानो भ्रष्टाचार समाधानको लागि DBCC CHECKDB प्रयोग गर्नुहोस्, जबकि निर्मित मर्मत क्षमताहरू भन्दा बाहिर गम्भीर भ्रष्टाचार परिदृश्यहरूको लागि व्यावसायिक रिकभरी उपकरणहरू आरक्षित गर्नुहोस्। निर्णय ढाँचाले ब्याकअप उपलब्धता, डेटाको आलोचनात्मकता, समय सीमा, र भ्रष्टाचारको गम्भीरतालाई विचार गर्नुपर्छ। सफल डाटाबेस प्रशासकहरूले नियमित CHECKDB अनुगमनलाई व्यापक ब्याकअप रणनीतिहरू र मानक दृष्टिकोणहरू अपर्याप्त साबित हुँदा उन्नत रिकभरी विकल्पहरूको जागरूकतासँग संयोजन गर्छन्।
Re। सन्दर्भ
- माइक्रोसफ्ट लर्न। "DBCC CHECKDB (ट्रान्स्याक्ट-SQL)।" SQL Server दस्तावेजमाइक्रोसफ्ट कर्पोरेशन।
https://learn.microsoft.com/en-us/sql/t-sql/database-console-commands/dbcc-checkdb-transact-sql?view=sql-server-ver17 - माइक्रोसफ्ट लर्न। "DBCC CHECKDB द्वारा रिपोर्ट गरिएको डाटाबेस स्थिरता त्रुटिहरूको समस्या निवारण गर्नुहोस्।" SQL Server दस्तावेजमाइक्रोसफ्ट कर्पोरेशन।
https://learn.microsoft.com/en-us/troubleshoot/sql/database-engine/database-file-operations/troubleshoot-dbcc-checkdb-errors