AWR: ວິທີການ "ຜູ້ຊ່ຽວຊານ" ແມ່ນການປະຕິບັດຖານຂໍ້ມູນ?

ດ້ວຍການຕອບສັ້ນໆນີ້ຂ້ອຍຢາກຈະຍົກເລີກຄວາມເຂົ້າໃຈຜິດຫນຶ່ງທີ່ກ່ຽວຂ້ອງກັບການວິເຄາະຖານຂໍ້ມູນ AWR ທີ່ເຮັດວຽກຢູ່ໃນ Oracle Exadata. ສໍາລັບເກືອບ 10 ປີ, ຂ້າພະເຈົ້າໄດ້ປະເຊີນກັບຄໍາຖາມຢ່າງຕໍ່ເນື່ອງ: ການປະກອບສ່ວນຂອງຊອບແວ Exadata ແມ່ນຫຍັງ? ຫຼືການໃຊ້ຄໍາສັບທີ່ສ້າງຂື້ນໃຫມ່: "ຜູ້ຊ່ຽວຊານ" ເຮັດວຽກຂອງຖານຂໍ້ມູນສະເພາະແນວໃດ?

ເລື້ອຍໆຄໍາຖາມທີ່ຖືກຕ້ອງນີ້, ໃນຄວາມຄິດເຫັນຂອງຂ້ອຍ, ຖືກຕອບບໍ່ຖືກຕ້ອງໂດຍອ້າງອີງໃສ່ສະຖິຕິ AWR. ມັນນໍາສະເຫນີວິທີການລໍຖ້າລະບົບ, ເຊິ່ງປະຕິບັດຕໍ່ເວລາຕອບສະຫນອງເປັນຜົນລວມຂອງເວລາປະຕິບັດງານຂອງໂປເຊດເຊີ (DB CPUs) ແລະເວລາລໍຖ້າຂອງຫ້ອງຮຽນຕ່າງໆ.

ກັບການມາເຖິງຂອງ Exadata, ຄວາມຄາດຫວັງຂອງລະບົບສະເພາະທີ່ກ່ຽວຂ້ອງກັບການດໍາເນີນງານຂອງ Exadata Software ປາກົດຢູ່ໃນສະຖິຕິ AWR. ຕາມກົດລະບຽບ, ຊື່ຂອງການລໍຖ້າດັ່ງກ່າວເລີ່ມຕົ້ນດ້ວຍຄໍາວ່າ "ເຊນ" (ເຄື່ອງແມ່ຂ່າຍຂອງ Exadata Storage ເອີ້ນວ່າເຊນ), ເຊິ່ງທົ່ວໄປທີ່ສຸດແມ່ນການລໍຖ້າທີ່ມີຊື່ "cell smart table scan", "cell multiblock physical read" ແລະ "ການອ່ານທາງກາຍະພາບຂອງເຊນດຽວ".

ໃນກໍລະນີຫຼາຍທີ່ສຸດ, ສ່ວນແບ່ງຂອງ Exadata ດັ່ງກ່າວລໍຖ້າໃນເວລາຕອບໂຕ້ທັງຫມົດແມ່ນຫນ້ອຍ, ແລະດັ່ງນັ້ນພວກມັນບໍ່ຕົກຢູ່ໃນເຫດການ Top10 Foreground ໂດຍພາກເວລາລໍຖ້າທັງຫມົດ (ໃນກໍລະນີນີ້, ທ່ານຈໍາເປັນຕ້ອງຊອກຫາພວກເຂົາຢູ່ໃນ Foreground Wait. ພາກສ່ວນເຫດການ). ດ້ວຍຄວາມຫຍຸ້ງຍາກອັນໃຫຍ່ຫຼວງ, ພວກເຮົາໄດ້ພົບເຫັນຕົວຢ່າງຂອງ AWR ປະຈໍາວັນຈາກລູກຄ້າຂອງພວກເຮົາ, ໃນຄວາມຄາດຫວັງຂອງ Exadata ໄດ້ລວມຢູ່ໃນພາກ Top10 ແລະໃນຈໍານວນທັງຫມົດມີປະມານ 5%:

ກໍລະນີ

ລໍຖ້າ

ເວລາລໍຖ້າທັງໝົດ (ວິນາທີ)

ລໍຖ້າສະເລ່ຍ

%DB ເວລາ

ລໍຖ້າຫ້ອງຮຽນ

DB CPU

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 ​​rebalance

4,350,012

3481.3

ປີ 800.30us

2.1

ອື່ນ ໆ

cell multiblock ອ່ານທາງດ້ານຮ່າງກາຍ

759,885

2252

2.96ms

1.4

ຜູ້ໃຊ້ I/O

ອ່ານເສັ້ນທາງໂດຍກົງ

374,368

1811.3

4.84ms

1.1

ຜູ້ໃຊ້ I/O

SQL*Net ຂໍ້ຄວາມຈາກ dblink

7,983

1725

216.08ms

1.1

ເຄືອຂ່າຍ

ສະແກນຕາຕະລາງ smart cell

1,007,520

1260.7

1.25ms

0.8

ຜູ້ໃຊ້ I/O

ເສັ້ນທາງໂດຍກົງອ່ານ temp

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" ຄລາສສິກ, ຫຼັງຈາກນັ້ນ, ການປະຕິບັດຈະບໍ່ປ່ຽນແປງຫຼາຍ. ເນື່ອງຈາກວ່າເຖິງແມ່ນວ່າ array ນີ້ຈະກາຍເປັນສາມເທົ່າຊ້າກວ່າລະບົບການເກັບຮັກສາ Exadata (ເຊິ່ງເປັນໄປບໍ່ໄດ້ສໍາລັບ arrays Flash ທີ່ທັນສະໄຫມທັງຫມົດ), ຫຼັງຈາກນັ້ນການຄູນ 5% ໂດຍສາມພວກເຮົາໄດ້ຮັບການເພີ່ມຂຶ້ນຂອງສ່ວນແບ່ງຂອງ I / O ລໍຖ້າ 15% - ຖານຂໍ້ມູນແນ່ນອນຈະຢູ່ລອດນີ້!

ທັງສອງບົດສະຫຼຸບເຫຼົ່ານີ້ແມ່ນບໍ່ຖືກຕ້ອງ, ນອກຈາກນັ້ນ, ພວກມັນບິດເບືອນຄວາມເຂົ້າໃຈຂອງຄວາມຄິດທີ່ມີຢູ່ໃນ Exadata Software. Exadata ບໍ່ພຽງແຕ່ໃຫ້ I/O ໄວເທົ່ານັ້ນ, ມັນເຮັດວຽກແຕກຕ່າງກັນໂດຍພື້ນຖານເມື່ອທຽບກັບເຄື່ອງແມ່ຂ່າຍຄລາສສິກ + array architecture. ຖ້າການດໍາເນີນງານຂອງຖານຂໍ້ມູນແມ່ນ "exadapted" ຢ່າງແທ້ຈິງ, ຫຼັງຈາກນັ້ນ, ເຫດຜົນ SQL ຖືກໂອນໄປຫາລະບົບການເກັບຮັກສາ. ເຄື່ອງແມ່ຂ່າຍການເກັບຮັກສາ, ຂໍຂອບໃຈກັບຈໍານວນຂອງກົນໄກພິເສດ (ຕົ້ນຕໍ Exadata Storage Index, ແຕ່ບໍ່ພຽງແຕ່), ຊອກຫາຂໍ້ມູນທີ່ຈໍາເປັນດ້ວຍຕົນເອງແລະສົ່ງ DB ກັບເຄື່ອງແມ່ຂ່າຍ. ພວກເຂົາເຮັດອັນນີ້ຢ່າງມີປະສິດທິພາບ, ດັ່ງນັ້ນສ່ວນແບ່ງຂອງ Exadata ປົກກະຕິລໍຖ້າໃນເວລາຕອບໂຕ້ທັງຫມົດແມ່ນຫນ້ອຍ. 

ການແບ່ງປັນນີ້ຈະປ່ຽນແປງແນວໃດຢູ່ນອກ Exadata? ນີ້ຈະມີຜົນກະທົບແນວໃດຕໍ່ການປະຕິບັດຂອງຖານຂໍ້ມູນທັງຫມົດ? ການທົດສອບຈະຕອບຄໍາຖາມເຫຼົ່ານີ້ໄດ້ດີທີ່ສຸດ. ຕົວຢ່າງ, ການລໍຖ້າ "ການສະແກນຕາຕະລາງອັດສະລິຍະຂອງເຊນ" ຢູ່ນອກ Exadata ສາມາດເຮັດໃຫ້ການສະແກນເຕັມຕາຕະລາງທີ່ຫນັກແຫນ້ນທີ່ I/O ໃຊ້ເວລາຕອບສະຫນອງທັງຫມົດແລະການປະຕິບັດຫຼຸດລົງຢ່າງຫຼວງຫຼາຍ. ນັ້ນແມ່ນເຫດຜົນທີ່ວ່າມັນເປັນການຜິດພາດ, ເມື່ອວິເຄາະ AWR, ເພື່ອພິຈາລະນາອັດຕາສ່ວນທັງຫມົດຂອງຄວາມຄາດຫວັງຂອງ Exadata ເປັນການປະກອບສ່ວນຂອງ magic ຂອງມັນໃນການປະຕິບັດ, ແລະຫຼາຍກວ່ານັ້ນເພື່ອໃຊ້ອັດຕາສ່ວນນີ້ເພື່ອຄາດຄະເນການປະຕິບັດພາຍນອກຂອງ Exadata. ເພື່ອເຂົ້າໃຈວ່າການເຮັດວຽກຂອງຖານຂໍ້ມູນແມ່ນ "ແນ່ນອນ", ທ່ານຈໍາເປັນຕ້ອງໄດ້ສຶກສາສະຖິຕິ AWR ຂອງ "ສະຖິຕິກິດຈະກໍາຕົວຢ່າງ" (ມີສະຖິຕິຈໍານວນຫລາຍທີ່ມີຊື່ທີ່ອະທິບາຍດ້ວຍຕົນເອງ) ແລະປຽບທຽບກັບກັນແລະກັນ.

ແລະເພື່ອເຂົ້າໃຈວ່າຖານຂໍ້ມູນພາຍນອກຂອງ Exadata ຈະມີຄວາມຮູ້ສຶກແນວໃດ, ມັນດີທີ່ສຸດທີ່ຈະສ້າງໂຄນຖານຂໍ້ມູນຈາກການສໍາຮອງໃນສະຖາປັດຕະຍະກໍາເປົ້າຫມາຍແລະວິເຄາະການປະຕິບັດຂອງ clone ນີ້ພາຍໃຕ້ການໂຫຼດ. ຕາມກົດລະບຽບ, ເຈົ້າຂອງ Exadata ມີໂອກາດນີ້.

Author: Alexey Struchenko, ຫົວຫນ້າພະແນກຖານຂໍ້ມູນ Jet Infosystems

ແຫຼ່ງຂໍ້ມູນ: www.habr.com