Oracle Real Application Testing и SwingBench на Exadata

THE HOLY BIBLE - King James Version - БИБЛИЯ в Синодальном переводе
"Нас Атакуют!" Изобличи козни лукавого, запрети диаволу

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.

  • для захвата на 9.2.0.8.0 и проигрывания на >=11.2.0.2.0, установите эти патчи: 9.2.0.8.0 + one-off patch 9373986
  • для захвата на 10.2.0.4.0 и проигрывания на >=11.2.0.2.0, установите эти патчи: 10.2.0.4.0 Patchset + one-off patch 10239989
  • для захвата на 10.2.0.5.0 и проигрывания на >=11.2.0.2.0 патчи не нужны.
  • Смотрите также:

  • Real Application Testing (RAT) API Setup and Verification [ID 1083063.1]
  • DATABASE CAPTURE AND REPLAY COMMON ERRORS AND REASONS [ID 463263.1]
  • Установка Oracle 10.2

  • Создайте отдельного Linux пользователя для 10g, в моем случае на одном и том же сервере "n4" будет несколько Oracle Homes: одна для Oracle 10g, две для 11g кластера - Grid Infrastructure Oracle Home и Oracle 11.2 Home.
  • [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.
    ...
    

  • Установите Oracle 10g RDBMS:
  • [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...
    ...
    

  • Установите 10.2.0.5 PatchSet
  • [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 опциями.

    Подготовка к тесту с пользователями

  • Создайте базу, включите archive logging и flashback logging.
  • Возможно, что мы не достигнем нужного уровня транзакций в секунду с первого раза. В этом случае flashback нам очень пригодится. Вместо полного удаления и создания заново схемы SOE, мы можем "перемотать" базу назад, к тому моменту когда SwingBench только создал свою SOE схему и никаких транзакций еще не было.

    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
    

  • Проверьте что flashback логи присутствуют и выясните насколько возможно "перемотать" базу назад:
  • 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.

  • Прежде всего проверим количество записей в основных таблицах схемы SOE:
  • 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>
    

  • Теперь "перемотаем" нашу базу на 30-40 минут назад, до начала первого SwingBench теста:
  • 1* flashback database to scn 654862
    10:27:23 SQL> /
    Flashback complete.
    Elapsed: 00:17:34.75
    10:44:59 SQL>
    

    "Перемотка" базы заняла в два раза меньше времени, чем реальные транзакции - как мы помним, "charbench" работал 30 минут.

  • Вновь проверим количество записей в основных таблицах и убедимся, что оно уменьшилось.
  • Не забывайте, что в процессе работы Swiingbench не только создает новые записи, но и удаляет - обновляет существующие. Именно поэтому мы видим всего лишь 243517 новых записей, созданных за полчаса работы генератора транзакций:

    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" и готова выполнить тот же тест заново, но с улучшенной конфигурацией системы логов. Этот тест мы попробуем "захватить", в надежде что мы достигнем большего числа транзакций в секунду.

  • Создадим пустую директорию для файлов RAT:
  • 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>
    

    Не забудьте что следующие операции не "захватываются":

  • Direct path load of data from external files using utilities such as SQL*Loader
  • Non-PL/SQL based Advanced Queuing (AQ)
  • Flashback queries
  • Oracle Call Interface (OCI) based object navigations
  • Non SQL-based object access
  • Distributed transactions (any distributed transactions that are captured will be replayed as local transactions)
  • RAT в состоянии перехватывать SQL и PL/SQL операции над объектами в SGA/PGA, но эта технология может быть бесполезна для batch-type load, типа ETL.

  • Для Oracle 10g необходимо установить параметр "pre_11g_enable_capture":
  • 11:11:18 SQL> show parameter PRE_11G_ENABLE_CAPTURE
    
    NAME				     TYPE	 VALUE
    ------------------------------------ ----------- ------------------------------
    pre_11g_enable_capture		     boolean	 TRUE
    11:14:48 SQL>
    

  • Создадим фильтр для захвата только операций с объектами схемы SOE, но не полностью всех действий в базе. Нас не интересуют запросы, выдаваемые Enterprise Manager, фоновые задачи типа сбора статистики и прочее.
  • 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>
    

    Сейчас мы готовы начать "перехват", хотя нагрузки как таковой еще нет. RAT capture процесс должен начаться раньше первой транзакции и окончиться позже последней. Наш RAT будет записывать активность пользователей в течение 40 минут, поскольку SwingBench работает 30 минут:

    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
    ...
    

  • Теперь, когда RAT записывает действия наших пользователей, запустим "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
    
    11:44:44 AM     15      7972    735 	-- количество TPS растет, 735*60=44100
    

    Очевидно, что наш "тюнинг" помог - SwingBench делает в 10 раз больше транзакций в секунду, чем до этого.

  • Продолжим наблюдение за RAT процессом в течение всех 40 минут:
  • 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>
    

  • Через 40 минут, RAT процесс прекратит захват запросов. Проверим наличие файлов в директории RAT:
  • [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 будем использовать все, их семь в нашей конфигурации.

  • Начнем с того, что перенесем все наши RAT файлы в директорию на новой системе и выключим 3 из 4 узлов кластера.
  • Внимательный читатель заметит, что во всех вставках кода имя исходной 10g и новой 11g систем одно и то же - "n4". Это не ошибка, просто я использовал один и тот же сервер в обоих случаях, что гарантирует нам одинаковые характеристики аппаратных средств. Имена linux users разные - "ora10" и "oracle".

    $> 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>
    

  • Теперь проверим наши файлы программкой Workload Analyzer и просмотрим ее отчет.
  • К моему сожалению, все больше и больше командных утилит Oracle переводится или изначально пишется на java. Я до сих пор не понимаю, зачем было переписывать (дважды!) прекрасный текстовый инсталлятор, почему утилита "cellcli" написана на java а не на C/C++, как "SQL*Plus". Если так пойдет и дальше, скоро само ядро базы будет переписано на "языке высокого уровня" ... надеюсь, до этого у разработчиков просто не дойдут руки.

    [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.
    

  • Подготовим базовую схему, поверх которой будем "накатывать" записанные транзакции.
  • Естественно, эта схема должна выглядеть логически так же, как исходная схема в базе 10g. Мы можем использовать SwingBench ("oewizard") и создать схему с такими же параметрами, или мы можем восстановить резервную копию исходной базы (в случае одного релиза) - или, как я, использовать Data Pump и импортировать схему из исходной базы, до того как в ней была произведена первая транзакция.

  • Теперь, когда наша исходная схема готова, пора инициализировать RAT replay:
  • 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
    

  • Очевидно, что параметры соединения с разными базами данных (10g и 11g) будут различаться, в нашем примере "dbm4" является базой назначения. Именно для этого случая существует remapping соединений:
  • 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, что позволит избежать ошибок при воспроизведении транзакций.

  • Подготовим процессы RAT к воспроизведению нагрузки:
  • 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>
    

    Мы еще не знаем как поведет себя наша новая система во время проигрывания нагрузки. Она может проигрывать ее слишком медленно не из-за недостаточной мощности, но из-за малого числа процессов - генераторов транзакций.

  • Для приблизительной оценки числа необходимых RAT генераторов записанные RAT файлы надо "откалибровать":
  • [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 и использует для всех сессий параметры соединения из командой строки.

  • Вторым шагом является непосредственно запуск RAT replay:
  • 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.

  • Процесс воспроизведения транзакций можно проверять через DBA_WORKLOAD_REPLAYS,
    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).

  • Проверим отчет о работе RAT генераторов:
  • 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" так и не проявились во время проигрывания нагрузки.

    Спасибо что зашли,

    Будьте благословенны!
    Денис