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

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

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

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

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

घटना

पर्खन्छ

कुल पर्खाइ समय (सेकेन्ड)

औसत प्रतीक्षा

%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 तथ्याङ्कहरूबाट, निम्न निष्कर्षहरू प्रायः निकालिन्छन्:

१. डाटाबेस कार्यसम्पादनमा एक्साडेटा म्याजिकको योगदान उच्च छैन - ५% भन्दा बढी छैन, र डाटाबेस "एक्साडेटास" खराब छ।

२. यदि यस्तो डाटाबेसलाई Exadata बाट क्लासिक "सर्भर + एरे" आर्किटेक्चरमा स्थानान्तरण गरियो भने, कार्यसम्पादनमा धेरै परिवर्तन हुनेछैन। किनभने यदि यो एरे Exadata भण्डारण प्रणाली (जुन आधुनिक All Flash एरेहरूको लागि सम्भव छैन) भन्दा तीन गुणा ढिलो भयो भने पनि, ५% लाई तीनले गुणा गर्दा हामीले इनपुट-आउटपुटको हिस्सा १५% सम्म बढ्छौं - डाटाबेस निश्चित रूपमा यसबाट बच्नेछ!

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

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

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

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

स्रोत: www.habr.com