AWR: តើ "អ្នកជំនាញ" ដំណើរការមូលដ្ឋានទិន្នន័យយ៉ាងដូចម្តេច?

ជាមួយនឹងការប្រកាសខ្លីនេះ ខ្ញុំចង់លុបបំបាត់ការយល់ច្រលំមួយដែលទាក់ទងនឹងការវិភាគនៃមូលដ្ឋានទិន្នន័យ AWR ដែលដំណើរការលើ Oracle Exadata។ អស់រយៈពេលជិត 10 ឆ្នាំមកហើយ ខ្ញុំបានប្រឈមមុខនឹងសំណួរឥតឈប់ឈរ៖ តើការរួមចំណែករបស់កម្មវិធី Exadata ដល់ផលិតភាពគឺជាអ្វី? ឬប្រើពាក្យដែលទើបបង្កើតថ្មី៖ តើ "អ្នកជំនាញ" ជាការងាររបស់មូលដ្ឋានទិន្នន័យជាក់លាក់យ៉ាងដូចម្តេច?

ជាញឹកញយ សំណួរត្រឹមត្រូវនេះ តាមគំនិតរបស់ខ្ញុំ ត្រូវបានឆ្លើយមិនត្រឹមត្រូវ ដោយយោងទៅលើស្ថិតិ AWR ។ វាបង្ហាញពីវិធីសាស្រ្តរង់ចាំប្រព័ន្ធ ដែលចាត់ទុកពេលវេលាឆ្លើយតបជាផលបូកនៃពេលវេលាប្រតិបត្តិការរបស់ processors (DB CPUs) និងពេលវេលារង់ចាំនៃថ្នាក់ផ្សេងៗ។

ជាមួយនឹងការមកដល់នៃ Exadata ការរំពឹងទុករបស់ប្រព័ន្ធជាក់លាក់ទាក់ទងនឹងប្រតិបត្តិការនៃកម្មវិធី Exadata បានបង្ហាញខ្លួននៅក្នុងស្ថិតិ AWR ។ តាមក្បួនមួយឈ្មោះនៃការរង់ចាំបែបនេះចាប់ផ្តើមដោយពាក្យ "កោសិកា" (ម៉ាស៊ីនមេផ្ទុកទិន្នន័យ Exadata ត្រូវបានគេហៅថាកោសិកា) ដែលការរង់ចាំទូទៅបំផុតគឺការប្រាប់ឈ្មោះ "ការស្កែនតារាងឆ្លាតវៃក្រឡា" "ក្រឡាច្រើនប្លុកការអាន" ។ និង "កោសិកាតែមួយប្លុកអានរាងកាយ" ។

ក្នុងករណីភាគច្រើន ចំណែកនៃ Exadata រង់ចាំក្នុងពេលវេលាឆ្លើយតបសរុបគឺតូច ដូច្នេះហើយពួកគេមិនបានធ្លាក់ចូលទៅក្នុងព្រឹត្តិការណ៍ខាងមុខកំពូលទាំង 10 ដោយផ្នែករង់ចាំសរុប (ក្នុងករណីនេះ អ្នកត្រូវរកមើលពួកវានៅផ្នែកខាងមុខរង់ចាំ។ ផ្នែកព្រឹត្តិការណ៍) ។ ជាមួយនឹងការលំបាកយ៉ាងខ្លាំង យើងបានរកឃើញឧទាហរណ៍នៃ AWR ប្រចាំថ្ងៃពីអតិថិជនរបស់យើង ដែលក្នុងនោះការរំពឹងទុក Exadata ត្រូវបានរួមបញ្ចូលនៅក្នុងផ្នែក Top10 ហើយសរុបមានចំនួនប្រហែល 5%៖

ព្រឹត្តការណ៍

រង់ចាំ

ពេលវេលារង់ចាំសរុប (វិនាទី)

រង់ចាំជាមធ្យម

% DB ម៉ោង

រង់ចាំថ្នាក់

ស៊ីភីយូ DB

115.2K

70.4

SQL*Net ទិន្នន័យបន្ថែមពី 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

SQL * សារសុទ្ធពី dblink

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 magic ទៅនឹងដំណើរការមូលដ្ឋានទិន្នន័យគឺមិនខ្ពស់ទេ - វាមិនលើសពី 5% ហើយមូលដ្ឋានទិន្នន័យ "exadatizes" មិនល្អ។

2. ប្រសិនបើមូលដ្ឋានទិន្នន័យបែបនេះត្រូវបានផ្ទេរពី Exadata ទៅស្ថាបត្យកម្ម "server + array" បុរាណ នោះដំណើរការនឹងមិនផ្លាស់ប្តូរច្រើនទេ។ ដោយសារតែទោះបីជាអារេនេះប្រែទៅជាយឺតជាងប្រព័ន្ធផ្ទុក Exadata 5 ដង (ដែលស្ទើរតែមិនអាចធ្វើទៅបានសម្រាប់អារេ Flash ទំនើបទាំងអស់) បន្ទាប់មកគុណ 15% ដោយបីយើងទទួលបានការកើនឡើងនៃចំណែកនៃ I/O រង់ចាំដល់ XNUMX% ។ - មូលដ្ឋានទិន្នន័យពិតជានឹងរស់រានមានជីវិត!

ការសន្និដ្ឋានទាំងពីរនេះគឺមិនត្រឹមត្រូវ លើសពីនេះទៅទៀត ពួកគេបានបំភ្លៃការយល់ដឹងអំពីគំនិតដែលមាននៅក្នុងកម្មវិធី Exadata ។ Exadata មិនគ្រាន់តែផ្តល់នូវ I/O លឿនប៉ុណ្ណោះទេ វាដំណើរការខុសគ្នាជាមូលដ្ឋានបើប្រៀបធៀបទៅនឹងម៉ាស៊ីនមេបុរាណ + ស្ថាបត្យកម្មអារេ។ ប្រសិនបើប្រតិបត្តិការមូលដ្ឋានទិន្នន័យពិតជា "ផ្លាស់ប្តូរ" នោះតក្កវិជ្ជា SQL ត្រូវបានផ្ទេរទៅប្រព័ន្ធផ្ទុក។ ម៉ាស៊ីនមេផ្ទុកទិន្នន័យ អរគុណចំពោះយន្តការពិសេសមួយចំនួន (ជាចម្បង សន្ទស្សន៍ផ្ទុកទិន្នន័យ Exadata ប៉ុន្តែមិនត្រឹមតែប៉ុណ្ណោះ) ស្វែងរកទិន្នន័យចាំបាច់ដោយខ្លួនឯង ហើយផ្ញើ DB ទៅម៉ាស៊ីនមេ។ ពួកគេធ្វើវាយ៉ាងមានប្រសិទ្ធភាព ដូច្នេះចំណែកនៃ Exadata ធម្មតារង់ចាំក្នុងពេលវេលាឆ្លើយតបសរុបគឺតូច។ 

តើការចែករំលែកនេះនឹងផ្លាស់ប្តូរនៅខាងក្រៅ Exadata យ៉ាងដូចម្តេច? តើវានឹងប៉ះពាល់ដល់ដំណើរការនៃមូលដ្ឋានទិន្នន័យទាំងមូលយ៉ាងដូចម្តេច? ការធ្វើតេស្តនឹងឆ្លើយសំណួរទាំងនេះបានល្អបំផុត។ ឧទាហរណ៍ ការរង់ចាំ "ការស្កែនតារាងក្រឡាឆ្លាតវៃ" នៅខាងក្រៅ Exadata អាចប្រែទៅជាការស្កេនពេញតារាងធ្ងន់ ដែល I/O ចំណាយពេលឆ្លើយតបទាំងស្រុង ហើយដំណើរការថយចុះយ៉ាងខ្លាំង។ នោះហើយជាមូលហេតុដែលវាខុស នៅពេលវិភាគ AWR ដើម្បីពិចារណាភាគរយសរុបនៃការរំពឹងទុករបស់ Exadata ជាការរួមចំណែកនៃវេទមន្តរបស់វាចំពោះការអនុវត្ត និងសូម្បីតែច្រើនទៀតដូច្នេះដើម្បីប្រើភាគរយនេះដើម្បីទស្សន៍ទាយលទ្ធផលនៅខាងក្រៅ Exadata ។ ដើម្បីយល់ពីរបៀបដែល "ពិតប្រាកដ" ការងាររបស់មូលដ្ឋានទិន្នន័យគឺ អ្នកត្រូវសិក្សាស្ថិតិ AWR នៃផ្នែក "Instance Activity Stats" (មានស្ថិតិជាច្រើនដែលមានឈ្មោះពន្យល់ដោយខ្លួនឯង) ហើយប្រៀបធៀបពួកវាជាមួយគ្នា។

ហើយដើម្បីយល់ពីរបៀបដែលមូលដ្ឋានទិន្នន័យនៅខាងក្រៅ Exadata នឹងមានអារម្មណ៍ វាជាការល្អបំផុតក្នុងការបង្កើតក្លូនមូលដ្ឋានទិន្នន័យពីការបម្រុងទុកនៅលើស្ថាបត្យកម្មគោលដៅ និងវិភាគដំណើរការនៃក្លូននេះដែលកំពុងផ្ទុក។ តាមក្បួនមួយម្ចាស់ Exadata មានឱកាសនេះ។

អ្នកនិពន្ធ: លោក Alexey Struchenko ប្រធាននាយកដ្ឋានទិន្នន័យប្រព័ន្ធព័ត៌មាន Jet

ប្រភព: www.habr.com