AWR: डाटाबेस प्रदर्शन कसरी "विशेषज्ञ" छ?

यस छोटो पोस्टको साथ म Oracle Exadata मा चलिरहेको AWR डाटाबेसहरूको विश्लेषणसँग सम्बन्धित एउटा गलतफहमीलाई हटाउन चाहन्छु। लगभग 10 वर्षको लागि, म निरन्तर प्रश्नको सामना गरिरहेको छु: उत्पादकतामा Exadata Software को योगदान के हो? वा नयाँ गठित शब्दहरू प्रयोग गर्दै: कसरी "विशेषज्ञ" एक विशेष डाटाबेसको काम हो?

प्रायः यो सही प्रश्न, मेरो विचारमा, AWR तथ्याङ्कको सन्दर्भमा गलत जवाफ दिइन्छ। यसले प्रणाली प्रतीक्षा विधि प्रस्तुत गर्दछ, जसले प्रतिक्रिया समयलाई प्रोसेसरहरूको सञ्चालन समय (DB CPUs) र विभिन्न कक्षाहरूको प्रतीक्षा समयको योगको रूपमा व्यवहार गर्दछ।

Exadata को आगमन संग, Exadata सफ्टवेयर को संचालन संग सम्बन्धित विशिष्ट प्रणाली अपेक्षा AWR तथ्याङ्क मा देखा पर्यो। नियमको रूपमा, त्यस्ता पर्खाइहरूको नाम "सेल" (एक्सडेटा भण्डारण सर्भरलाई सेल भनिन्छ) शब्दबाट सुरु हुन्छ, जसमध्ये सबैभन्दा सामान्य नामहरू "सेल स्मार्ट टेबल स्क्यान", "सेल मल्टिब्लक फिजिकल रिड" भनिने प्रतिक्षाहरू हुन्। र "सेल एकल ब्लक भौतिक पठन"।

धेरैजसो अवस्थामा, कुल प्रतिक्रिया समयमा पर्खने त्यस्ता Exadata को अंश सानो हुन्छ, र त्यसैले तिनीहरू टोटल वेट टाइम खण्डद्वारा शीर्ष १० फोरग्राउन्ड घटनाहरूमा पर्दैनन् (यस अवस्थामा, तपाईंले तिनीहरूलाई अग्रभूमि पर्खाइमा खोज्नु पर्छ। घटना खण्ड)। ठूलो कठिनाईको साथ, हामीले हाम्रा ग्राहकहरूबाट दैनिक AWR को उदाहरण भेट्टायौं, जसमा Exadata अपेक्षाहरू Top10 खण्डमा समावेश गरिएको थियो र कुल रकम लगभग 10% थियो:

घटना

पर्खन्छ

कुल प्रतीक्षा समय (सेकेन्ड)

औसत पर्खनुहोस्

% DB समय

कक्षा पर्खनुहोस्

DB CPU

115.2K

70.4

SQL*dblink बाट नेट थप डाटा

670,196

5471.5

8.16ms

3.3

नेटवर्क

सेल एकल ब्लक भौतिक पढाइ

5,661,452

3827.6

676.07us

2.3

प्रयोगकर्ता I/O

ASM रिब्यालेन्स सिंक गर्नुहोस्

4,350,012

3481.3

800.30us

2.1

अन्य

सेल मल्टीब्लक भौतिक पढाइ

759,885

2252

2.96ms

1.4

प्रयोगकर्ता I/O

सीधा बाटो पढ्नुहोस्

374,368

1811.3

4.84ms

1.1

प्रयोगकर्ता I/O

dblink बाट SQL*नेट सन्देश

7,983

1725

216.08ms

1.1

नेटवर्क

सेल स्मार्ट टेबल स्क्यान

1,007,520

1260.7

1.25ms

0.8

प्रयोगकर्ता I/O

सीधा मार्ग पढ्ने तापमान

520,211

808.4

1.55ms

0.5

प्रयोगकर्ता I/O

enq: TM - विवाद

652

795.8

1220.55ms

0.5

आवेदन

यस्ता AWR तथ्याङ्कहरूबाट प्रायः निम्न निष्कर्षहरू निकालिन्छन्:

1. डाटाबेस प्रदर्शनमा Exadata जादू को योगदान उच्च छैन - यो 5% भन्दा बढी छैन, र डाटाबेस "exadatizes" खराब छ।

2. यदि यस्तो डाटाबेस Exadata बाट क्लासिक "सर्भर + array" आर्किटेक्चरमा स्थानान्तरण गरियो भने, प्रदर्शन धेरै परिवर्तन हुनेछैन। किनभने यदि यो एरे Exadata भण्डारण प्रणाली (जुन आधुनिक All Flash arrays को लागि सायद सम्भव छैन) भन्दा तीन गुणा ढिलो भएको भए पनि, त्यसपछि 5% लाई तीनले गुणन गर्दा हामीले I/O को शेयरमा 15% पर्खने वृद्धि पाउँछौं। - डाटाबेस निश्चित रूपमा यो बाँच्नेछ!

यी दुवै निष्कर्षहरू गलत छन्, यसबाहेक, तिनीहरूले Exadata सफ्टवेयर पछाडिको विचारको बुझाइलाई विकृत गर्छन्। Exadata ले द्रुत I/O मात्र प्रदान गर्दैन, यसले क्लासिक सर्भर + एरे आर्किटेक्चरको तुलनामा आधारभूत रूपमा फरक काम गर्दछ। यदि डाटाबेस सञ्चालन साँच्चै "विस्तारित" छ भने, SQL तर्क भण्डारण प्रणालीमा स्थानान्तरण गरिएको छ। भण्डारण सर्भरहरू, धेरै विशेष संयन्त्रहरू (मुख्य रूपमा Exadata भण्डारण अनुक्रमणिकाहरू, तर मात्र होइन) को लागी धन्यवाद, आवश्यक डाटा आफैं खोज्नुहोस् र सर्भरहरूमा DB पठाउनुहोस्। तिनीहरूले यो धेरै कुशलतापूर्वक गर्छन्, त्यसैले सामान्य Exadata को कुल प्रतिक्रिया समय मा प्रतिक्षाको अंश सानो छ। 

Exadata बाहिर यो शेयर कसरी परिवर्तन हुनेछ? यसले समग्र डाटाबेसको कार्यसम्पादनलाई कसरी असर गर्छ? परीक्षणले यी प्रश्नहरूको जवाफ दिनेछ। उदाहरणका लागि, Exadata बाहिर "सेल स्मार्ट टेबल स्क्यान" को लागि पर्खनुले यस्तो भारी तालिका पूर्ण स्क्यानमा परिणत हुन सक्छ कि I/O ले सम्पूर्ण प्रतिक्रिया समय लिन्छ र प्रदर्शन नाटकीय रूपमा घट्छ। त्यसकारण यो गलत छ, AWR को विश्लेषण गर्दा, Exadata अपेक्षाहरूको कुल प्रतिशतलाई प्रदर्शनमा यसको जादूको योगदानको रूपमा विचार गर्नु, र अझ बढी Exadata बाहिरको कार्यसम्पादनको भविष्यवाणी गर्न यो प्रतिशत प्रयोग गर्नु गलत हो। डाटाबेसको काम कत्तिको "सटीक" छ भनेर बुझ्नको लागि, तपाईंले "इन्स्ट्यान्स गतिविधि तथ्याङ्क" खण्डको AWR तथ्याङ्कहरू अध्ययन गर्न आवश्यक छ (त्यहाँ स्व-व्याख्यात्मक नामहरूसँग धेरै तथ्याङ्कहरू छन्) र तिनीहरूलाई एक-अर्कासँग तुलना गर्नुहोस्।

र Exadata बाहिरको डाटाबेसले कस्तो महसुस गर्नेछ भनेर बुझ्नको लागि, लक्षित आर्किटेक्चरमा ब्याकअपबाट डाटाबेस क्लोन बनाउन र लोड अन्तर्गत यो क्लोनको कार्यसम्पादन विश्लेषण गर्नु उत्तम हुन्छ। नियमको रूपमा, Exadata मालिकहरूसँग यो अवसर छ।

लेखक: एलेक्सी स्ट्रुचेन्को, जेट इन्फोसिस्टम डाटाबेस विभागका प्रमुख

स्रोत: www.habr.com