"Нас Атакуют!" Изобличи козни лукавого, запрети диаволу
Oracle Real Application Testing и SwingBench на Exadata.
В этой заметке мы рассмотрим один из сценариев использования Oracle Real Application Testing для тестирования производительности кластерных систем Exadata под реальной нагрузкой, захваченной на существующей производственной системе. Mы рассмотрим как захватить реальную нагрузку со старой версии Oracle 10.2, работающей на одиночном сервере (2 CPUs - 12 cores, 96Gb RAM, RAID5 3:1 15kRPM disks) и воспроизвести эту нагрузку на одном из нодов кластерной системы (Exadata).
Различные генераторы синтетической нагрузки, такие как SwingBench, позволяют произвести стресс тест новой системы и весьма эффективны для обнаружения "узких мест" оборудования или системной конфигурации. К сожалению, генерируемые искусственные транзакции не могут отразить специфики той или иной "живой" производственной системы. Именно в таких случаях применение Real Application Testing позволяет оценить как именно ваша производственная система поведет себя на новом оборудовании и насколько быстрее ваши реальные пользователи смогут выполнять свою работу.
Прежде чем мы продолжим, я хотел бы привести строки из Евангелия:
......................... == Третья книга Ездры == .............................
=== Глава 10, Стих 21 ===
21 Ибо ты видишь, что святилище наше опустошено, алтарь наш ниспровергнут,
храм наш разрушен,
22 псалтирь наш уничижен, песни умолкли, радость наша исчезла, свет
светильника нашего угас, ковчег завета нашего расхищен, Святое наше
осквернено, и имя, которое наречено на нас, едва не поругано, дети наши
потерпели позор, священники наши избиты, левиты наши отведены в плен,
девицы наши осквернены, жены наши потерпели насилие, праведники наши
увлечены, отроки наши погибли, юноши наши в рабстве, крепкие наши
изнемогли;
23 и что всего тяжелее, знамя Сиона лишено славы своей, потому что предано в
руки ненавидящих нас.
Лично для вас благая весть - Иисус Христос любит вас и Он заповедовал нам любить ближнего своего, как самого себя, быть милосердным, прощать ближним своим и покаяться в своих грехах.
Посмотрите, что происходит с нами и страной, в которой мы живем. Где слава наша, где наша свобода? За грехи наши и преступления, за то, что ожесточили мы сердца свои и отвернулись от Бога отцов наших - за это преданы мы в руки ненавидящих нас.
Покайтесь, примите Иисуса как вашего Спасителя, ибо наступают последние времена и время близко - стоит Судья у ворот.
На главной странице этого сайта вы найдете программу для чтения Библии в командной строке - буду очень рад если программа окажется полезной. Пожалуйста, читайте Библию, на экране или в печатном виде - вы будете искренне удивлены как много там сказано лично про вас и ваши обстоятельства.
Вернемся к нашим техническим деталям.
Я предполагаю что уважаемый читатель владеет необходимыми знаниями и навыками использования Linux и Oracle, поэтому я буду очень краток. Ввиду отсутствия реальных пользователей я прибег к помощи SwingBench, но его роль не является ключевой. В вашем случае для захвата нагрузки используйте реальную систему с пользователями.
На сегодняшний день Real Application Testing может захватывать нагрузку на нескольких релизах Oracle, смотрите metalink note ID 560977.1.
Смотрите также:
Установка Oracle 10.2
[root@n4 ~]# useradd -d /home/ora10g -c "Oracle 10g user" -g oinstall -G oinstall,dba -m -r ora10g [root@n4 ~]# id -a ora10g uid=100(ora10g) gid=1001(oinstall) groups=1001(oinstall),1002(dba) [root@n4 ~]# passwd ora10g Changing password for user ora10g. ...
[ora10g@n4 ~]$ ls 10201_database_linux_x86_64.cpio database p8202632_10205_Linux-x86-64.zip [ora10g@n4 ~]$ cd database/ [ora10g@n4 database]$ ls doc install response runInstaller stage welcome.html [ora10g@n4 database]$ ./runInstaller & [1] 13336 [ora10g@n4 database]$ Starting Oracle Universal Installer... ...
[oracle@n4 logs]$ pwd /u01/app/oracle/oraInventory/logs [oracle@n4 logs]$ less installActions2011-01-27_05-39-07AM.log ... INFO: Check complete. The overall result of this check is: Passed INFO: -------------------------------------------------------------------------------- INFO: Prerequisite checks completed : Thu Jan 27 05:40:36 EST 2011 INFO: The user has manually verified 'Checking kernel parameters' INFO: The user has manually verified 'Checking available swap space requirements ...' INFO: Install type for "Oracle Real Application Testing 10.2.0.5.0 " is "Custom". ------ заметьте! INFO: Install type for "Oracle ODBC Driver for Instant Client 10.2.0.5.0 " is "Custom". INFO: Install type for "Oracle Configuration Manager 10.3.2.1.0 " is "Custom". INFO: Install type for "Oracle Universal Installer 10.2.0.5.0 " is "Custom". INFO: Install type for "Oracle One-Off Patch Installer 10.2.0.4.2 " is "Custom". INFO: Install type for "Installer SDK Component 10.2.0.5.0 " is "Custom". INFO: Install type for "Java Runtime Environment 1.4.2.14.0 " is "Custom". INFO: Install type for "Sun JDK 1.4.2.14.05 " is "Custom". INFO: Calling Query globalVarQueries10.2.0.5.0 getGlobalVariable ... INFO: ----------------------------------------------------------------------------- Summary Global Settings Source: /home/oracle/Disk1/stage/products.xml Oracle Home: /u01/app/oracle/product/10.2.0/db_1 (OraDb10g_home1) Product Languages English Space Requirements / Required 1.49GB (includes 54MB temporary) : Available 14.08GB New Installations (86 products) Oracle Notification Service Patch 10.2.0.5.0 ... Oracle Real Application Testing 10.2.0.5.0 -- заметьте! Oracle Configuration Manager 10.3.2.1.0 ... INFO: 1/27/11 5:41:51 AM EST: Starting install Install Phase 1 of component Oracle Real Application Testing INFO: Calling Action fileActions10.2.0.5.0 copyGroupFromJar selectedNodes = null copyGroup = filegroup1 permissions = 0664 owner = null group = null copyAsText = null JarLoc = /tmp/OraInstall2011-01-27_05-39-07AM/temp36 gpEntries = [[kecwr.o ->%ORACLE_HOME%/rdbms/lib/kecwr.o 3660 plats=1=>[46] DllGroup = false ... INFO: 1/27/11 5:45:05 AM EST: Starting install Link Phase of component Oracle Real Application Testing ... INFO: 1/27/11 5:49:34 AM EST: Starting install Install Phase 2 of component Oracle Real Application Testing ... INFO: Updating XML inventory. INFO: Saving comps.xml for /u01/app/oracle/product/10.2.0/db_1 INFO: Current Inventory: Oracle Home: OraDb10g_home1 Oracle Database 10g 10.2.0.1.0 Sun JDK extensions 10.1.2.0.0 Perl Interpreter 5.8.3.0.2 ... Oracle Real Application Testing 10.2.0.5.0 -- заметьте! ... WARNING: The following configuration scripts need to be executed as the "root" user. #!/bin/sh #Root script to run /u01/app/oracle/product/10.2.0/db_1/root.sh ... INFO: *** End of Installation Page*** The installation of Oracle Database 10g Release 2 Patch Set 4 was successful.
Как видно из логов установки патча 10.2.0.5, Real Application Testing действительно включен как компонент и устанавливается наряду с другими Enterprise Edition опциями.
Подготовка к тесту с пользователями
SQL> l 1 select parameter, value 2 from v$option 3 where parameter like 'Real%' 4* order by 1 SQL> / PARAMETER VALUE --------------------------------------------- ------------ Real Application Clusters FALSE Real Application Testing TRUE SQL> SQL> archive log list Database log mode Archive Mode Automatic archival Enabled Archive destination USE_DB_RECOVERY_FILE_DEST Oldest online log sequence 14 Next log sequence to archive 16 Current log sequence 16 SQL> SQL> select FORCE_LOGGING, FLASHBACK_ON, CURRENT_SCN 2 from v$database; FOR FLASHBACK_ON CURRENT_SCN --- ------------------ ----------- NO YES 225286
SQL> select OLDEST_FLASHBACK_SCN, RETENTION_TARGET, FLASHBACK_SIZE, ESTIMATED_FLASHBACK_SIZE 2 from V$FLASHBACK_DATABASE_LOG; OLDEST_FLASHBACK_SCN RETENTION_TARGET FLASHBACK_SIZE ESTIMATED_FLASHBACK_SIZE -------------------- ---------------- -------------- ------------------------ 225165 4320 8192000 0 SQL> select NAME, FIRST_CHANGE#, BYTES 2 from V$FLASHBACK_DATABASE_LOGFILE; NAME -------------------------------------------------------------------------------------------------------------- FIRST_CHANGE# BYTES ------------- ---------- /u01/app/oracle/product/10.2.0/db_1/flash_recovery_area/DB10G/flashback/o1_mf_6n0y2srg_.flb 225263 8192000 SQL> select * from v$FLASH_RECOVERY_AREA_USAGE; FILE_TYPE PERCENT_SPACE_USED PERCENT_SPACE_RECLAIMABLE NUMBER_OF_FILES ------------ ------------------ ------------------------- --------------- CONTROLFILE .33 0 1 ONLINELOG 7.32 0 3 ARCHIVELOG 0 0 0 BACKUPPIECE 0 0 0 IMAGECOPY 0 0 0 FLASHBACKLOG .38 0 1 6 rows selected.
Параметр RETENTION_TARGET позволяет нам вернуть базу на 72 минуты назад. Можно также использовать "CREATE TABLESPACE .. RETENTION GUARANTEE" для создания UNDO tablespace.
Первая попытка - тест пользовательской активности
Установите java и swingbench в вашу домашнюю директорию. Создайте swingbench схему размером 1Гб, запишите текущий SCN, сразу после создания схемы - в моем случае это 654862. Сделайте DataPump Export вновь созданной схемы SOE, он пригодится для проигрывания нагрузки позже. Сконфигурируйте соединение между swingbench и базой данных и запустите на 30 минут один генератор "charbench":
[ora10@n4 bin]$ ./charbench Version : 2.4.0.688 Results will be written to results.xml. Hit Return to Terminate Run... Time Users TPM TPS 9:55:22 AM 15 1164 79
В течение работы генератора транзакций, проверяйте IO на сервере:
Device: rrqm/s wrqm/s r/s w/s rsec/s wsec/s avgrq-sz avgqu-sz await svctm %util sda 0.00 241.52 0.00 117.56 0.00 2871.06 24.42 4.17 35.65 8.49 99.82 sda1 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 sda2 0.00 241.52 0.00 117.56 0.00 2871.06 24.42 4.17 35.65 8.49 99.82 dm-0 0.00 0.00 0.00 269.86 0.00 2158.88 8.00 9.58 35.53 3.70 99.82 dm-1 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 dm-2 0.00 0.00 0.00 89.02 0.00 712.18 8.00 4.23 47.67 0.35 3.07 dm-3 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
"iostat" показывает, что дисковая система нашего сервера почти полностью истощена, но мы не можем достичь более чем 80 TPS. В чем причина? После завершения этого пробного запуска, проанализировав AWR report, я увеличил размер log buffer, размер и число online logs и выделил в 4 раза больше памяти под PGA. Теперь я хочу повторить тест. Естественно, для этого я воспользуюсь опцией flashback database.
10:19:50 SQL> select count(*) from ORDER_ITEMS; COUNT(*) ---------- 13873000 1 row selected. Elapsed: 00:00:00.58 10:20:10 SQL> select count(*) from orders; COUNT(*) ---------- 4643327 1 row selected. Elapsed: 00:00:00.04 10:20:19 SQL>
1* flashback database to scn 654862 10:27:23 SQL> / Flashback complete. Elapsed: 00:17:34.75 10:44:59 SQL>
"Перемотка" базы заняла в два раза меньше времени, чем реальные транзакции - как мы помним, "charbench" работал 30 минут.
10:52:38 SQL> select count(*) from ORDER_ITEMS; COUNT(*) ---------- 13629483 1 row selected. Elapsed: 00:00:00.58 10:52:40 SQL> select count(*) from orders; COUNT(*) ---------- 4549910 1 row selected. Elapsed: 00:00:00.04 10:53:03 SQL>
Вторая попытка - запись пользовательской активности
Итак, наша база данных вернулась к состоянию "после создания схемы SOE" и готова выполнить тот же тест заново, но с улучшенной конфигурацией системы логов. Этот тест мы попробуем "захватить", в надежде что мы достигнем большего числа транзакций в секунду.
11:10:54 SQL> create directory RAT as '/u01/reco/rat'; Directory created. Elapsed: 00:00:00.01 11:11:07 SQL> grant read,write on directory RAT to public; Grant succeeded. Elapsed: 00:00:00.00 11:11:18 SQL>
Не забудьте что следующие операции не "захватываются":
RAT в состоянии перехватывать SQL и PL/SQL операции над объектами в SGA/PGA, но эта технология может быть бесполезна для batch-type load, типа ETL.
11:11:18 SQL> show parameter PRE_11G_ENABLE_CAPTURE NAME TYPE VALUE ------------------------------------ ----------- ------------------------------ pre_11g_enable_capture boolean TRUE 11:14:48 SQL>
BEGIN DBMS_WORKLOAD_CAPTURE.ADD_FILTER ( fname => ’user_soe’, fattribute => ’USER’, fvalue => ’SOE’); END; / ... 11:28:33 SQL> l 1* select * from DBA_WORKLOAD_FILTERS 11:28:35 SQL> / TYPE ID STATUS NAME ATTRIBUTE VALUE ------------------------------ ---------- ------ --------------- -------------------- -------------------- CAPTURE 0 NEW USER_SOE USER SOE 1 row selected. Elapsed: 00:00:00.00 11:28:36 SQL>
BEGIN DBMS_WORKLOAD_CAPTURE.START_CAPTURE (name => 'swin', dir => 'RAT', -- Директория для RAT файлов с записями транзакций duration => 2400, -- захватывать только 40 минут default_action => 'EXCLUDE' -- Игнорировать все, что не определено в фильтрах ); END; / 11:43:54 SQL> l 1 select NAME, STATUS, START_SCN, FILTERS_USED, DEFAULT_ACTION, DIR_PATH 2* from dba_workload_captures 11:43:56 SQL> / NAME STATUS START_SCN FILTERS_USED DEFAULT_AC DIR_PATH -------- --------------- ---------- ------------ ---------- -------------------- swin IN PROGRESS 657120 1 EXCLUDE /u01/reco/rat 1 row selected. Elapsed: 00:00:00.00 11:43:57 SQL> [ora10@n4 bdump]$ tail -200f alert_DB10G.log ... Sun Jan 30 11:41:31 EST 2011 DBMS_WORKLOAD_CAPTURE.START_CAPTURE(): Starting database capture at 01/30/2011 11:41:31 ...
[ora10@n4 bin]$ ./charbench Version : 2.4.0.688 Results will be written to results.xml. Hit Return to Terminate Run... Time Users TPM TPS 11:44:44 AM 15 7972 735 -- количество TPS растет, 735*60=44100
Очевидно, что наш "тюнинг" помог - SwingBench делает в 10 раз больше транзакций в секунду, чем до этого.
11:47:48 SQL> l 1 select id, PARALLEL, STATUS, START_TIME, END_TIME, DURATION_SECS, TRANSACTIONS, ERRORS 2* from dba_workload_captures 11:47:51 SQL> / ID PAR STATUS START_TIME END_TIME DURATION_SECS TRANSACTIONS ERRORS ---------- --- --------------- ------------ ------------ ------------- ------------ ---------- 1 NO IN PROGRESS 30-JAN 11:41 30-JAN 12:21 2400 89154 0 1 row selected. Elapsed: 00:00:00.00 11:47:52 SQL>
[ora10@n4 ~]$ cd /u01/reco/rat/ [ora10@n4 rat]$ ls wcr_49cyfh0000000.rec wcr_49d3bh000000b.rec wcr_49dqfh000000q.rec wcr_49f0nh0000011.rec wcr_49fvqh000001c.rec wcr_49d3bh0000001.rec wcr_49d3bh000000c.rec wcr_49dqfh000000r.rec wcr_49f0nh0000012.rec wcr_49fw2h000001d.rec wcr_49d3bh0000002.rec wcr_49d3bh000000d.rec wcr_49du6h000000s.rec wcr_49f68h0000013.rec wcr_49fw2h000001f.rec wcr_49d3bh0000003.rec wcr_49d3bh000000f.rec wcr_49du6h000000t.rec wcr_49f8bh0000014.rec wcr_49fzjh000001g.rec wcr_49d3bh0000004.rec wcr_49d3bh000000g.rec wcr_49dwqh000000u.rec wcr_49fhhh0000015.rec wcr_49g12h000001h.rec wcr_49d3bh0000005.rec wcr_49dpth000000h.rec wcr_49f0bh000000v.rec wcr_49fhrh0000016.rec wcr_49g3ah000001j.rec wcr_49d3bh0000006.rec wcr_49dpth000000j.rec wcr_49f0bh000000w.rec wcr_49fvqh0000017.rec wcr_49g8sh000001k.rec wcr_49d3bh0000007.rec wcr_49dpth000000k.rec wcr_49f0bh000000x.rec wcr_49fvqh0000018.rec wcr_scapture.wmd wcr_49d3bh0000008.rec wcr_49dpth000000m.rec wcr_49f0bh000000y.rec wcr_49fvqh0000019.rec wcr_49d3bh0000009.rec wcr_49dpth000000n.rec wcr_49f0bh000000z.rec wcr_49fvqh000001a.rec wcr_49d3bh000000a.rec wcr_49dpth000000p.rec wcr_49f0bh0000010.rec wcr_49fvqh000001b.rec [ora10@n4 rat]$
11:52:38 SQL> select count(*) from ORDER_ITEMS; COUNT(*) ---------- 14603551 -- в начале было 13629483 1 row selected. Elapsed: 00:00:00.58 11:52:40 SQL> select count(*) from orders; COUNT(*) ---------- 4830161 -- в начале было 4549910 1 row selected. Elapsed: 00:00:00.04 11:53:03 SQL>
За время второго получасового теста, "charbench" создал 974068 новых записей, в 4 раза больше первого теста (243517 за 30 минут).
Подготовка к воспроизведению записанных действий пользователей
Для воспроизведения записанных транзакций нам необходимы две вещи: файлы RAT и система с базой данных. Файлы у нас уже есть, получены на предыдущем этапе, как результат записи активности реальных пользователей на старой 10g системе. Воспроизводить иx мы будем на кластерной базе данных, представляющей из себя half rack Oracle Exadata. Напомню, что исходная система работала только на одном сервере. Чтобы сделать сравнение более или менее подобным, мы будем использовать только один из четырех узлов Exadata кластера. А вот ячейки Exadata Storage Server будем использовать все, их семь в нашей конфигурации.
$> ssh oracle@n4 .............................. == Псалтирь == .................................. === Глава 83, Стих 4 === 4 И птичка находит себе жилье, и ласточка гнездо себе, где положить птенцов своих, у алтарей Твоих, Господи сил, Царь мой и Бог мой! 5 Блаженны живущие в доме Твоем: они непрестанно будут восхвалять Тебя. (b+/b-, c+/c-, +/-, *) > [oracle@n4 ~]$ srvctl status database -d dbm Instance dbm1 is not running on node n1 Instance dbm2 is not running on node n2 Instance dbm3 is not running on node n3 Instance dbm4 is running on node n4 [oracle@n4 ~]$
Директория для RAT файлов будет иметь на новой системе такое же имя, перенесем файлы туда и проведем их начальную обработку:
13:02:03 SQL> begin 13:02:14 2 DBMS_WORKLOAD_REPLAY.PROCESS_CAPTURE ( 13:02:23 3 capture_dir => 13:02:32 4 'RAT' 13:02:40 5 ); 13:02:42 6 END; 13:02:45 7 / PL/SQL procedure successfully completed. Elapsed: 00:00:16.78 13:03:03 SQL>
[oracle@n4 ~]$ which java /home/oracle/jre1.6.0_23/bin/java [oracle@n4 ~]$ java -version java version "1.6.0_23" Java(TM) SE Runtime Environment (build 1.6.0_23-b05) Java HotSpot(TM) Server VM (build 19.0-b09, mixed mode) [oracle@n4 ~]$ [oracle@n4 ~]$ java -classpath $ORACLE_HOME/jdbc/lib/ojdbc5.jar:\ $ORACLE_HOME/rdbms/jlib/dbrparser.jar:\ $ORACLE_HOME/rdbms/jlib/dbranalyzer.jar \ oracle.dbreplay.workload.checker.CaptureChecker \ /u01/reco/rat jdbc:oracle:thin:@n4:1521:dbm4 Enter database username: system Enter password: Importing AWR data from directory '/u01/reco/rat' Capture ID: 3 Cannot import AWR data for this capture. Skipping AWR and ASH analysis! Analysis done! [oracle@n4 ~]$ cat /u01/reco/rat/wcr_cap_analysis.html ... Finding Maximum Workload Impact PL/SQL 99 % ERRORS 7 % Missing AWR export Unknown ... Maximum Workload Impact: 99 % of DB Time ... A significant part of your workload comes from PL/SQL. If the PL/SQL blocks or functions have 'complicated' logic or multiple commits in them, they are hard to synchronize and they behavior might change during replay. You might see a different workload profile during replay if this is the case. ... Maximum Workload Impact: 7 % of DB Time ... A significant part of your captured workload time is spent in user calls that encountered errors. These calls might not be completely captured/replayed, and therefore the time associated with these errors might not appear completely in the replay DB Time.
19:14:25 SQL> exec dbms_workload_replay.initialize_replay (replay_name => 'swinr', replay_dir=>'RAT'); PL/SQL procedure successfully completed. Elapsed: 00:00:00.62 19:14:48 SQL> 19:16:51 SQL> l 1 select name, status 2* from DBA_WORKLOAD_REPLAYS 19:16:58 SQL> / NAME STATUS --------------- ---------------------------------------- swinr INITIALIZED 1 row selected. Elapsed: 00:00:00.00
19:18:22 SQL> exec dbms_workload_replay.remap_connection (connection_id=> 1, replay_connection=>'n4:1521/dbm4'); PL/SQL procedure successfully completed. Elapsed: 00:00:00.01 19:22:40 SQL> 19:22:40 SQL> select * from DBA_WORKLOAD_CONNECTION_MAP; REPLAY_ID CONN_ID ---------- ---------- CAPTURE_CONN -------------------------------------------------------------------------------------------------------------- REPLAY_CONN -------------------------------------------------------------------------------------------------------------- 1 1 (DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=10.1.1.28)(PORT=1521))(CONNECT_DATA=(CID=(PROGRAM=JDBC Thin Cli ent)(HOST=__jdbc__)(USER=ora10))(SERVICE_NAME=DB10G)(CID=(PROGRAM=JDBC Thin Client)(HOST=__jdbc__)(USER=ora10) ))) n4:1521/dbm4 1 row selected. Elapsed: 00:00:00.00 19:23:41 SQL>
В таком случае все записанные сессии, использующие service DB10G, будут автоматически перенаправлены на service dbm4, что позволит избежать ошибок при воспроизведении транзакций.
19:25:16 SQL> begin 19:29:31 2 dbms_workload_replay.prepare_replay ( 19:29:49 3 THINK_TIME_SCALE=>0); -- тут я использую то же, что было в SwingBench 19:30:39 4 end; 19:30:41 5 / PL/SQL procedure successfully completed. Elapsed: 00:00:12.64 19:30:54 SQL> 9:31:27 SQL> select name, status 19:31:35 2 from DBA_WORKLOAD_REPLAYS; NAME STATUS --------------- ---------------------------------------- swinr PREPARE 1 row selected. Elapsed: 00:00:00.00 19:31:45 SQL>
Мы еще не знаем как поведет себя наша новая система во время проигрывания нагрузки. Она может проигрывать ее слишком медленно не из-за недостаточной мощности, но из-за малого числа процессов - генераторов транзакций.
[oracle@n4 ~]$ wrc mode=calibrate replaydir=/dbfs_direct/staging_area/ Workload Replay Client: Release 11.2.0.2.0 - Production on Sun Jan 30 19:36:44 2011 Copyright (c) 1982, 2009, Oracle and/or its affiliates. All rights reserved. Report for Workload in: /dbfs_direct/staging_area/ -- файлы теперь здесь, про DBFS в другой раз ----------------------- Recommendation: Consider using at least 1 clients divided among 1 CPU(s) You will need at least 56 MB of memory per client process. If your machine(s) cannot match that number, consider using more clients. Workload Characteristics: - max concurrency: 15 sessions - total number of sessions: 15 Assumptions: - 1 client process per 50 concurrent sessions - 4 client process per CPU - 256 KB of memory cache per concurrent session - think time scale = 100 - connect time scale = 100 - synchronization = TRUE [oracle@n4 ~]$
Калибровка показывает что нам должно быть достаточно одного генератора, но мы будем использовать два.
Воспроизведение записанных действий пользователей
Воспроизведение записанных транзакций происходит в два этапа.
(Клиент 1 в терминале 1) [oracle@n4 ~]$ wrc system/welcome@//n4/dbm mode=replay\ replaydir=/dbfs_direct/staging_area connection_override=true & [1] 22429 [oracle@n4 ~]$ Workload Replay Client: Release 11.2.0.2.0 - Production on Sun Jan 30 19:42:43 2011 Copyright (c) 1982, 2009, Oracle and/or its affiliates. All rights reserved. Wait for the replay to start (19:42:43) (Второй клиент в другом терминале выведет такое же сообщение) 19:49:24 SQL> l 1 select inst_id, SID, SERIAL#, spid, event, user_calls 2* from gv$workload_replay_thread 19:49:28 SQL> / INST_ID SID SERIAL# SPID EVENT USER_CALLS ---------- ---------- ---------- ------------ ----------------------------------- ---------- 4 785 237 22832 WCR: replay client notify 0 -- ничего не происходит 4 847 107 22431 WCR: replay client notify 0 2 rows selected. Elapsed: 00:00:00.01 19:49:30 SQL>
Существует еще один способ переназначения параметров соединений, он использован в моем примере - параметр "connection_overridе" игнорирует DBA_WORKLOAD_CONNECTION_MAP и использует для всех сессий параметры соединения из командой строки.
19:50:17 SQL> exec dbms_workload_replay.start_replay; PL/SQL procedure successfully completed. Elapsed: 00:00:02.68 19:50:42 SQL> 1 select inst_id, SID, SERIAL#, spid, event, user_calls 2* from gv$workload_replay_thread 19:51:19 SQL> / INST_ID SID SERIAL# SPID EVENT USER_CALLS ---------- ---------- ---------- ------------ ----------------------------------- ---------- 4 141 135 25257 WCR: replay client notify 0 4 336 5 25357 WCR: replay clock 4426 4 397 5 25355 cell single block physical read 4819 4 527 4549 25369 SQL*Net message from client 4369 4 591 14367 25367 cell single block physical read 4155 4 657 4999 25365 cell single block physical read 3715 4 719 399 25379 WCR: replay clock 4545 4 785 239 25260 WCR: replay client notify 0 4 788 5181 25389 WCR: replay clock 4009 4 847 109 25266 SQL*Net message from client 0 4 850 8691 25375 cell single block physical read 4683 4 913 69 25373 WCR: replay clock 4531 4 980 1169 25377 WCR: replay clock 4529 4 984 95 25263 SQL*Net message from client 0 4 1042 61 25371 WCR: replay clock 3921 4 1109 6821 25383 cell single block physical read 4741 4 1178 7 25381 SQL*Net message to client 4515 4 1238 163 25387 cell single block physical read 3913 4 1310 13 25385 WCR: replay clock 4591 19 rows selected. Elapsed: 00:00:00.01 19:51:20 SQL>
Два генератора транзакций подключены к базе через множество сессий, каждая из которых воспроизводит приблизительно равное количество пользовательских операций. Wait event "cell single block physical read" свидетельствует что чтение данных в buffer cache производится с Exadata Storage Server cells.
GV$WORKLOAD_REPLAY_THREAD и DBA_WORKLOAD_REPLAY_DIVERGENCE:
19:55:22 SQL> select * from DBA_WORKLOAD_REPLAY_DIVERGENCE 19:55:28 2 ; no rows selected -- логических ошибок пока нет Elapsed: 00:00:00.03 20:00:27 SQL> l 1 select EXPECTED_ERROR_MESSAGE, OBSERVED_ERROR_MESSAGE, count(*) 2 from DBA_WORKLOAD_REPLAY_DIVERGENCE 3* group by EXPECTED_ERROR_MESSAGE, OBSERVED_ERROR_MESSAGE 20:00:51 SQL> / EXPECTED_ERROR_MESSAGE OBSERVED_ERROR_MESSAGE COUNT(*) --------------------------------------------- ------------------------- ---------- break received on communication channel 49 1 row selected. Elapsed: 00:00:00.01 20:00:52 SQL>
Ожидаемые 49 ошибок произошли на исходной системе в результате неожиданного завершения сессий SwingBench и могут быть проигнорированы.
20:00:52 SQL> select inst_id, SID, SERIAL#, spid, event, user_calls 20:02:21 2 from gv$workload_replay_thread; no rows selected Elapsed: 00:00:00.00 Оба генератора выведут похожее сообщение, но с разным временем окончания работы: Wait for the replay to start (19:42:43) Replay started (19:50:42) Replay finished (19:56:53)
Анализ и сравнение результатов
30 минут транзакций, записанных на исходной системе, были воспроизведены за 5 минут на одном узле Exadata кластера, смотрите отчет ниже. Поскольку мы использовали один и тот же сервер в обоих случаях, улучшение было достигнуто главным образом благодаря высокопроизводительной дисковой системе. Это далеко не предел и результат можно улучшить. Swingbench на Exadata X2-2 half rack в состоянии генерировать около 4500 транзакций в секунду на одном ноде кластера (TPS взяты из AWR Report и представляют реальное количество транзакций в одном instance).
20:13:31 SQL> select dbms_workload_replay.report (1, 'TEXT') 20:14:36 2 from dual; DBMS_WORKLOAD_REPLAY.REPORT(1,'TEXT') --------------------------------------- DB Replay Report for swinr ... Duration 5 minutes 3 seconds ... User calls 829383 ... Errors No Longer Seen During Replay 49 ... Workload Profile Top Events -------------------------------------------------------------- | Event | Event Class | % Activity | -------------------------------------------------------------- | CPU + Wait for CPU | CPU | 54.55 | -------------------------------------------------------------- | cell single block physical read | User I/O | 28.67 | --------------------------------------------------------------
20:22:56 SQL> conn soe/soe Connected. 20:22:59 SQL> select count(*) from ORDER_ITEMS; COUNT(*) ---------- 14603551 1 row selected. Elapsed: 00:00:08.71 20:23:53 SQL> select count(*) from orders; COUNT(*) ---------- 4830161 1 row selected. Elapsed: 00:00:00.12 20:24:23 SQL>
Цифры совпали несмотря на 49 ошибок. Почему? Эти ошибки произошли уже после того, как "charbench" завершил все транзакции и отключился. Как мы помним, ошибки записи "break received on communication channel" так и не проявились во время проигрывания нагрузки.
Спасибо что зашли,
Будьте благословенны!
Денис
