ວິທີການ poke ວິທະຍາສາດ, ຫຼືວິທີການເລືອກການຕັ້ງຄ່າຖານຂໍ້ມູນໂດຍໃຊ້ benchmarks ແລະວິທີການເພີ່ມປະສິດທິພາບ.

ສະບາຍດີ

ຂ້າພະເຈົ້າໄດ້ຕັດສິນໃຈທີ່ຈະແບ່ງປັນການຊອກຫາຂອງຂ້ອຍ - ຫມາກຂອງຄວາມຄິດ, ການທົດລອງແລະຄວາມຜິດພາດ.
ໂດຍແລະຂະຫນາດໃຫຍ່: ນີ້ບໍ່ແມ່ນການຊອກຫາ, ແນ່ນອນ - ທັງຫມົດນີ້ຄວນຈະເປັນທີ່ຮູ້ຈັກເປັນເວລາດົນນານ, ສໍາລັບຜູ້ທີ່ມີສ່ວນຮ່ວມໃນການນໍາໃຊ້ການປະມວນຜົນຂໍ້ມູນສະຖິຕິແລະການເພີ່ມປະສິດທິພາບຂອງລະບົບຕ່າງໆ, ບໍ່ຈໍາເປັນໂດຍສະເພາະ DBMS.
ແລະ: ແມ່ນແລ້ວ, ພວກເຂົາຮູ້, ພວກເຂົາຂຽນບົດຄວາມທີ່ຫນ້າສົນໃຈກ່ຽວກັບການຄົ້ນຄວ້າຂອງພວກເຂົາ, ຕົວຢ່າງ (UPD.: ໃນຄໍາເຫັນພວກເຂົາຊີ້ໃຫ້ເຫັນໂຄງການທີ່ຫນ້າສົນໃຈຫຼາຍ: ottertune )
ໃນອີກດ້ານຫນຶ່ງ: offhand ຂ້າພະເຈົ້າບໍ່ເຫັນການກ່າວເຖິງຢ່າງກວ້າງຂວາງຫຼືການເຜີຍແຜ່ວິທີການນີ້ໃນອິນເຕີເນັດໃນບັນດາຜູ້ຊ່ຽວຊານດ້ານໄອທີ, DBA.

ດັ່ງນັ້ນ, ເຖິງຈຸດ.

ຂໍໃຫ້ສົມມຸດວ່າພວກເຮົາມີວຽກງານ: ຈັດຕັ້ງລະບົບການບໍລິການສະເພາະໃດຫນຶ່ງເພື່ອໃຫ້ບໍລິການບາງປະເພດ.

ມັນເປັນທີ່ຮູ້ຈັກກ່ຽວກັບວຽກງານນີ້: ມັນແມ່ນຫຍັງ, ວິທີການວັດແທກຄຸນນະພາບຂອງວຽກງານນີ້, ແລະສິ່ງທີ່ເປັນເງື່ອນໄຂສໍາລັບການວັດແທກຄຸນນະພາບນີ້.

ໃຫ້ສົມມຸດວ່າມັນເປັນທີ່ຮູ້ຈັກແລະເຂົ້າໃຈຫຼາຍຫຼືຫນ້ອຍ: ແນ່ນອນວ່າວິທີການເຮັດວຽກຢູ່ໃນ (ຫຼືກັບ) ລະບົບການບໍລິການນີ້.

"ຫຼາຍຫຼືຫນ້ອຍ" - ນີ້ຫມາຍຄວາມວ່າມັນເປັນໄປໄດ້ທີ່ຈະກະກຽມ (ຫຼືເອົາມັນມາຈາກບ່ອນໃດບ່ອນຫນຶ່ງ) ເຄື່ອງມືສະເພາະໃດຫນຶ່ງ, ຜົນປະໂຫຍດ, ການບໍລິການທີ່ສາມາດສັງເຄາະແລະນໍາໃຊ້ກັບລະບົບດ້ວຍການໂຫຼດການທົດສອບພຽງພໍກັບສິ່ງທີ່ຈະຜະລິດ, ໃນເງື່ອນໄຂທີ່ພຽງພໍສໍາລັບການເຮັດວຽກໃນການຜະລິດ.

ແລ້ວ, ໃຫ້ສົມມຸດວ່າຊຸດຂອງຕົວກໍານົດການປັບຕົວສໍາລັບລະບົບການບໍລິການນີ້ແມ່ນເປັນທີ່ຮູ້ຈັກ, ເຊິ່ງສາມາດນໍາໃຊ້ເພື່ອກໍານົດລະບົບນີ້ໃນແງ່ຂອງຜົນຜະລິດຂອງການເຮັດວຽກຂອງມັນ.

ແລະບັນຫາແມ່ນຫຍັງ - ບໍ່ມີຄວາມເຂົ້າໃຈຢ່າງພຽງພໍກ່ຽວກັບລະບົບການບໍລິການນີ້, ເຊິ່ງຊ່ວຍໃຫ້ທ່ານສາມາດກໍານົດການຕັ້ງຄ່າຂອງລະບົບນີ້ສໍາລັບການໂຫຼດໃນອະນາຄົດໃນເວທີທີ່ກໍານົດແລະໄດ້ຮັບຜົນຜະລິດຂອງລະບົບທີ່ຕ້ອງການ.

ດີ. ນີ້ແມ່ນເກືອບທຸກກໍລະນີ.

ເຈົ້າສາມາດເຮັດຫຍັງໄດ້ຢູ່ນີ້?

ດີ, ສິ່ງທໍາອິດທີ່ເຂົ້າມາໃນໃຈແມ່ນການເບິ່ງເອກະສານສໍາລັບລະບົບນີ້. ເຂົ້າໃຈວ່າຂອບເຂດທີ່ຍອມຮັບໄດ້ແມ່ນຫຍັງສໍາລັບຄ່າຂອງຕົວກໍານົດການປັບ. ແລະ, ສໍາລັບການຍົກຕົວຢ່າງ, ການນໍາໃຊ້ວິທີການ descent ປະສານງານ, ເລືອກຄ່າສໍາລັບຕົວກໍານົດການລະບົບໃນການທົດສອບ.

ເຫຼົ່ານັ້ນ. ໃຫ້ລະບົບບາງປະເພດຂອງການຕັ້ງຄ່າ, ໃນຮູບແບບຂອງຊຸດຄ່າສະເພາະສໍາລັບຕົວກໍານົດການຕັ້ງຂອງມັນ.

ນໍາໃຊ້ການໂຫຼດການທົດສອບກັບມັນ, ການນໍາໃຊ້ເຄື່ອງມືຫຼາຍ - ປະໂຫຍດນີ້, ເຄື່ອງກໍາເນີດການໂຫຼດ.
ແລະເບິ່ງມູນຄ່າ - ການຕອບສະຫນອງ, ຫຼື metric ຂອງຄຸນນະພາບຂອງລະບົບ.

ຄວາມຄິດທີສອງອາດຈະເປັນການສະຫລຸບວ່ານີ້ແມ່ນເວລາດົນນານຫຼາຍ.

ດີ, ນັ້ນແມ່ນ: ຖ້າມີຫຼາຍຕົວກໍານົດການ, ຖ້າຂອບເຂດຂອງຄ່າຂອງພວກມັນຖືກດໍາເນີນການແມ່ນໃຫຍ່, ຖ້າການທົດສອບການໂຫຼດແຕ່ລະຄົນໃຊ້ເວລາຫຼາຍເພື່ອໃຫ້ສໍາເລັດ, ຫຼັງຈາກນັ້ນ: ແມ່ນແລ້ວ, ທັງຫມົດນີ້ອາດຈະໃຊ້ເວລາທີ່ບໍ່ສາມາດຍອມຮັບໄດ້. ເວ​ລາ​ດົນ​ນານ.

ແລ້ວ, ນີ້ແມ່ນສິ່ງທີ່ເຈົ້າສາມາດເຂົ້າໃຈ ແລະຈື່ໄດ້.

ທ່ານສາມາດຄົ້ນພົບວ່າໃນຊຸດຂອງຄ່າຂອງຕົວກໍານົດການການຕັ້ງຄ່າລະບົບການບໍລິການມີ vector, ເປັນລໍາດັບຂອງບາງຄ່າ.

ແຕ່ລະ vector ດັ່ງກ່າວ, ສິ່ງອື່ນໆມີຄວາມເທົ່າທຽມກັນ (ໃນທີ່ມັນບໍ່ໄດ້ຮັບຜົນກະທົບຈາກ vector ນີ້), ເທົ່າກັບມູນຄ່າທີ່ແນ່ນອນຂອງ metric - ຕົວຊີ້ວັດຄຸນນະພາບຂອງການເຮັດວຽກຂອງລະບົບພາຍໃຕ້ການໂຫຼດການທົດສອບ.

Ie

ໃຫ້ພວກເຮົາສະແດງ vector ການຕັ້ງຄ່າລະບົບເປັນ ບ່ອນທີ່ ; ຢູ່ໃສ — ຈໍາ​ນວນ​ຂອງ​ຕົວ​ກໍາ​ນົດ​ການ​ຕັ້ງ​ຄ່າ​ລະ​ບົບ​, ຈໍາ​ນວນ​ຂອງ​ຕົວ​ກໍາ​ນົດ​ການ​ເຫຼົ່າ​ນີ້​ມີ​.

ແລະມູນຄ່າຂອງ metric ທີ່ສອດຄ້ອງກັນກັບເລື່ອງນີ້ ໃຫ້ໝາຍເຖິງມັນເປັນ
ຫຼັງຈາກນັ້ນ, ພວກເຮົາໄດ້ຮັບຫນ້າທີ່:

ແລ້ວ, ທຸກສິ່ງທຸກຢ່າງກໍ່ມາທັນທີ, ໃນກໍລະນີຂອງຂ້ອຍ: ເກືອບລືມຈາກມື້ນັກຮຽນຂອງຂ້ອຍ, ສູດການຄິດໄລ່ສໍາລັບການຊອກຫາຫນ້າທີ່ສູງສຸດ.

ຕົກລົງ, ແຕ່ໃນທີ່ນີ້ຄໍາຖາມກ່ຽວກັບການຈັດຕັ້ງແລະການນໍາໃຊ້ເກີດຂຶ້ນ: ສູດການຄິດໄລ່ທີ່ຈະໃຊ້.

1. ໃນຄວາມຫມາຍ - ເພື່ອໃຫ້ທ່ານສາມາດລະຫັດຫນ້ອຍລົງດ້ວຍມື.
2. ແລະເພື່ອໃຫ້ມັນເຮັດວຽກ, i.e. ພົບເຫັນ extremum (ຖ້າມີຫນຶ່ງ), ດີ, ຢ່າງຫນ້ອຍໄວກ່ວາການປະສານງານ descent.

ຈຸດທໍາອິດແນະນໍາວ່າພວກເຮົາຈໍາເປັນຕ້ອງຊອກຫາບາງສະພາບແວດລ້ອມທີ່ algorithms ດັ່ງກ່າວໄດ້ຖືກປະຕິບັດແລ້ວ, ແລະໃນບາງຮູບແບບ, ພ້ອມທີ່ຈະໃຊ້ໃນລະຫັດ.
ດີ, ຂ້ອຍຮູ້ python и cran-r

ຈຸດທີສອງຫມາຍຄວາມວ່າທ່ານຈໍາເປັນຕ້ອງໄດ້ອ່ານກ່ຽວກັບ algorithms ຕົວເອງ, ພວກມັນແມ່ນຫຍັງ, ຄວາມຕ້ອງການຂອງພວກເຂົາແມ່ນຫຍັງ, ລັກສະນະຂອງການເຮັດວຽກຂອງພວກເຂົາ.

ແລະສິ່ງທີ່ເຂົາເຈົ້າໃຫ້ສາມາດເປັນຜົນຂ້າງຄຽງທີ່ເປັນປະໂຫຍດ - ຜົນໄດ້ຮັບ, ຫຼືໂດຍກົງຈາກ algorithm ຕົວຂອງມັນເອງ.

ຫຼືພວກເຂົາສາມາດໄດ້ຮັບຈາກຜົນໄດ້ຮັບຂອງສູດການຄິດໄລ່.

ຫຼາຍຂື້ນກັບເງື່ອນໄຂການປ້ອນຂໍ້ມູນ.

ຕົວຢ່າງ, ຖ້າ, ສໍາລັບເຫດຜົນບາງຢ່າງ, ທ່ານຕ້ອງການຜົນໄດ້ຮັບໄວ, ດີ, ທ່ານຈໍາເປັນຕ້ອງຊອກຫາວິທີ gradient descent algorithms ແລະເລືອກຫນຶ່ງໃນນັ້ນ.

ຫຼື, ຖ້າເວລາບໍ່ສໍາຄັນ, ຕົວຢ່າງ, ທ່ານສາມາດໃຊ້ວິທີການເພີ່ມປະສິດທິພາບຂອງ stochastic, ເຊັ່ນ: ສູດການຄິດໄລ່ທາງພັນທຸກໍາ.

ຂ້າພະເຈົ້າສະເຫນີໃຫ້ພິຈາລະນາວຽກງານຂອງວິທີການນີ້, ການເລືອກການຕັ້ງຄ່າລະບົບ, ການນໍາໃຊ້ສູດການຄິດໄລ່ທາງພັນທຸກໍາ, ຕໍ່ໄປ, ດັ່ງນັ້ນການເວົ້າ: ການເຮັດວຽກຫ້ອງທົດລອງ.

ຕົ້ນສະບັບ:

1. ໃຫ້​ມີ​, ເປັນ​ລະ​ບົບ​ການ​ບໍ​ລິ​ການ​: oracle xe 18c
2. ໃຫ້ມັນຮັບໃຊ້ກິດຈະກໍາການເຮັດທຸລະກໍາແລະເປົ້າຫມາຍ: ເພື່ອໃຫ້ໄດ້ຮັບການສົ່ງຜ່ານສູງສຸດທີ່ເປັນໄປໄດ້ຂອງຖານຂໍ້ມູນຍ່ອຍ, ໃນທຸລະກໍາ / ວິນາທີ.
3. ການເຮັດທຸລະກໍາສາມາດແຕກຕ່າງກັນຫຼາຍໃນລັກສະນະຂອງການເຮັດວຽກກັບຂໍ້ມູນແລະສະພາບການຂອງການເຮັດວຽກ.
   ໃຫ້ຕົກລົງກັນວ່າເຫຼົ່ານີ້ແມ່ນການເຮັດທຸລະກໍາທີ່ບໍ່ໄດ້ດໍາເນີນການຈໍານວນຂະຫນາດໃຫຍ່ຂອງຂໍ້ມູນຕາຕະລາງ.
   ໃນຄວາມຮູ້ສຶກວ່າພວກເຂົາບໍ່ສ້າງຂໍ້ມູນ undo ຫຼາຍກ່ວາ redo ແລະບໍ່ປະມວນຜົນອັດຕາສ່ວນໃຫຍ່ຂອງແຖວແລະຕາຕະລາງຂະຫນາດໃຫຍ່.

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

ໃນສະຖານະການນີ້: ຜົນຜະລິດຂອງຖານຂໍ້ມູນຍ່ອຍສໍາລັບການປະມວນຜົນທຸລະກໍາຈະ, ດ້ວຍການຈອງ, ຖືກກໍານົດໂດຍຄຸນນະພາບຂອງການປຸງແຕ່ງໂດຍຖານຂໍ້ມູນ redox.

ການປະຕິເສດ - ຖ້າພວກເຮົາສົນທະນາໂດຍສະເພາະກ່ຽວກັບການຕັ້ງຄ່າ subdb.

ເນື່ອງຈາກວ່າ, ໃນກໍລະນີທົ່ວໄປ, ມັນອາດຈະມີການລັອກການເຮັດທຸລະກໍາລະຫວ່າງ SQL sessions, ເນື່ອງຈາກການອອກແບບຂອງຜູ້ໃຊ້ເຮັດວຽກກັບຂໍ້ມູນຕາຕະລາງແລະ / ຫຼືຮູບແບບຕາຕະລາງ.

ເຊິ່ງ, ແນ່ນອນ, ຈະມີຜົນກະທົບທີ່ຫນ້າເສົ້າໃຈຕໍ່ TPS metric ແລະນີ້ຈະເປັນປັດໃຈ exogenous, ທີ່ກ່ຽວຂ້ອງກັບ subdatabase: ດີ, ນີ້ແມ່ນວິທີທີ່ຕົວແບບຕາຕະລາງໄດ້ຖືກອອກແບບແລະເຮັດວຽກກັບຂໍ້ມູນໃນມັນທີ່ມີການຂັດຂວາງ.

ດັ່ງນັ້ນ, ສໍາລັບຄວາມບໍລິສຸດຂອງການທົດລອງ, ພວກເຮົາຈະຍົກເວັ້ນປັດໄຈນີ້, ແລະຂ້າງລຸ່ມນີ້ຂ້າພະເຈົ້າຈະຊີ້ແຈງຢ່າງແນ່ນອນ.

1. ໃຫ້ພວກເຮົາສົມມຸດວ່າ, ສໍາລັບຄໍານິຍາມ, 100% ຂອງຄໍາສັ່ງ SQL ທີ່ສົ່ງກັບຖານຂໍ້ມູນແມ່ນຄໍາສັ່ງ DML.
   ໃຫ້ຄຸນລັກສະນະຂອງຜູ້ໃຊ້ເຮັດວຽກກັບຖານຂໍ້ມູນຍ່ອຍຄືກັນໃນການທົດສອບ.
   ຄື: ຈໍານວນຂອງກອງປະຊຸມ skl, ຂໍ້ມູນຕາຕະລາງ, ວິທີການ skl sessions ເຮັດວຽກກັບເຂົາເຈົ້າ.
2. Subd ເຮັດວຽກຢູ່ໃນ FORCE LOGGING, ARCHIVELOG mods. ໂໝດ Flashback-ຖານຂໍ້ມູນຖືກປິດໄວ້, ໃນລະດັບຍ່ອຍ.
3. ບັນທຶກຂໍ້ມູນຄືນໃໝ່: ຕັ້ງຢູ່ໃນລະບົບໄຟລ໌ແຍກຕ່າງຫາກ, ໃນ “ແຜ່ນ” ແຍກຕ່າງຫາກ;
   ສ່ວນທີ່ເຫຼືອຂອງອົງປະກອບທາງກາຍະພາບຂອງຖານຂໍ້ມູນ: ໃນລະບົບໄຟລ໌ແຍກຕ່າງຫາກ, ໃນ "disk" ແຍກຕ່າງຫາກ:

ລາຍລະອຽດເພີ່ມເຕີມກ່ຽວກັບອຸປະກອນທາງດ້ານຮ່າງກາຍ. ອົງປະກອບຖານຂໍ້ມູນຫ້ອງທົດລອງ

SQL> select status||' '||name from v$controlfile;
 /db/u14/oradata/XE/control01.ctl
SQL> select GROUP#||' '||MEMBER from v$logfile;
1 /db/u02/oradata/XE/redo01_01.log
2 /db/u02/oradata/XE/redo02_01.log
SQL> select FILE_ID||' '||TABLESPACE_NAME||' '||round(BYTES/1024/1024,2)||' '||FILE_NAME as col from dba_data_files;
4 UNDOTBS1 2208 /db/u14/oradata/XE/undotbs1_01.dbf
2 SLOB 128 /db/u14/oradata/XE/slob01.dbf
7 USERS 5 /db/u14/oradata/XE/users01.dbf
1 SYSTEM 860 /db/u14/oradata/XE/system01.dbf
3 SYSAUX 550 /db/u14/oradata/XE/sysaux01.dbf
5 MONITOR 128 /db/u14/oradata/XE/monitor.dbf
SQL> !cat /proc/mounts | egrep "/db/u[0-2]"
/dev/vda1 /db/u14 ext4 rw,noatime,nodiratime,data=ordered 0 0
/dev/mapper/vgsys-ora_redo /db/u02 xfs rw,noatime,nodiratime,attr2,nobarrier,inode64,logbsize=256k,noquota 0 0

ໃນເບື້ອງຕົ້ນ, ພາຍໃຕ້ເງື່ອນໄຂການໂຫຼດເຫຼົ່ານີ້, ຂ້ອຍຕ້ອງການໃຊ້ທຸລະກໍາ subd SLOB-ປະໂຫຍດ
ມັນມີຄຸນສົມບັດທີ່ດີເລີດ, ຂ້າພະເຈົ້າຈະອ້າງເຖິງຜູ້ຂຽນ:

ຫົວໃຈຂອງ SLOB ແມ່ນ "ວິທີການ SLOB." ວິທີການ SLOB ມີຈຸດປະສົງເພື່ອທົດສອບເວທີ
ໂດຍບໍ່ມີການຂັດແຍ້ງກ່ຽວກັບຄໍາຮ້ອງສະຫມັກ. ຫນຶ່ງບໍ່ສາມາດຂັບລົດປະສິດທິພາບສູງສຸດຂອງຮາດແວ
ການນໍາໃຊ້ລະຫັດຄໍາຮ້ອງສະຫມັກທີ່ເປັນ, ສໍາລັບການຍົກຕົວຢ່າງ, ຜູກມັດໂດຍການລັອກຄໍາຮ້ອງສະຫມັກຫຼືແມ້ກະທັ້ງ
ການແບ່ງປັນຖານຂໍ້ມູນ Oracle. ຖືກຕ້ອງແລ້ວ—ມີສ່ວນເກີນເມື່ອແບ່ງປັນຂໍ້ມູນ
ໃນ​ຂໍ້​ມູນ​ຕັນ​! ແຕ່ SLOB - ໃນການປະຕິບັດໃນຕອນຕົ້ນຂອງມັນ - ມີພູມຕ້ານທານຕໍ່ການຂັດແຍ້ງດັ່ງກ່າວ.

ການປະກາດນີ້: ກົງກັນ, ມັນແມ່ນ.
ມັນສະດວກໃນການຄວບຄຸມລະດັບຄວາມຂະຫນານຂອງກອງປະຊຸມ cl, ນີ້ແມ່ນສໍາຄັນ -t ເປີດ​ປະ​ໂຫຍດ​ runit.sh ຈາກ SLOB
ເປີເຊັນຂອງຄໍາສັ່ງ DML ຖືກຄວບຄຸມ, ໃນຈໍານວນຂໍ້ຄວາມທີ່ຖືກສົ່ງໄປຫາ subd, ແຕ່ລະກອງປະຊຸມຂໍ້ຄວາມ, ພາລາມິເຕີ UPDATE_PCT
ແຍກຕ່າງຫາກແລະສະດວກຫຼາຍ: SLOB ຕົວຂອງມັນເອງ, ກ່ອນແລະຫຼັງຈາກກອງປະຊຸມການໂຫຼດ - ກະກຽມ statspack, ຫຼື awr-snapshots (ສິ່ງທີ່ຖືກກໍານົດໄວ້ເພື່ອກະກຽມ).

ຢ່າງໃດກໍຕາມ, ມັນໄດ້ຫັນອອກວ່າ SLOB ບໍ່ຮອງຮັບ SQL sessions ທີ່ມີໄລຍະເວລາຫນ້ອຍກວ່າ 30 ວິນາທີ.
ເພາະສະນັ້ນ, ທໍາອິດຂ້າພະເຈົ້າໄດ້ລະຫັດຂອງຕົນເອງ, ສະບັບແຮງງານ - peasant ຂອງ loader, ແລະຫຼັງຈາກນັ້ນມັນຍັງຄົງຢູ່ໃນການດໍາເນີນງານ.

ໃຫ້ຂ້ອຍຊີ້ແຈງສິ່ງທີ່ loader ເຮັດແລະເຮັດແນວໃດມັນເຮັດມັນ, ເພື່ອຄວາມຊັດເຈນ.
ໂດຍ​ພື້ນ​ຖານ​ແລ້ວ loader ເບິ່ງ​ຄື​ນີ້​:

ລະຫັດຄົນງານ

function dotx()
{
local v_period="$2"
[ -z "v_period" ] && v_period="0"
source "/home/oracle/testingredotracе/config.conf"

$ORACLE_HOME/bin/sqlplus -S system/${v_system_pwd} << __EOF__
whenever sqlerror exit failure
set verify off
set echo off
set feedback off

define wnum="$1"
define period="$v_period"
set appinfo worker_&&wnum

declare
 v_upto number;
 v_key  number;
 v_tots number;
 v_cts  number;
begin
 select max(col1) into v_upto from system.testtab_&&wnum;
 SELECT (( SYSDATE - DATE '1970-01-01' ) * 86400 ) into v_cts FROM DUAL;
 v_tots := &&period + v_cts;
 while v_cts <= v_tots
 loop
  v_key:=abs(mod(dbms_random.random,v_upto));
  if v_key=0 then
   v_key:=1;
  end if;
  update system.testtab_&&wnum t
  set t.object_name=translate(dbms_random.string('a', 120), 'abcXYZ', '158249')
  where t.col1=v_key
  ;
  commit;
  SELECT (( SYSDATE - DATE '1970-01-01' ) * 86400 ) into v_cts FROM DUAL;
 end loop;
end;
/

exit
__EOF__
}
export -f dotx

ຄົນງານຖືກເປີດຕົວດ້ວຍວິທີນີ້:

ພະນັກງານແລ່ນ

echo "starting test, duration: ${TEST_DURATION}" >> "$v_logfile"
for((i=1;i<="$SQLSESS_COUNT";i++))
do
 echo "sql-session: ${i}" >> "$v_logfile"
 dotx "$i" "${TEST_DURATION}" &
done
echo "waiting..." >> "$v_logfile"
wait

ແລະ​ໂຕະ​ສໍາ​ລັບ​ຄົນ​ງານ​ແມ່ນ​ໄດ້​ຮັບ​ການ​ກະ​ກຽມ​ດັ່ງ​ນີ້​:

ການສ້າງຕາຕະລາງ

function createtable() {
source "/home/oracle/testingredotracе/config.conf"
$ORACLE_HOME/bin/sqlplus -S system/${v_system_pwd} << __EOF__
whenever sqlerror continue
set verify off
set echo off
set feedback off

define wnum="$1"
define ts_name="slob"

begin
 execute immediate 'drop table system.testtab_&&wnum';
exception when others then null;
end;
/

create table system.testtab_&&wnum tablespace &&ts_name as
select rownum as col1, t.*
from sys.dba_objects t
where rownum<1000
;
create index testtab_&&wnum._idx on system.testtab_&&wnum (col1);
--alter table system.testtab_&&wnum nologging;
--alter index system.testtab_&&wnum._idx nologging;
exit
__EOF__
}
export -f createtable

seq 1 1 "$SQLSESS_COUNT" | xargs -n 1 -P 4 -I {} -t bash -c "createtable "{}"" | tee -a "$v_logfile"
echo "createtable done" >> "$v_logfile"

ເຫຼົ່ານັ້ນ. ສໍາລັບແຕ່ລະພະນັກງານ (ປະຕິບັດ: ກອງປະຊຸມ SQL ແຍກຕ່າງຫາກໃນ DB) ຕາຕະລາງແຍກຕ່າງຫາກແມ່ນຖືກສ້າງຂຶ້ນ, ເຊິ່ງພະນັກງານເຮັດວຽກ.

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

ສິ້ນຂອງບົດລາຍງານ statspack ທີ່ອະທິບາຍການດໍາເນີນງານຂອງ subd ພາຍໃຕ້ການໂຫຼດ

Database    DB Id    Instance     Inst Num  Startup Time   Release     RAC
~~~~~~~~ ----------- ------------ -------- --------------- ----------- ---
          2929910313 XE                  1 07-Sep-20 23:12 18.0.0.0.0  NO

Host Name             Platform                CPUs Cores Sockets   Memory (G)
~~~~ ---------------- ---------------------- ----- ----- ------- ------------
     billing.izhevsk1 Linux x86 64-bit           2     2       1         15.6

Snapshot       Snap Id     Snap Time      Sessions Curs/Sess Comment
~~~~~~~~    ---------- ------------------ -------- --------- ------------------
Begin Snap:       1630 07-Sep-20 23:12:27       55        .7
  End Snap:       1631 07-Sep-20 23:20:29       62        .6
   Elapsed:       8.03 (mins) Av Act Sess:       8.4
   DB time:      67.31 (mins)      DB CPU:      15.01 (mins)

Cache Sizes            Begin        End
~~~~~~~~~~~       ---------- ----------
    Buffer Cache:     1,392M              Std Block Size:         8K
     Shared Pool:       288M                  Log Buffer:   103,424K

Load Profile              Per Second    Per Transaction    Per Exec    Per Call
~~~~~~~~~~~~      ------------------  ----------------- ----------- -----------
      DB time(s):                8.4                0.0        0.00        0.20
       DB CPU(s):                1.9                0.0        0.00        0.04
       Redo size:        7,685,765.6              978.4
   Logical reads:           60,447.0                7.7
   Block changes:           47,167.3                6.0
  Physical reads:                8.3                0.0
 Physical writes:              253.4                0.0
      User calls:               42.6                0.0
          Parses:               23.2                0.0
     Hard parses:                1.2                0.0
W/A MB processed:                1.0                0.0
          Logons:                0.5                0.0
        Executes:           15,756.5                2.0
       Rollbacks:                0.0                0.0
    Transactions:            7,855.1

ກັບຄືນໄປເຮັດວຽກຫ້ອງທົດລອງ.
ພວກເຮົາຈະ, ສິ່ງອື່ນໆທີ່ເທົ່າທຽມກັນ, ແຕກຕ່າງກັນຄ່າຂອງຕົວກໍານົດການດັ່ງຕໍ່ໄປນີ້ຂອງ subdatabase ຫ້ອງທົດລອງ:

1. ຂະໜາດຂອງກຸ່ມບັນທຶກຖານຂໍ້ມູນ. ຊ່ວງມູນຄ່າ: [32, 1024] MB;
2. ຈໍານວນກຸ່ມວາລະສານໃນຖານຂໍ້ມູນ. ຊ່ວງມູນຄ່າ: [2,32];
3. log_archive_max_processes ຊ່ວງມູນຄ່າ: [1,8];
4. commit_logging ສອງ​ຄ່າ​ແມ່ນ​ອະ​ນຸ​ຍາດ​ໃຫ້​: batch|immediate;
5. commit_wait ສອງ​ຄ່າ​ແມ່ນ​ອະ​ນຸ​ຍາດ​ໃຫ້​: wait|nowait;
6. log_buffer ຊ່ວງມູນຄ່າ: [2,128] MB.
7. log_checkpoint_timeout ຊ່ວງມູນຄ່າ: [60,1200] ວິນາທີ
8. db_writer_processes ຊ່ວງ​ມູນ​ຄ່າ​: [1,4​]
9. undo_retention ຊ່ວງຄ່າ: [30;300] ວິນາທີ
10. transactions_per_rollback_segment ຊ່ວງ​ມູນ​ຄ່າ​: [1,8​]
11. disk_asynch_io ສອງ​ຄ່າ​ແມ່ນ​ອະ​ນຸ​ຍາດ​ໃຫ້​: true|false;
12. filesystemio_options ຄ່າຕໍ່ໄປນີ້ແມ່ນອະນຸຍາດໃຫ້: none|setall|directIO|asynch;
13. db_block_checking ຄ່າຕໍ່ໄປນີ້ແມ່ນອະນຸຍາດໃຫ້: OFF|LOW|MEDIUM|FULL;
14. db_block_checksum ຄ່າຕໍ່ໄປນີ້ແມ່ນອະນຸຍາດໃຫ້: OFF|TYPICAL|FULL;

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

ແຕ່.

ຈຸດຂອງການເຮັດວຽກຂອງຫ້ອງທົດລອງແມ່ນເພື່ອສະແດງໃຫ້ເຫັນວ່າວິທີການເພີ່ມປະສິດທິພາບຕົວມັນເອງຈະຊີ້ແຈງເລື່ອງນີ້ສໍາລັບພວກເຮົາຂ້ອນຂ້າງໄວ.

ສໍາລັບພວກເຮົາ, ທັງຫມົດທີ່ຍັງເຫຼືອແມ່ນເບິ່ງເຂົ້າໄປໃນເອກະສານ, ໂດຍຜ່ານລະບົບທີ່ສາມາດປັບແຕ່ງໄດ້, ພຽງແຕ່ພຽງພໍທີ່ຈະຊອກຫາສິ່ງທີ່ຕົວກໍານົດການທີ່ຈະປ່ຽນແປງແລະໃນຂອບເຂດໃດ.
ແລະຍັງ: ລະຫັດລະຫັດທີ່ຈະໃຊ້ເພື່ອເຮັດວຽກກັບລະບົບ custom ຂອງ algorithm ການເພີ່ມປະສິດທິພາບທີ່ເລືອກ.

ດັ່ງນັ້ນ, ໃນປັດຈຸບັນກ່ຽວກັບລະຫັດ.
ຂ້າພະເຈົ້າໄດ້ເວົ້າຂ້າງເທິງກ່ຽວກັບ cran-r, i.e.: ການຫມູນໃຊ້ທັງໝົດກັບລະບົບທີ່ກຳນົດເອງແມ່ນຖືກຈັດໃສ່ໃນຮູບແບບຂອງສະຄຣິບ R.

ວຽກງານຕົວຈິງ, ການວິເຄາະ, ການຄັດເລືອກໂດຍມູນຄ່າ metric, vectors ລັດລະບົບ: ນີ້ແມ່ນຊຸດ GA (ເອກະສານ)
ຊຸດ, ໃນກໍລະນີນີ້, ບໍ່ເຫມາະສົມຫຼາຍ, ໃນຄວາມຫມາຍທີ່ມັນຄາດຫວັງວ່າ vectors (chromosomes, ຖ້າຢູ່ໃນຂໍ້ກໍານົດຂອງຊຸດ) ຈະຖືກກໍານົດໃນຮູບແບບຂອງຊ່ອຍແນ່ຂອງຕົວເລກທີ່ມີສ່ວນເສດສ່ວນ.

ແລະ vector ຂອງຂ້ອຍ, ຈາກຄ່າຂອງຕົວກໍານົດການ: ເຫຼົ່ານີ້ແມ່ນ 14 ປະລິມານ - integers ແລະ string values ​​.

ບັນຫາ, ແນ່ນອນ, ໄດ້ຖືກຫຼີກເວັ້ນໄດ້ຢ່າງງ່າຍດາຍໂດຍການກໍານົດຕົວເລກສະເພາະບາງຢ່າງໃຫ້ກັບຄ່າສະຕຣິງ.

ດັ່ງນັ້ນ, ໃນທີ່ສຸດ, ຊິ້ນສ່ວນຕົ້ນຕໍຂອງຕົວອັກສອນ R ເບິ່ງຄືວ່ານີ້:

ໂທຫາ GA::ga

cat( "", file=v_logfile, sep="n", append=F)

pSize = 10
elitism_value=1
pmutation_coef=0.8
pcrossover_coef=0.1
iterations=50

gam=GA::ga(type="real-valued", fitness=evaluate,
lower=c(32,2, 1,1,1,2,60,1,30,1,0,0, 0,0), upper=c(1024,32, 8,10,10,128,800,4,300,8,10,40, 40,30),
popSize=pSize,
pcrossover = pcrossover_coef,
pmutation = pmutation_coef,
maxiter=iterations,
run=4,
keepBest=T)
cat( "GA-session is done" , file=v_logfile, sep="n", append=T)
gam@solution

ທີ່ນີ້, ດ້ວຍການຊ່ວຍເຫຼືອ lower и upper ຄຸນລັກສະນະຍ່ອຍ ga ໂດຍພື້ນຖານແລ້ວ, ພື້ນທີ່ຂອງພື້ນທີ່ຄົ້ນຫາແມ່ນຖືກກໍານົດ, ເຊິ່ງໃນນັ້ນການຄົ້ນຫາຈະຖືກປະຕິບັດສໍາລັບ vectors (ຫຼື vectors) ເຊິ່ງມູນຄ່າສູງສຸດຂອງຫນ້າທີ່ສອດຄ່ອງຈະໄດ້ຮັບ.

routine ຍ່ອຍຂອງ ga ດໍາເນີນການຄົ້ນຫາເພື່ອເພີ່ມປະສິດທິພາບສູງສຸດ.

ແລ້ວ, ມັນ turns ໃຫ້ເຫັນວ່າ, ໃນກໍລະນີນີ້, ມັນເປັນສິ່ງຈໍາເປັນທີ່ຫນ້າທີ່ສອດຄ່ອງ, ຄວາມເຂົ້າໃຈ vector ເປັນຊຸດຂອງຄ່າສໍາລັບຕົວກໍານົດການສະເພາະໃດຫນຶ່ງຂອງ subd, ໄດ້ຮັບ metric ຈາກ subd ໄດ້.

ນັ້ນແມ່ນ: ຈໍານວນເທົ່າໃດ, ດ້ວຍການຕັ້ງຄ່າ subd ແລະການໂຫຼດທີ່ໃຫ້ຢູ່ໃນ subd: subd ດໍາເນີນທຸລະກໍາຕໍ່ວິນາທີ.

ນັ້ນແມ່ນ, ເມື່ອເປີດເຜີຍ, ຫຼາຍຂັ້ນຕອນຕໍ່ໄປນີ້ຕ້ອງຖືກປະຕິບັດພາຍໃນຫນ້າທີ່ສອດຄ່ອງກັບ:

1. ການປະມວນຜົນ vector ການປ້ອນຂໍ້ມູນຂອງຕົວເລກ - ການແປງມັນເປັນຄ່າສໍາລັບຕົວກໍານົດການຍ່ອຍຂໍ້ມູນ.
2. ຄວາມພະຍາຍາມທີ່ຈະສ້າງຈໍານວນກຸ່ມ redo ຂອງຂະຫນາດທີ່ກໍານົດໄວ້. ຍິ່ງໄປກວ່ານັ້ນ, ຄວາມພະຍາຍາມອາດຈະບໍ່ປະສົບຜົນສໍາເລັດ.
   ກຸ່ມວາລະສານທີ່ມີຢູ່ແລ້ວໃນ subd, ໃນບາງປະລິມານແລະບາງຂະຫນາດ, ສໍາລັບຄວາມບໍລິສຸດຂອງການທົດລອງ - d.b. ລຶບແລ້ວ.
3. ຖ້າຈຸດທີ່ຜ່ານມາປະສົບຜົນສໍາເລັດ: ການລະບຸຄ່າຂອງພາລາມິເຕີການຕັ້ງຄ່າກັບຖານຂໍ້ມູນ (ອີກເທື່ອຫນຶ່ງ: ອາດຈະມີຄວາມລົ້ມເຫລວ)
4. ຖ້າຂັ້ນຕອນທີ່ຜ່ານມາປະສົບຜົນສໍາເລັດ: ການຢຸດ subd, ເລີ່ມຕົ້ນ subd ເພື່ອໃຫ້ຄ່າພາລາມິເຕີທີ່ກໍານົດໃຫມ່ມີຜົນ. (ອີກ​ເທື່ອ​ຫນຶ່ງ​: ອາດ​ຈະ​ມີ​ຄວາມ​ຜິດ​ພາດ​)
5. ຖ້າຂັ້ນຕອນທີ່ຜ່ານມາປະສົບຜົນສໍາເລັດ: ປະຕິບັດການທົດສອບການໂຫຼດ. ໄດ້ຮັບ metrics ຈາກ subd.
6. ກັບຄືນ subd ກັບສະພາບເດີມຂອງມັນ, i.e. ລຶບກຸ່ມບັນທຶກເພີ່ມເຕີມ, ສົ່ງຄືນການຕັ້ງຄ່າຖານຂໍ້ມູນຍ່ອຍຕົ້ນສະບັບໃຫ້ເຮັດວຽກ.

ລະຫັດຟັງຊັນຟິດເນສ

evaluate=function(p_par) {
v_module="evaluate"
v_metric=0
opn=NULL
opn$rg_size=round(p_par[1],digit=0)
opn$rg_count=round(p_par[2],digit=0)
opn$log_archive_max_processes=round(p_par[3],digit=0)
opn$commit_logging="BATCH"
if ( round(p_par[4],digit=0) > 5 ) {
 opn$commit_logging="IMMEDIATE"
}
opn$commit_logging=paste("'", opn$commit_logging, "'",sep="")

opn$commit_wait="WAIT"
if ( round(p_par[5],digit=0) > 5 ) {
 opn$commit_wait="NOWAIT"
}
opn$commit_wait=paste("'", opn$commit_wait, "'",sep="")

opn$log_buffer=paste(round(p_par[6],digit=0),"m",sep="")
opn$log_checkpoint_timeout=round(p_par[7],digit=0)
opn$db_writer_processes=round(p_par[8],digit=0)
opn$undo_retention=round(p_par[9],digit=0)
opn$transactions_per_rollback_segment=round(p_par[10],digit=0)
opn$disk_asynch_io="true"
if ( round(p_par[11],digit=0) > 5 ) {
 opn$disk_asynch_io="false"
} 

opn$filesystemio_options="none"
if ( round(p_par[12],digit=0) > 10 && round(p_par[12],digit=0) <= 20 ) {
 opn$filesystemio_options="setall"
}
if ( round(p_par[12],digit=0) > 20 && round(p_par[12],digit=0) <= 30 ) {
 opn$filesystemio_options="directIO"
}
if ( round(p_par[12],digit=0) > 30 ) {
 opn$filesystemio_options="asynch"
}

opn$db_block_checking="OFF"
if ( round(p_par[13],digit=0) > 10 && round(p_par[13],digit=0) <= 20 ) {
 opn$db_block_checking="LOW"
}
if ( round(p_par[13],digit=0) > 20 && round(p_par[13],digit=0) <= 30 ) {
 opn$db_block_checking="MEDIUM"
}
if ( round(p_par[13],digit=0) > 30 ) {
 opn$db_block_checking="FULL"
}

opn$db_block_checksum="OFF"
if ( round(p_par[14],digit=0) > 10 && round(p_par[14],digit=0) <= 20 ) {
 opn$db_block_checksum="TYPICAL"
}
if ( round(p_par[14],digit=0) > 20 ) {
 opn$db_block_checksum="FULL"
}

v_vector=paste(round(p_par[1],digit=0),round(p_par[2],digit=0),round(p_par[3],digit=0),round(p_par[4],digit=0),round(p_par[5],digit=0),round(p_par[6],digit=0),round(p_par[7],digit=0),round(p_par[8],digit=0),round(p_par[9],digit=0),round(p_par[10],digit=0),round(p_par[11],digit=0),round(p_par[12],digit=0),round(p_par[13],digit=0),round(p_par[14],digit=0),sep=";")
cat( paste(v_module," try to evaluate vector: ", v_vector,sep="") , file=v_logfile, sep="n", append=T)

rc=make_additional_rgroups(opn)
if ( rc!=0 ) {
 cat( paste(v_module,"make_additional_rgroups failed",sep="") , file=v_logfile, sep="n", append=T)
 return (0)
}

v_rc=0
rc=set_db_parameter("log_archive_max_processes", opn$log_archive_max_processes)
if ( rc != 0 ) {  v_rc=1 }
rc=set_db_parameter("commit_logging", opn$commit_logging )
if ( rc != 0 ) {  v_rc=1 }
rc=set_db_parameter("commit_wait", opn$commit_wait )
if ( rc != 0 ) {  v_rc=1 }
rc=set_db_parameter("log_buffer", opn$log_buffer )
if ( rc != 0 ) {  v_rc=1 }
rc=set_db_parameter("log_checkpoint_timeout", opn$log_checkpoint_timeout )
if ( rc != 0 ) {  v_rc=1 }
rc=set_db_parameter("db_writer_processes", opn$db_writer_processes )
if ( rc != 0 ) {  v_rc=1 }
rc=set_db_parameter("undo_retention", opn$undo_retention )
if ( rc != 0 ) {  v_rc=1 }
rc=set_db_parameter("transactions_per_rollback_segment", opn$transactions_per_rollback_segment )
if ( rc != 0 ) {  v_rc=1 }
rc=set_db_parameter("disk_asynch_io", opn$disk_asynch_io )
if ( rc != 0 ) {  v_rc=1 }
rc=set_db_parameter("filesystemio_options", opn$filesystemio_options )
if ( rc != 0 ) {  v_rc=1 }
rc=set_db_parameter("db_block_checking", opn$db_block_checking )
if ( rc != 0 ) {  v_rc=1 }
rc=set_db_parameter("db_block_checksum", opn$db_block_checksum )
if ( rc != 0 ) {  v_rc=1 }

if ( rc!=0 ) {
 cat( paste(v_module," can not startup db with that vector of settings",sep="") , file=v_logfile, sep="n", append=T)
 rc=stop_db("immediate")
 rc=create_spfile()
 rc=start_db("")
 rc=remove_additional_rgroups(opn)
 return (0)
}

rc=stop_db("immediate")
rc=start_db("")
if ( rc!=0 ) {
 cat( paste(v_module," can not startup db with that vector of settings",sep="") , file=v_logfile, sep="n", append=T)
 rc=stop_db("abort")
 rc=create_spfile()
 rc=start_db("")
 rc=remove_additional_rgroups(opn)
 return (0)
}

rc=run_test()
v_metric=getmetric()

rc=stop_db("immediate")
rc=create_spfile()
rc=start_db("")
rc=remove_additional_rgroups(opn)

cat( paste("result: ",v_metric," ",v_vector,sep="") , file=v_logfile, sep="n", append=T)
return (v_metric)
}

ນັ້ນ. ການເຮັດວຽກທັງຫມົດ: ປະຕິບັດໃນຫນ້າທີ່ອອກກໍາລັງກາຍ.

ga-subroutine ປະມວນຜົນ vectors, ຫຼື, ຢ່າງຖືກຕ້ອງ, chromosomes.
ໃນນັ້ນ, ສິ່ງທີ່ ສຳ ຄັນທີ່ສຸດ ສຳ ລັບພວກເຮົາແມ່ນການເລືອກໂຄໂມໂຊມທີ່ມີພັນທຸ ກຳ ທີ່ ໜ້າ ທີ່ການອອກ ກຳ ລັງກາຍສ້າງຄຸນຄ່າອັນໃຫຍ່ຫຼວງ.

ໂດຍເນື້ອແທ້ແລ້ວ, ນີ້ແມ່ນຂະບວນການຊອກຫາຊຸດໂຄໂມໂຊມທີ່ດີທີ່ສຸດໂດຍໃຊ້ vector ໃນພື້ນທີ່ຄົ້ນຫາ N-dimensional.

ຊັດເຈນຫຼາຍ, ລະອຽດ ຄຳ ອະທິບາຍ, ດ້ວຍຕົວຢ່າງຂອງລະຫັດ R, ການເຮັດວຽກຂອງສູດການຄິດໄລ່ທາງພັນທຸກໍາ.

ຂ້າພະເຈົ້າຢາກຈະສັງເກດເຫັນສອງຈຸດດ້ານວິຊາການແຍກຕ່າງຫາກ.

ໂທເສີມຈາກຟັງຊັນ evaluate, ສໍາລັບການຍົກຕົວຢ່າງ, ການຢຸດເຊົາການເລີ່ມຕົ້ນ, ການກໍານົດຄ່າຂອງຕົວກໍານົດການ subd, ແມ່ນປະຕິບັດໂດຍອີງໃສ່ cran-r ຫນ້າທີ່ system2

ດ້ວຍການຊ່ວຍເຫຼືອຂອງທີ່: ບາງ bash script ຫຼືຄໍາສັ່ງຖືກເອີ້ນ.

ຕົວຢ່າງ:

set_db_parameter

set_db_parameter=function(p1, p2) {
v_module="set_db_parameter"
v_cmd="/home/oracle/testingredotracе/set_db_parameter.sh"
v_args=paste(p1," ",p2,sep="")

x=system2(v_cmd, args=v_args, stdout=T, stderr=T, wait=T)
if ( length(attributes(x)) > 0 ) {
 cat(paste(v_module," failed with: ",attributes(x)$status," ",v_cmd," ",v_args,sep=""), file=v_logfile, sep="n", append=T)
 return (attributes(x)$status)
}
else {
 cat(paste(v_module," ok: ",v_cmd," ",v_args,sep=""), file=v_logfile, sep="n", append=T)
 return (0)
}
}

ຈຸດທີສອງແມ່ນເສັ້ນ, evaluate ຟັງຊັນ, ດ້ວຍການປະຫຍັດຄ່າ metric ສະເພາະແລະ vector tuning ທີ່ສອດຄ້ອງກັນກັບໄຟລ໌ບັນທຶກ:

cat( paste("result: ",v_metric," ",v_vector,sep="") , file=v_logfile, sep="n", append=T)

ນີ້ແມ່ນສິ່ງສໍາຄັນ, ເພາະວ່າຈາກ array ຂໍ້ມູນນີ້, ມັນຈະເປັນໄປໄດ້ທີ່ຈະໄດ້ຮັບຂໍ້ມູນເພີ່ມເຕີມກ່ຽວກັບອົງປະກອບໃດຂອງ vector tuning ມີຜົນກະທົບຫຼາຍຫຼືຫນ້ອຍກ່ຽວກັບຄ່າ metric.

ນັ້ນແມ່ນ: ມັນຈະເປັນໄປໄດ້ທີ່ຈະປະຕິບັດການວິເຄາະຄຸນລັກສະນະການນໍາເຂົ້າ.

ດັ່ງນັ້ນສິ່ງທີ່ສາມາດເກີດຂຶ້ນ?

ໃນ​ຮູບ​ແບບ​ກາ​ຟ​, ຖ້າ​ຫາກ​ວ່າ​ທ່ານ​ກໍາ​ນົດ​ການ​ທົດ​ສອບ​ໃນ​ລໍາ​ດັບ metric ຕັ້ງ​ຊັນ​ຂຶ້ນ​, ຮູບ​ພາບ​ດັ່ງ​ຕໍ່​ໄປ​ນີ້​:

ຂໍ້ມູນບາງຢ່າງທີ່ສອດຄ້ອງກັບຄ່າສູງສຸດຂອງ metric:

ທີ່ນີ້, ໃນ screenshot ກັບຜົນໄດ້ຮັບ, ຂ້າພະເຈົ້າຈະຊີ້ແຈງ: ຄ່າຂອງ vector tuning ແມ່ນໃຫ້ຢູ່ໃນຂໍ້ກໍານົດຂອງລະຫັດການທໍາງານການສອດຄ່ອງກັບ, ບໍ່ແມ່ນໃນຂໍ້ກໍານົດຂອງບັນຊີລາຍຊື່ຂອງຕົວກໍານົດການ / ໄລຍະຂອງຄ່າພາລາມິເຕີ, ເຊິ່ງໄດ້ຖືກສ້າງຂື້ນ. ຂ້າງເທິງໃນຂໍ້ຄວາມ.

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

ນະໂຍບາຍດ້ານຢູ່ທີ່ນີ້ແມ່ນດີ.
ມັນເປັນທີ່ຊັດເຈນວ່າຢ່າງຫນ້ອຍຫນຶ່ງປັດໄຈທີ່ມີອິດທິພົນຢ່າງຫຼວງຫຼາຍຕໍ່ມູນຄ່າຂອງ metric, ga-algorithm, ການຈັດຮຽງໂດຍຜ່ານ vectors chromosome: ກວມເອົາ.
ການຕັດສິນໂດຍນະໂຍບາຍດ້ານທີ່ເຂັ້ມແຂງພໍສົມຄວນຂອງຄ່າເສັ້ນໂຄ້ງ, ມີຢ່າງຫນ້ອຍຫນຶ່ງປັດໃຈເພີ່ມເຕີມທີ່, ເຖິງແມ່ນວ່າມີຂະຫນາດນ້ອຍກວ່າ, ມີອິດທິພົນ.

ນີ້ແມ່ນບ່ອນທີ່ທ່ານຕ້ອງການ attribute-importance ການວິເຄາະເພື່ອເຂົ້າໃຈວ່າຄຸນລັກສະນະໃດ (ດີ, ໃນກໍລະນີນີ້, ອົງປະກອບຂອງ vector tuning) ແລະວິທີການທີ່ມີອິດທິພົນຕໍ່ຄ່າ metric.
ແລະຈາກຂໍ້ມູນນີ້: ເຂົ້າໃຈວ່າປັດໃຈໃດໄດ້ຮັບຜົນກະທົບຈາກການປ່ຽນແປງຄຸນລັກສະນະທີ່ສໍາຄັນ.

ການດໍາເນີນງານ attribute-importance ເປັນໄປໄດ້ໃນທາງທີ່ແຕກຕ່າງກັນ.

ສໍາລັບຈຸດປະສົງເຫຼົ່ານີ້, ຂ້າພະເຈົ້າມັກ algorithm randomForest ຊຸດ R ຂອງຊື່ດຽວກັນ (ເອກະສານ)
randomForest, ດັ່ງທີ່ຂ້ອຍເຂົ້າໃຈວຽກງານຂອງລາວໂດຍທົ່ວໄປແລະວິທີການຂອງລາວໃນການປະເມີນຄວາມສໍາຄັນຂອງຄຸນລັກສະນະໂດຍສະເພາະ, ກໍ່ສ້າງຕົວແບບທີ່ແນ່ນອນຂອງການເພິ່ງພາອາໄສຂອງຕົວແປການຕອບສະຫນອງຕໍ່ຄຸນລັກສະນະ.

ໃນ​ກໍ​ລະ​ນີ​ຂອງ​ພວກ​ເຮົາ​, ຕົວ​ແປ​ຕອບ​ສະ​ຫນອງ​ແມ່ນ​ຕົວ​ຊີ້​ວັດ​ທີ່​ໄດ້​ຮັບ​ຈາກ​ຖານ​ຂໍ້​ມູນ​ໃນ​ການ​ທົດ​ສອບ​ການ​ໂຫຼດ​: tps;
ແລະຄຸນລັກສະນະແມ່ນອົງປະກອບຂອງ vector tuning.

ສະນັ້ນຢູ່ນີ້ randomForest ປະເມີນຄວາມສໍາຄັນຂອງຄຸນລັກສະນະຂອງແຕ່ລະຕົວແບບທີ່ມີສອງຕົວເລກ: %IncMSE — ວິ​ທີ​ການ​ທີ່​ມີ​ຢູ່ / ບໍ່​ມີ​ຄຸນ​ສົມ​ບັດ​ນີ້​ໃນ​ຕົວ​ແບບ​ການ​ປ່ຽນ​ແປງ​ຄຸນ​ນະ​ພາບ MSE ຂອງ​ຕົວ​ແບບ​ນີ້ (Mean Squared Error);

ແລະ IncNodePurity ແມ່ນຕົວເລກທີ່ສະທ້ອນເຖິງວິທີການທີ່ດີ, ໂດຍອີງໃສ່ຄຸນຄ່າຂອງຄຸນລັກສະນະນີ້, ຊຸດຂໍ້ມູນທີ່ມີການສັງເກດສາມາດແບ່ງອອກໄດ້, ດັ່ງນັ້ນໃນສ່ວນຫນຶ່ງມີຂໍ້ມູນທີ່ມີຄ່າຫນຶ່ງຂອງ metric ຖືກອະທິບາຍ, ແລະອີກສ່ວນຫນຶ່ງມີຂໍ້ມູນ. ຄ່າອື່ນຂອງ metric.
ແລ້ວ, ນັ້ນແມ່ນ: ນີ້ແມ່ນຄຸນລັກສະນະການຈັດປະເພດໃນລະດັບໃດ (ຂ້ອຍໄດ້ເຫັນຄໍາອະທິບາຍພາສາລັດເຊຍທີ່ຊັດເຈນທີ່ສຸດຢູ່ໃນ RandomForest. ທີ່ນີ້).

Worker-peasant R-code ສໍາລັບການປະມວນຜົນຊຸດຂໍ້ມູນທີ່ມີຜົນຂອງການທົດສອບການໂຫຼດ:

x=NULL
v_data_file=paste('/tmp/data1.dat',sep="")
x=read.table(v_data_file, header = TRUE, sep = ";", dec=",", quote = ""'", stringsAsFactors=FALSE)
colnames(x)=c('metric','rgsize','rgcount','lamp','cmtl','cmtw','lgbffr','lct','dbwrp','undo_retention','tprs','disk_async_io','filesystemio_options','db_block_checking','db_block_checksum')

idxTrain=sample(nrow(x),as.integer(nrow(x)*0.7))
idxNotTrain=which(! 1:nrow(x) %in% idxTrain )
TrainDS=x[idxTrain,]
ValidateDS=x[idxNotTrain,]

library(randomForest)
#mtry=as.integer( sqrt(dim(x)[2]-1) )
rf=randomForest(metric ~ ., data=TrainDS, ntree=40, mtry=3, replace=T, nodesize=2, importance=T, do.trace=10, localImp=F)
ValidateDS$predicted=predict(rf, newdata=ValidateDS[,colnames(ValidateDS)!="metric"], type="response")
sum((ValidateDS$metric-ValidateDS$predicted)^2)
rf$importance

ທ່ານສາມາດເລືອກ hyperparameters ຂອງ algorithm ໂດຍກົງດ້ວຍມືຂອງທ່ານແລະ, ສຸມໃສ່ຄຸນນະພາບຂອງຕົວແບບ, ເລືອກຕົວແບບທີ່ປະຕິບັດໄດ້ຢ່າງຖືກຕ້ອງຕາມການຄາດຄະເນກ່ຽວກັບຊຸດຂໍ້ມູນທີ່ຖືກຕ້ອງ.
ທ່ານສາມາດຂຽນບາງປະເພດສໍາລັບການເຮັດວຽກນີ້ (ໂດຍວິທີທາງການ, ອີກເທື່ອຫນຶ່ງ, ການນໍາໃຊ້ບາງປະເພດຂອງວິທີການເພີ່ມປະສິດທິພາບ).

ທ່ານສາມາດນໍາໃຊ້ຊຸດ R caret, ບໍ່ແມ່ນຈຸດສໍາຄັນ.

ດັ່ງນັ້ນ, ໃນກໍລະນີນີ້, ຜົນໄດ້ຮັບຕໍ່ໄປນີ້ແມ່ນໄດ້ຮັບເພື່ອປະເມີນລະດັບຄວາມສໍາຄັນຂອງຄຸນລັກສະນະ:

ດີ. ດັ່ງນັ້ນ, ພວກເຮົາສາມາດເລີ່ມຕົ້ນການສະທ້ອນທົ່ວໂລກ:

1. ມັນ turns ໃຫ້​ເຫັນ​ວ່າ​ທີ່​ສໍາ​ຄັນ​ທີ່​ສຸດ​, ພາຍ​ໃຕ້​ເງື່ອນ​ໄຂ​ການ​ທົດ​ສອບ​ເຫຼົ່າ​ນີ້​, ແມ່ນ​ຕົວ​ກໍາ​ນົດ​ການ​ commit_wait
   ທາງດ້ານເທກນິກ, ມັນກໍານົດຮູບແບບການປະຕິບັດຂອງການດໍາເນີນງານ io ຂອງການຂຽນຂໍ້ມູນ redo ຈາກ subdb log buffer ໄປຫາກຸ່ມບັນທຶກປະຈຸບັນ: synchronous ຫຼື asynchronous.
   ມູນຄ່າ nowait ເຊິ່ງສົ່ງຜົນໃຫ້ເກືອບແນວຕັ້ງ, ເພີ່ມຂຶ້ນຫຼາຍໃນມູນຄ່າຂອງ tps metric: ນີ້ແມ່ນການລວມເອົາໂຫມດ io asynchronous ໃນກຸ່ມ redo.
   ຄໍາຖາມແຍກຕ່າງຫາກແມ່ນວ່າທ່ານຄວນຈະເຮັດແນວນີ້ຫຼືບໍ່ໃນຖານຂໍ້ມູນອາຫານ. ໃນທີ່ນີ້ຂ້າພະເຈົ້າຈໍາກັດຕົວເອງພຽງແຕ່ເວົ້າວ່າ: ນີ້ແມ່ນປັດໃຈສໍາຄັນ.
2. ມັນເປັນເຫດຜົນວ່າຂະຫນາດຂອງ log buffer ຂອງ subd: ກາຍເປັນປັດໃຈສໍາຄັນ.
   ຂະໜາດຂອງບັຟເຟີບັນທຶກທີ່ນ້ອຍລົງ, ຄວາມອາດສາມາດ buffering ຂອງມັນໜ້ອຍລົງ, ມັນມັກຈະລົ້ນ ແລະ/ຫຼື ການບໍ່ສາມາດຈັດສັນພື້ນທີ່ຫວ່າງໃນມັນໃຫ້ກັບບາງສ່ວນຂອງຂໍ້ມູນ redox ໃໝ່.
   ນີ້ຫມາຍຄວາມວ່າ: ຄວາມລ່າຊ້າທີ່ກ່ຽວຂ້ອງກັບການຈັດສັນພື້ນທີ່ໃນ log buffer ແລະ / ຫຼື dumping redo ຂໍ້ມູນຈາກມັນເຂົ້າໄປໃນ redo ກຸ່ມ.
   ຄວາມລ່າຊ້າເຫຼົ່ານີ້, ແນ່ນອນ, ຄວນແລະຜົນກະທົບຕໍ່ການຜ່ານຖານຂໍ້ມູນສໍາລັບການເຮັດທຸລະກໍາ.
3. Parameter db_block_checksum: ດີ, ຍັງ, ໂດຍທົ່ວໄປມັນຈະແຈ້ງ - ການປະມວນຜົນທຸລະກໍານໍາໄປສູ່ການສ້າງຕັ້ງຂອງ darty blocks ໃນ subdatabase ຂອງ buffer cache.
   ເຊິ່ງ, ເມື່ອກວດເບິ່ງ checksums ຂອງ datablocks ຖືກເປີດໃຊ້, ຖານຂໍ້ມູນຕ້ອງດໍາເນີນການ - ຄິດໄລ່ checksums ເຫຼົ່ານີ້ຈາກຮ່າງກາຍຂອງ datablock, ກວດເບິ່ງພວກມັນດ້ວຍສິ່ງທີ່ຂຽນໄວ້ໃນ header datablock: ກົງກັນ / ບໍ່ກົງກັນ.
   ການເຮັດວຽກດັ່ງກ່າວ, ອີກເທື່ອຫນຶ່ງ, ບໍ່ສາມາດຊັກຊ້າການປະມວນຜົນຂໍ້ມູນ, ແລະຕາມຄວາມເຫມາະສົມ, ພາລາມິເຕີແລະກົນໄກທີ່ກໍານົດພາລາມິເຕີນີ້ໄດ້ກາຍເປັນທີ່ສໍາຄັນ.
   ນັ້ນແມ່ນເຫດຜົນທີ່ຜູ້ຂາຍສະເຫນີ, ໃນເອກະສານສໍາລັບພາລາມິເຕີນີ້, ຄ່າທີ່ແຕກຕ່າງກັນສໍາລັບມັນ (ພາລາມິເຕີ) ແລະສັງເກດວ່າແມ່ນແລ້ວ, ມັນຈະມີຜົນກະທົບ, ແຕ່, ດີ, ທ່ານສາມາດເລືອກຄ່າທີ່ແຕກຕ່າງກັນ, ເຖິງ "ປິດ" ແລະ. ຜົນກະທົບທີ່ແຕກຕ່າງກັນ.

ດີ, ການສະຫລຸບທົ່ວໂລກ.

ວິທີການ, ໂດຍທົ່ວໄປ, turns ອອກຈະເຮັດວຽກຂ້ອນຂ້າງ.

ລາວຂ້ອນຂ້າງອະນຸຍາດໃຫ້ຕົນເອງ, ໃນໄລຍະຕົ້ນຂອງການທົດສອບການໂຫຼດຂອງລະບົບການບໍລິການສະເພາະໃດຫນຶ່ງ, ໃນຄໍາສັ່ງທີ່ຈະເລືອກເອົາ (ລະບົບ) ການຕັ້ງຄ່າທີ່ດີທີ່ສຸດຂອງຕົນສໍາລັບການໂຫຼດ, ບໍ່ delve ຫຼາຍເກີນໄປເຂົ້າໄປໃນສະເພາະຂອງການຕິດຕັ້ງລະບົບສໍາລັບການໂຫຼດໄດ້.

ແຕ່ມັນບໍ່ໄດ້ຍົກເວັ້ນມັນຢ່າງສົມບູນ - ຢ່າງຫນ້ອຍໃນລະດັບຄວາມເຂົ້າໃຈ: ລະບົບຈະຕ້ອງຮູ້ກ່ຽວກັບ "ລູກບິດປັບ" ແລະຂອບເຂດທີ່ອະນຸຍາດຂອງການຫມຸນຂອງລູກບິດເຫຼົ່ານີ້.

ວິທີການດັ່ງກ່າວສາມາດຊອກຫາການຕັ້ງຄ່າລະບົບທີ່ດີທີ່ສຸດໄດ້ໄວ.
ແລະອີງໃສ່ຜົນຂອງການທົດສອບ, ມັນເປັນໄປໄດ້ທີ່ຈະໄດ້ຮັບຂໍ້ມູນກ່ຽວກັບລັກສະນະຂອງການພົວພັນລະຫວ່າງຕົວວັດແທກການປະຕິບັດລະບົບແລະຄ່າຂອງຕົວກໍານົດການປັບລະບົບ.

ເຊິ່ງ, ແນ່ນອນ, ຄວນປະກອບສ່ວນເຂົ້າໃນການເກີດໃຫມ່ຂອງຄວາມເຂົ້າໃຈຢ່າງເລິກເຊິ່ງຂອງລະບົບ, ການດໍາເນີນງານຂອງມັນ, ຢ່າງຫນ້ອຍພາຍໃຕ້ການໂຫຼດ.

ໃນການປະຕິບັດ, ນີ້ແມ່ນການແລກປ່ຽນຄ່າໃຊ້ຈ່າຍໃນການເຂົ້າໃຈລະບົບທີ່ກໍາຫນົດເອງສໍາລັບຄ່າໃຊ້ຈ່າຍໃນການກະກຽມການທົດສອບດັ່ງກ່າວຂອງລະບົບ.

ຂ້າພະເຈົ້າຢາກຈະສັງເກດເຫັນແຍກຕ່າງຫາກ: ໃນວິທີການນີ້, ລະດັບຄວາມພຽງພໍຂອງການທົດສອບລະບົບກັບເງື່ອນໄຂການດໍາເນີນງານທີ່ມັນຈະມີໃນການດໍາເນີນງານທາງການຄ້າແມ່ນມີຄວາມສໍາຄັນຫຼາຍ.

ຂອບໃຈສໍາລັບຄວາມສົນໃຈແລະເວລາຂອງທ່ານ.

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