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

Использование Interdatabase IORM планов для управления дисковыми операциями в Exadata

Консолидирование и дальнейшее объединение множества баз данных в одну кластерную систему стало почти стандартом в сегодняшних ИТ отделах. В то же время, проблема контроля и распределения общих ресурсов обретает еще большую актуальность.

Эта заметка рассматривает простой способ управления распределенными дисковыми ресурсами кластерной системы. Используется Oracle IORM - новое средство для распределения дисковых операций между множеством баз данных, объединенных на общей платформе Oracle Exadata X2.

Прежде чем мы продолжим, я хотел бы привести строки из Евангелия:



.................. == От Иоанна святое благовествование == ..................... === Глава 3, Стих 16 === 16 Ибо так возлюбил Бог мир, что отдал Сына  Своего  Единородного,  дабы  всякий    верующий в Него, не погиб, но имел жизнь вечную. 17 Ибо не послал Бог  Сына  Своего  в  мир,  чтобы  судить  мир,  но  чтобы  мир    спасен был чрез Него. 18 Верующий в  Него  не  судится,  а  неверующий  уже  осужден,  потому  что  не    уверовал во имя Единородного Сына Божия. 19 Суд же состоит в том,  что  свет  пришел  в  мир;  но  люди  более  возлюбили    тьму, нежели свет, потому что дела их были злы; 20 ибо всякий, делающий злое, ненавидит  свет  и  не  идет  к  свету,  чтобы  не    обличились дела его, потому что они злы, 21 а поступающий по правде идет к свету, дабы явны были  дела  его,  потому  что    они в Боге соделаны.

Нечего добавить к этим строкам из Святого Писания - читай и думай сам. Прошло две недели после Пасхи, вспомним дела свои за это время - к чему они ближе, к свету или к тьме? Идешь ли ты к свету или по-старому блуждаешь во тьме? Светлый праздник Пасхи отогнал тьму от нас - так останемся же во свете пришедшего Христа и будем поступать по правде, делая наши дела в Боге - чтоб не стыдиться их позже.

Лично для вас благая весть - Единородный Сын Божий Иисус Христос любит вас, Он взошел на крест за ваши грехи, был распят и на третий день воскрес, сел одесную Бога и открыл нам дорогу в Царствие Небесное.

Покайтесь, примите Иисуса как вашего Спасителя, ибо наступают последние времена и время близко - стоит Судья у ворот.

Пожалуйста, в своих каждодневных трудах, какими бы занятыми вы себе ни казались - находите время для Бога, Его заповедей и Библии.

На главной странице этого сайта вы найдете программу для чтения Библии в командной строке - буду очень рад если программа окажется полезной. Пожалуйста, читайте Библию, на экране или в печатном виде - вы будете искренне удивлены как много там сказано лично про вас и ваши обстоятельства.


Вернемся к нашим техническим деталям.

Я предполагаю что уважаемый читатель владеет необходимыми знаниями и навыками использования Linux и Oracle, поэтому я буду очень краток. Цель этой заметки изложить простой подход к контролю дисковых ресурсов в кластере и прояснить некоторые детали.

Я также предполагаю, что в наличии имеется Oracle Exadata x2 и система уже работает в вашей серверной комнате. Обсуждаемый здесь сценарий основан на IORM, а он доступен только на Exadata.

Кратко опишем проблему.

Предположим, на нашем Exadata кластере существует множество баз данных, используемых в различных проектах. Разработчики одного из проектов используют базу данных с именем "DBA" для тестирования нового программного продукта, требующего огромного количества дисковых операций. Таким продуктом в нашем случае будет SwingBench. Иногда база данных "DBA" потребляет до 90% всех доступных IOPS системы, существенно замедляя работу другой базы с именем "DBB". Обе базы контролируются разными администраторами, каждый из которых уверен в особой значимости только его проекта. При этом все существующие базы данных используют одну общую ASM группу "DATA_X", включающую в себя все доступные физические диски.

Необходимо ограничить потребление дисковых ресурсов базой "DBA" до 1%, без вовлечения ее администратора, предоставив оставшиеся IOPS для использования базой "DBB". При этом никакие изменения на уровне дисковой организации недопустимы - все базы по-прежнему должны использовать одну общую ASM группу "DATA_X", и эта группа должна включать в себя все физические диски.

Предложим решение.

В такой постановке, задача фактически неразрешима традиционными средствами. Попытка разграничить доступ к индивидуальным дискам нарушит требование использовать всего одну ASM группу. Ограничение числа дисковых операций, доступных программе SwingBench внутри базы данных "DBA" потребует создания планов Oracle Resource Manager и вовлечения администратора. Именно в такой ситуации простое и элегантное решение может быть достигнуто с использованием IORM на уровне "ячеек" - индивидуальных Exadata Storage Servers.

Для демонстрации нашего решения, выполним следующие шаги:

  • Первый SwingBench тест, без ограничений числа IOPS;
  • Первый DataPump import тест, без ограничений.
    DataPump будет использоваться для подготовки схемы "SOE" для нового запуска SwingBench;
  • Активация IORM плана на каждой "ячейке",
    так чтобы база "DBA" не могла получать более 1% от общего доступного числа IOPS;
  • Второй DataPump import тест, с ограниченным числом IOPS;
  • Второй SwingBench тест, с ограниченным числом IOPS.
  • Используя IORM план на уровне каждой индивидуальной дисковой "ячейки" Exadata, мы можем гарантировать что база "DBA" при любых условиях ее использования не получит более 1% от общего максимально доступного числа IOPS на этой "ячейке". При этом контроль за IORM планом осуществляется администратором Storage Server (root или celladmin), не требует вовлечения администратора баз данных или изменения структуры дисковых групп. Более того, IORM план может быть изменен или отключен в любой момент, на уровне одной "ячейки" или всех Exadata Storage Servers.

    Используя Interdatabase IORM, администратор Exadata Storage Server может установить для каждой кластерной базы данных "потолок" на число дисковых операций в секунду (IOPS) потребляемых в сумме всеми instances этой базы с индивидуальной "ячейки".

    Первый SwingBench тест, без ограничений числа IOPS

  • Убедимся, что обе базы данных "DBA" и "DBB" запущены на всех четырех узлах Exadata кластера:
  • [oracle@x1 sw]$ /u01/app/11.2.0/grid/bin/crsctl status resource -w "TYPE = ora.database.type" -t
    --------------------------------------------------------------------------------
    NAME           TARGET  STATE        SERVER                   STATE_DETAILS
    --------------------------------------------------------------------------------
    Cluster Resources
    --------------------------------------------------------------------------------
    ora.dba.db
          1        ONLINE  ONLINE       x1                 Open
          2        ONLINE  ONLINE       x2                 Open
          3        ONLINE  ONLINE       x3                 Open
          4        ONLINE  ONLINE       x4                 Open
    ora.dbb.db
          1        ONLINE  ONLINE       x1                 Open
          2        ONLINE  ONLINE       x2                 Open
          3        ONLINE  ONLINE       x3                 Open
          4        ONLINE  ONLINE       x4                 Open
    [oracle@x1 sw]$
    

    На данный момент, все семь "ячеек" раздают свои ресурсы без ограничений, в количестве запрашиваемом базами данных, вплоть то 100%-го истощения запаса числа дисковых операций.

  • На первом узле кластера запустим один генератор нагрузки SwingBench, имитирующий 20 пользователей:
  • [oracle@x1 bin]$ ./charbench
    Results will be written to results.xml.
    Hit Return to Start & Terminate Run...
    
    Time            Users   TPM     TPS
    2:54:25 PM      20      90766   2003
    

  • Убедимся, что все сессии пользователей распределены между instances базы "DBA":
  • -- we have limit of 20 sessions max per one SW generator:
      1  select inst_id, count(*)
      2  from gv$session
      3  where username  = 'SOE'
      4* group by inst_id
    14:56:08 SQL> /
    
       INST_ID   COUNT(*)
    ---------- ----------
             1          6
             2          5
             4          6
             3          6
    
    4 rows selected.
    
    Elapsed: 00:00:00.01
    14:56:09 SQL>
    

    IOPS: На уровне дисков "ячейки"

  • Проверим какое количество дисковых операций выдается в секунду (IOPS) с каждого диска каждой ячейки. Все "dcli" команды запускаются с узлов кластера, как Linux пользователь "oracle":
  • [oracle@x1 ~]$ dcli -g cell_group -l root cellcli -e "list METRICCURRENT
    GD_IO_RQ_W_SM_SEC, GD_IO_RQ_W_LG_SEC, GD_IO_RQ_R_SM_SEC, GD_IO_RQ_R_LG_SEC
    where metricObjectName like \'DATA_.*\'" | grep -v "0.0 IO/sec"
    
    c1: GD_IO_RQ_W_SM_SEC         DATA_X_CD_00_c1         15.2 IO/sec --
    c1: GD_IO_RQ_W_SM_SEC         DATA_X_CD_01_c1         13.2 IO/sec
    c1: GD_IO_RQ_W_SM_SEC         DATA_X_CD_02_c1         68.4 IO/sec
    c1: GD_IO_RQ_W_SM_SEC         DATA_X_CD_03_c1         14.8 IO/sec
    c1: GD_IO_RQ_W_SM_SEC         DATA_X_CD_04_c1         33.2 IO/sec
    c1: GD_IO_RQ_W_SM_SEC         DATA_X_CD_05_c1         16.8 IO/sec
    c1: GD_IO_RQ_W_SM_SEC         DATA_X_CD_06_c1         64.9 IO/sec
    c1: GD_IO_RQ_W_SM_SEC         DATA_X_CD_07_c1         88.7 IO/sec
    c1: GD_IO_RQ_W_SM_SEC         DATA_X_CD_08_c1         62.9 IO/sec
    c1: GD_IO_RQ_W_SM_SEC         DATA_X_CD_09_c1         196 IO/sec
    c1: GD_IO_RQ_W_SM_SEC         DATA_X_CD_10_c1         59.6 IO/sec
    c1: GD_IO_RQ_W_SM_SEC         DATA_X_CD_11_c1         16.1 IO/sec -- Total: 649.8
    c1: GD_IO_RQ_W_LG_SEC         DATA_X_CD_03_c1         0.1 IO/sec
    c1: GD_IO_RQ_W_LG_SEC         DATA_X_CD_06_c1         0.4 IO/sec
    c1: GD_IO_RQ_W_LG_SEC         DATA_X_CD_10_c1         0.1 IO/sec
    c1: GD_IO_RQ_W_LG_SEC         DATA_X_CD_11_c1         0.2 IO/sec
    c1: GD_IO_RQ_R_SM_SEC         DATA_X_CD_02_c1         0.2 IO/sec
    c1: GD_IO_RQ_R_SM_SEC         DATA_X_CD_03_c1         1.5 IO/sec
    c1: GD_IO_RQ_R_SM_SEC         DATA_X_CD_05_c1         0.2 IO/sec
    c1: GD_IO_RQ_R_SM_SEC         DATA_X_CD_07_c1         0.1 IO/sec
    c1: GD_IO_RQ_R_SM_SEC         DATA_X_CD_08_c1         0.1 IO/sec
    c1: GD_IO_RQ_R_SM_SEC         DATA_X_CD_09_c1         0.1 IO/sec
    c1: GD_IO_RQ_R_SM_SEC         DATA_X_CD_10_c1         0.2 IO/sec
    c2: GD_IO_RQ_W_SM_SEC         DATA_X_CD_00_c2         71.0 IO/sec --
    c2: GD_IO_RQ_W_SM_SEC         DATA_X_CD_01_c2         166 IO/sec
    c2: GD_IO_RQ_W_SM_SEC         DATA_X_CD_02_c2         38.8 IO/sec
    c2: GD_IO_RQ_W_SM_SEC         DATA_X_CD_03_c2         60.2 IO/sec
    c2: GD_IO_RQ_W_SM_SEC         DATA_X_CD_04_c2         16.4 IO/sec
    c2: GD_IO_RQ_W_SM_SEC         DATA_X_CD_05_c2         27.4 IO/sec
    c2: GD_IO_RQ_W_SM_SEC         DATA_X_CD_06_c2         60.4 IO/sec
    c2: GD_IO_RQ_W_SM_SEC         DATA_X_CD_07_c2         23.6 IO/sec
    c2: GD_IO_RQ_W_SM_SEC         DATA_X_CD_08_c2         194 IO/sec
    c2: GD_IO_RQ_W_SM_SEC         DATA_X_CD_09_c2         63.0 IO/sec
    c2: GD_IO_RQ_W_SM_SEC         DATA_X_CD_10_c2         23.0 IO/sec
    c2: GD_IO_RQ_W_SM_SEC         DATA_X_CD_11_c2         56.3 IO/sec -- Total: 800.1
    c2: GD_IO_RQ_W_LG_SEC         DATA_X_CD_01_c2         0.1 IO/sec
    c2: GD_IO_RQ_W_LG_SEC         DATA_X_CD_04_c2         0.1 IO/sec
    c2: GD_IO_RQ_W_LG_SEC         DATA_X_CD_05_c2         0.1 IO/sec
    c2: GD_IO_RQ_W_LG_SEC         DATA_X_CD_07_c2         0.3 IO/sec
    c2: GD_IO_RQ_W_LG_SEC         DATA_X_CD_08_c2         0.2 IO/sec
    c2: GD_IO_RQ_W_LG_SEC         DATA_X_CD_09_c2         0.4 IO/sec
    c2: GD_IO_RQ_R_SM_SEC         DATA_X_CD_00_c2         0.1 IO/sec
    c2: GD_IO_RQ_R_SM_SEC         DATA_X_CD_03_c2         0.1 IO/sec
    c2: GD_IO_RQ_R_SM_SEC         DATA_X_CD_06_c2         0.1 IO/sec
    c2: GD_IO_RQ_R_SM_SEC         DATA_X_CD_07_c2         0.4 IO/sec
    c2: GD_IO_RQ_R_SM_SEC         DATA_X_CD_09_c2         0.3 IO/sec
    c3: GD_IO_RQ_W_SM_SEC         DATA_X_CD_00_c3         14.2 IO/sec --
    c3: GD_IO_RQ_W_SM_SEC         DATA_X_CD_01_c3         59.3 IO/sec
    c3: GD_IO_RQ_W_SM_SEC         DATA_X_CD_02_c3         16.8 IO/sec
    c3: GD_IO_RQ_W_SM_SEC         DATA_X_CD_03_c3         62.6 IO/sec
    c3: GD_IO_RQ_W_SM_SEC         DATA_X_CD_04_c3         190 IO/sec
    c3: GD_IO_RQ_W_SM_SEC         DATA_X_CD_05_c3         145 IO/sec
    c3: GD_IO_RQ_W_SM_SEC         DATA_X_CD_06_c3         54.8 IO/sec
    c3: GD_IO_RQ_W_SM_SEC         DATA_X_CD_07_c3         17.6 IO/sec
    c3: GD_IO_RQ_W_SM_SEC         DATA_X_CD_08_c3         13.1 IO/sec
    c3: GD_IO_RQ_W_SM_SEC         DATA_X_CD_09_c3         48.0 IO/sec
    c3: GD_IO_RQ_W_SM_SEC         DATA_X_CD_10_c3         58.8 IO/sec
    c3: GD_IO_RQ_W_SM_SEC         DATA_X_CD_11_c3         195 IO/sec -- Total: 875.2
    c3: GD_IO_RQ_W_LG_SEC         DATA_X_CD_03_c3         0.1 IO/sec
    c3: GD_IO_RQ_W_LG_SEC         DATA_X_CD_06_c3         0.1 IO/sec
    c3: GD_IO_RQ_W_LG_SEC         DATA_X_CD_07_c3         0.2 IO/sec
    c3: GD_IO_RQ_R_SM_SEC         DATA_X_CD_00_c3         0.1 IO/sec
    c3: GD_IO_RQ_R_SM_SEC         DATA_X_CD_01_c3         14.2 IO/sec
    c3: GD_IO_RQ_R_SM_SEC         DATA_X_CD_04_c3         0.3 IO/sec
    c3: GD_IO_RQ_R_SM_SEC         DATA_X_CD_05_c3         0.1 IO/sec
    c3: GD_IO_RQ_R_SM_SEC         DATA_X_CD_06_c3         0.1 IO/sec
    c3: GD_IO_RQ_R_SM_SEC         DATA_X_CD_07_c3         0.2 IO/sec
    c3: GD_IO_RQ_R_SM_SEC         DATA_X_CD_11_c3         0.1 IO/sec
    c4: GD_IO_RQ_W_SM_SEC         DATA_X_CD_00_c4         24.6 IO/sec --
    c4: GD_IO_RQ_W_SM_SEC         DATA_X_CD_01_c4         61.3 IO/sec
    c4: GD_IO_RQ_W_SM_SEC         DATA_X_CD_02_c4         19.7 IO/sec
    c4: GD_IO_RQ_W_SM_SEC         DATA_X_CD_03_c4         15.8 IO/sec
    c4: GD_IO_RQ_W_SM_SEC         DATA_X_CD_04_c4         161 IO/sec
    c4: GD_IO_RQ_W_SM_SEC         DATA_X_CD_05_c4         65.5 IO/sec
    c4: GD_IO_RQ_W_SM_SEC         DATA_X_CD_06_c4         149 IO/sec
    c4: GD_IO_RQ_W_SM_SEC         DATA_X_CD_07_c4         25.0 IO/sec
    c4: GD_IO_RQ_W_SM_SEC         DATA_X_CD_08_c4         18.4 IO/sec
    c4: GD_IO_RQ_W_SM_SEC         DATA_X_CD_09_c4         13.6 IO/sec
    c4: GD_IO_RQ_W_SM_SEC         DATA_X_CD_10_c4         10.6 IO/sec
    c4: GD_IO_RQ_W_SM_SEC         DATA_X_CD_11_c4         13.6 IO/sec -- Total: 578.1
    c4: GD_IO_RQ_W_LG_SEC         DATA_X_CD_02_c4         0.1 IO/sec
    c4: GD_IO_RQ_W_LG_SEC         DATA_X_CD_03_c4         0.1 IO/sec
    c4: GD_IO_RQ_W_LG_SEC         DATA_X_CD_04_c4         0.1 IO/sec
    c4: GD_IO_RQ_W_LG_SEC         DATA_X_CD_06_c4         0.2 IO/sec
    c4: GD_IO_RQ_W_LG_SEC         DATA_X_CD_07_c4         0.1 IO/sec
    c4: GD_IO_RQ_W_LG_SEC         DATA_X_CD_09_c4         0.2 IO/sec
    c4: GD_IO_RQ_W_LG_SEC         DATA_X_CD_10_c4         0.1 IO/sec
    c4: GD_IO_RQ_R_SM_SEC         DATA_X_CD_00_c4         0.1 IO/sec
    c4: GD_IO_RQ_R_SM_SEC         DATA_X_CD_01_c4         0.1 IO/sec
    c4: GD_IO_RQ_R_SM_SEC         DATA_X_CD_04_c4         0.1 IO/sec
    c4: GD_IO_RQ_R_SM_SEC         DATA_X_CD_06_c4         0.1 IO/sec
    c6: GD_IO_RQ_W_SM_SEC         DATA_X_CD_00_c6         201 IO/sec --
    c6: GD_IO_RQ_W_SM_SEC         DATA_X_CD_01_c6         65.0 IO/sec
    c6: GD_IO_RQ_W_SM_SEC         DATA_X_CD_02_c6         63.1 IO/sec
    c6: GD_IO_RQ_W_SM_SEC         DATA_X_CD_03_c6         192 IO/sec
    c6: GD_IO_RQ_W_SM_SEC         DATA_X_CD_04_c6         23.0 IO/sec
    c6: GD_IO_RQ_W_SM_SEC         DATA_X_CD_05_c6         59.1 IO/sec
    c6: GD_IO_RQ_W_SM_SEC         DATA_X_CD_06_c6         42.9 IO/sec
    c6: GD_IO_RQ_W_SM_SEC         DATA_X_CD_07_c6         18.9 IO/sec
    c6: GD_IO_RQ_W_SM_SEC         DATA_X_CD_08_c6         139 IO/sec
    c6: GD_IO_RQ_W_SM_SEC         DATA_X_CD_09_c6         296 IO/sec
    c6: GD_IO_RQ_W_SM_SEC         DATA_X_CD_10_c6         146 IO/sec
    c6: GD_IO_RQ_W_SM_SEC         DATA_X_CD_11_c6         11.9 IO/sec -- Total: 1257.9
    c6: GD_IO_RQ_W_LG_SEC         DATA_X_CD_01_c6         0.2 IO/sec
    c6: GD_IO_RQ_W_LG_SEC         DATA_X_CD_04_c6         0.1 IO/sec
    c6: GD_IO_RQ_W_LG_SEC         DATA_X_CD_08_c6         0.1 IO/sec
    c6: GD_IO_RQ_R_SM_SEC         DATA_X_CD_01_c6         0.2 IO/sec
    c6: GD_IO_RQ_R_SM_SEC         DATA_X_CD_05_c6         0.1 IO/sec
    c6: GD_IO_RQ_R_SM_SEC         DATA_X_CD_09_c6         14.2 IO/sec
    c6: GD_IO_RQ_R_SM_SEC         DATA_X_CD_11_c6         0.1 IO/sec
    c7: GD_IO_RQ_W_SM_SEC         DATA_X_CD_00_c7         193 IO/sec --
    c7: GD_IO_RQ_W_SM_SEC         DATA_X_CD_01_c7         63.1 IO/sec
    c7: GD_IO_RQ_W_SM_SEC         DATA_X_CD_02_c7         13.5 IO/sec
    c7: GD_IO_RQ_W_SM_SEC         DATA_X_CD_04_c7         61.7 IO/sec
    c7: GD_IO_RQ_W_SM_SEC         DATA_X_CD_05_c7         106 IO/sec
    c7: GD_IO_RQ_W_SM_SEC         DATA_X_CD_06_c7         23.4 IO/sec
    c7: GD_IO_RQ_W_SM_SEC         DATA_X_CD_07_c7         146 IO/sec
    c7: GD_IO_RQ_W_SM_SEC         DATA_X_CD_08_c7         12.4 IO/sec
    c7: GD_IO_RQ_W_SM_SEC         DATA_X_CD_09_c7         64.5 IO/sec
    c7: GD_IO_RQ_W_SM_SEC         DATA_X_CD_10_c7         66.5 IO/sec
    c7: GD_IO_RQ_W_SM_SEC         DATA_X_CD_11_c7         112 IO/sec -- Total: 862.1
    c7: GD_IO_RQ_W_LG_SEC         DATA_X_CD_00_c7         0.1 IO/sec ===== Всего на всех дисках всех ячеек: 5023.2
    c7: GD_IO_RQ_W_LG_SEC         DATA_X_CD_01_c7         0.1 IO/sec
    c7: GD_IO_RQ_W_LG_SEC         DATA_X_CD_03_c7         0.2 IO/sec
    c7: GD_IO_RQ_W_LG_SEC         DATA_X_CD_05_c7         0.1 IO/sec
    c7: GD_IO_RQ_W_LG_SEC         DATA_X_CD_09_c7         0.1 IO/sec
    c7: GD_IO_RQ_W_LG_SEC         DATA_X_CD_11_c7         0.3 IO/sec
    c7: GD_IO_RQ_R_SM_SEC         DATA_X_CD_03_c7         15.0 IO/sec
    c7: GD_IO_RQ_R_SM_SEC         DATA_X_CD_05_c7         0.1 IO/sec
    c7: GD_IO_RQ_R_SM_SEC         DATA_X_CD_06_c7         0.1 IO/sec
    c7: GD_IO_RQ_R_SM_SEC         DATA_X_CD_07_c7         2.0 IO/sec
    c7: GD_IO_RQ_R_SM_SEC         DATA_X_CD_08_c7         6.8 IO/sec
    c7: GD_IO_RQ_R_SM_SEC         DATA_X_CD_11_c7         44.0 IO/sec
    [oracle@x1 ~]$ 
    

    Я просуммировал число одно-блоковых записей в секунду (GD_IO_RQ_W_SM_SEC) и получил результаты для каждой "ячейки" и для всего кластера в целом. Как видно, все 7 "ячеек" производят вместе 5023.2 "одно-блоковых" записей в секунду. Это число включает запросы со всех instances всех баз данных в кластере (т.е. "DBA1"-"DBA4" и "DBB1"-"DBB4")

    Данные были получены непосредственно с Exadata Storage Servers, используя "cellcli" интерфейс. Метрики с "ячейки" представляют самый нижний уровень мониторинга в Exadata. Те же самые данные можно увидеть "выше" - на уровне ASM файлов и на уровне системной статистики базы данных. Проверим это.

    IOPS: На уровне дата файлов

  • Вычислим количество дисковых операций в секунду:
  • -- check IOPS on datafile level:
      1  select distinct systimestamp, sum(SMALL_WRITE_REQS)
      2  from V$IOSTAT_FILE
      3  where FILE_NO in (select file_no from v$asm_file
      4  where GROUP_NUMBER in (
      5  select GROUP_NUMBER from v$asm_diskgroup where name = 'DATA_X')
      6* )
    15:37:01 SQL> /
    
    SYSTIMESTAMP								    SUM(SMALL_WRITE_REQS)
    --------------------------------------------------------------------------- ---------------------
    30-APR-11 03.37.02.575398 PM +02:00							 17159759
    
    1 row selected.
    
    Elapsed: 00:00:04.66
    15:37:07 SQL> /
    
    SYSTIMESTAMP								    SUM(SMALL_WRITE_REQS)
    --------------------------------------------------------------------------- ---------------------
    30-APR-11 03.37.24.325819 PM +02:00							 17264966
    
    1 row selected.
    
    Elapsed: 00:00:02.58
    15:37:26 SQL> /
    
    SYSTIMESTAMP								    SUM(SMALL_WRITE_REQS)
    --------------------------------------------------------------------------- ---------------------
    30-APR-11 03.37.45.434398 PM +02:00							 17356286
    
    1 row selected.
    
    Elapsed: 00:00:02.34
    15:37:47 SQL> /
    
    SYSTIMESTAMP								    SUM(SMALL_WRITE_REQS)
    --------------------------------------------------------------------------- ---------------------
    30-APR-11 03.37.55.635259 PM +02:00							 17387751
    
    1 row selected.
    
    Elapsed: 00:00:02.07
    15:37:57 SQL> select (17387751-17159759)/53 from dual;
    
    (17387751-17159759)/53
    ----------------------
    	    4301.73585  -- Single Block Writes per Second, зарегистрированных на уровне 
    	    		-- datafiles (ASM), для instance "DBA1".
    			-- Приблизительно совпадает с метриками на Storage Servers.
    
    1 row selected.
    
    Elapsed: 00:00:00.00
    15:50:01 SQL> 
    

    Поскольку кластерное представление "GV$IOSTAT_FILE" не использовалось, 4301 IOPS представляет количество "одно-блоковых" дисковых записей только для первого instance базы данных - "DBA1".

    IOPS: На уровне базы данных

  • Посмотрим, сколько дисковых операций в секунду регистрируется ядром базы данных.
  • Вначале убедимся, что Exadata FlashCache участвует в процессе и выдает нам кэшированные данные, вместо чтения их с физических дисков:

    -- READS from Storage Server's FlashCache
    select systimestamp, name, value
      2  from v$sysstat
      3* where name  = 'physical read requests optimized'
    15:17:06 SQL> /
    
    SYSTIMESTAMP
    ---------------------------------------------------------------------------
    NAME                                                                  VALUE
    ---------------------------------------------------------------- ----------
    30-APR-11 03.17.07.842583 PM +02:00
    physical read requests optimized                                     183254
    
    
    1 row selected.
    
    Elapsed: 00:00:00.02
    15:17:07 SQL> /
    
    SYSTIMESTAMP
    ---------------------------------------------------------------------------
    NAME                                                                  VALUE
    ---------------------------------------------------------------- ----------
    30-APR-11 03.17.11.039970 PM +02:00
    physical read requests optimized                                     183415
    
    
    1 row selected.
    
    Elapsed: 00:00:00.02
    15:17:11 SQL> /
    
    SYSTIMESTAMP
    ---------------------------------------------------------------------------
    NAME                                                                  VALUE
    ---------------------------------------------------------------- ----------
    30-APR-11 03.17.20.343953 PM +02:00
    physical read requests optimized                                     183774
    
    
    1 row selected.
    
    Elapsed: 00:00:00.02
    15:17:20 SQL> /
    
    SYSTIMESTAMP
    ---------------------------------------------------------------------------
    NAME                                                                  VALUE
    ---------------------------------------------------------------- ----------
    30-APR-11 03.17.35.201467 PM +02:00
    physical read requests optimized                                     184332
    
    
    1 row selected.
    
    Elapsed: 00:00:00.01
    15:17:35 SQL> select (184332-183254)/28 from dual;
    
    (184332-183254)/28
    ------------------
                  38.5 -- optimized reads from FlashCache per second
    
    1 row selected.
    
    Elapsed: 00:00:00.00
    15:18:17 SQL> 
    

    Статистика "physical read requests optimized" показывает сколько дисковых операций (чтение) было выполнено из FlashCache на "ячейках", без обращения к физическим дискам. (Также эта статистика имеет отношение к Exadata Storage Index, но мы проигнорируем этот факт)

    Теперь взглянем на операции записи (на уровне одного instance базы данных) и сравним их с метриками, полученными непосредственно с "ячеек" выше.

    Документация ("Oracle Database Reference 11g Release 2 (11.2)") говорит, что: "physical write total IO requests" - Number of write requests which wrote one or more database blocks from all instance activity including application activity, backup and recovery, and other utilities. The difference between this stat and "physical write total multi block requests" gives the number of single block write requests. То есть, вычитая число "многоблоковых" записей из общего числа всех дисковых записей, мы получим количество "одноблоковых" дисковых операций записи, что нам и необходимо для сравнения с "GD_IO_RQ_W_SM_SEC" на "ячейках":

    -- WRITE IOPS on database level, for Single Block 
      1  select systimestamp, name, value
      2   from v$sysstat
      3   where name  in ('physical write total IO requests',
      4  'physical write total multi block requests')
      5* order by name
    15:27:32 SQL> /
    
    SYSTIMESTAMP
    ---------------------------------------------------------------------------
    NAME								      VALUE
    ---------------------------------------------------------------- ----------
    30-APR-11 03.27.34.081032 PM +02:00
    physical write total IO requests				   14571759
    
    30-APR-11 03.27.34.081032 PM +02:00
    physical write total multi block requests			      19890
    
    
    2 rows selected.
    
    Elapsed: 00:00:00.02
    15:27:34 SQL> /
    
    SYSTIMESTAMP
    ---------------------------------------------------------------------------
    NAME								      VALUE
    ---------------------------------------------------------------- ----------
    30-APR-11 03.27.38.767172 PM +02:00
    physical write total IO requests				   14590961
    
    30-APR-11 03.27.38.767172 PM +02:00
    physical write total multi block requests			      19912
    
    
    2 rows selected.
    
    Elapsed: 00:00:00.02
    15:27:38 SQL> /
    
    SYSTIMESTAMP
    ---------------------------------------------------------------------------
    NAME								      VALUE
    ---------------------------------------------------------------- ----------
    30-APR-11 03.27.57.362925 PM +02:00
    physical write total IO requests				   14680257
    
    30-APR-11 03.27.57.362925 PM +02:00
    physical write total multi block requests			      20018
    
    
    2 rows selected.
    
    Elapsed: 00:00:00.02
    15:27:57 SQL> /
    
    SYSTIMESTAMP
    ---------------------------------------------------------------------------
    NAME								      VALUE
    ---------------------------------------------------------------- ----------
    30-APR-11 03.28.06.042151 PM +02:00
    physical write total IO requests				   14718630
    
    30-APR-11 03.28.06.042151 PM +02:00
    physical write total multi block requests			      20063
    
    
    2 rows selected.
    
    Elapsed: 00:00:00.02
    15:28:06 SQL> select (14718630-14571759)-(20063-19890) from dual;
    
    (14718630-14571759)-(20063-19890)
    ---------------------------------
    			   146698
    
    1 row selected.
    
    Elapsed: 00:00:00.00
    15:28:50 SQL> select 146698/32 from dual;
    
     146698/32
    ----------
     4584.3125 -- Single block writes per second
    
    1 row selected.
    
    Elapsed: 00:00:00.00
    15:29:37 SQL> 
    

    Учитывая что это число (4584 IOPS) "одноблоковых" записей в секунду только на первом instance базы "DBA", где SwingBench производит большинство транзакций - можно сказать что показания на уровнях системной статистики базы данных, ASM datafiles и метрик Exadata Storage Servers приблизительно совпадают.

  • На первом узле кластера остановим единственный работающий генератор нагрузки SwingBench, имитирующий 20 пользователей и проверим результаты первого теста:
  • Изучим содержание последнего xml файла:
    -rw-r--r-- 1 oracle oinstall 2.8K Apr 30 15:37 results00002.xml
    
    <Results>
       <Overview>
          <BenchmarkName>Order Entry (jdbc)</BenchmarkName>
          <Comment>"Simple Order Entry benchmark using client side jdbc calls"</Comment>
          <TimeOfRun>Apr 30, 2011 2:33:30 PM</TimeOfRun>
          <TotalRunTime>1:04:22</TotalRunTime>	----- 1 час
          <TotalLogonTime>0:00:00</TotalLogonTime>
          <TotalCompletedTransactions>5997206</TotalCompletedTransactions>
          <TotalFailedTransactions>173</TotalFailedTransactions>
          <AverageTransactionsPerSecond>1552.88</AverageTransactionsPerSecond>  ---- 1500 TPS
          <MaximumTransactionRate>104545</MaximumTransactionRate>
       </Overview>
       <Configuration>
          <NumberOfUsers>20</NumberOfUsers>
          <MinimumThinkTime>0</MinimumThinkTime>
          <MaximumThinkTime>0</MaximumThinkTime>
          <ConnectString>//x-scan:1521/DBA</ConnectString>
          <TimingsIn>miliseconds</TimingsIn>
       </Configuration>
       <DMLResults>					---- Transactions volumes
          <SelectStatements>30322078</SelectStatements>
          <InsertStatements>10143597</InsertStatements>
          <UpdateStatements>6216603</UpdateStatements>
          <DeleteStatements>0</DeleteStatements>
          <CommitStatements>7632602</CommitStatements>
          <RollbackStatements>0</RollbackStatements>
       </DMLResults>
       <TransactionResults>
          <Result id="Customer Registration">
             <AverageResponse>5</AverageResponse>
             <MinimumResponse>1</MinimumResponse>
             <MaximumResponse>2973</MaximumResponse>
             <TransactionCount>544101</TransactionCount>
             <FailedTransactionCount>0</FailedTransactionCount>
          </Result>
          <Result id="Browse Products">
             <AverageResponse>10</AverageResponse>
             <MinimumResponse>1</MinimumResponse>
             <MaximumResponse>3040</MaximumResponse>
             <TransactionCount>1527349</TransactionCount>
             <FailedTransactionCount>0</FailedTransactionCount>
          </Result>
          <Result id="Order Products">
             <AverageResponse>33</AverageResponse>
             <MinimumResponse>6</MinimumResponse>
             <MaximumResponse>3225</MaximumResponse>
             <TransactionCount>1091122</TransactionCount>
             <FailedTransactionCount>173</FailedTransactionCount>
          </Result>
          <Result id="Process Orders">
             <AverageResponse>9</AverageResponse>
             <MinimumResponse>1</MinimumResponse>
             <MaximumResponse>3122</MaximumResponse>
             <TransactionCount>1307243</TransactionCount>
             <FailedTransactionCount>0</FailedTransactionCount>
          </Result>
          <Result id="Browse Orders">
             <AverageResponse>3</AverageResponse>
             <MinimumResponse>1</MinimumResponse>
             <MaximumResponse>3180</MaximumResponse>
             <TransactionCount>1527391</TransactionCount>
             <FailedTransactionCount>0</FailedTransactionCount>
          </Result>
       </TransactionResults>
    </Results>
    

    Результат первого SwingBench теста: Все вместе наши 20 пользователей производили около 1500 транзакций в секунду, со средним временем отклика 12 миллисекунд. При этом все "ячейки" обеспечивали около 5000 дисковых операций в секунду (IOPS). Первый узел кластера генерировал приблизительно 50% общего числа транзакций, согласно сравнению статистики использования ресурсов процессора на всех узлах кластера.

    Первый DataPump import тест, без ограничений

    После проведения предыдущего теста, большое количество новых записей было добавлено в таблицы базовой схемы SwingBench (SOE). Перед следующим SwingBench тестом все эти записи надо удалить, чтобы оба теста начинали свою работу в совершенно одинаковых условиях. Самый простой способ привести схему SOE в ее начальное состояние - удалить ее полностью и загрузить заново с помощью DataPump, используя заранее подготовленный "эталонный" dump file.

  • Прежде чем мы начнем импортировать схему SOE заново, проверим текущую конфигурацию IORM на "ячейках" и убедимся что в данный момент никаких ограничений на количество дисковых операций нет. В это же время подготовим Interdatabase IORM планы на каждой "ячейке", но не будем активировать их.
  • На каждой "ячейке" план определяет "потолок" в 1% от максимального числа дисковых операций для базы "DBA", и 99% для всех остальных баз. Директива "low_latency" рекомендована для использования в OLTP системах (с которой мы и имеем дело) - эта директива планирует дисковые запросы так, что каждый из них выполняется как можно быстрее.

    Команда "cellcli" используется только на Exadata Storage Servers, в отличие от "dcli", используемой чаще всего на узлах кластера.

    -------------------- Проверка IORM планов ----------------------------
    -- Эти метрики будут использованы:
    CellCLI> list METRICDEFINITION DB_IO_UTIL_LG, DB_IO_UTIL_SM  detail
    	 name:              	 DB_IO_UTIL_LG
    	 description:       	 "Percentage of disk resources utilized by large requests from this database"
    	 			 -- "много-блоковые" дисковые операции, утилизация в % для каждой кластерной базы
    	 metricType:        	 Instantaneous
    	 objectType:        	 IORM_DATABASE
    	 unit:              	 %
    
    	 name:              	 DB_IO_UTIL_SM
    	 description:       	 "Percentage of disk resources utilized by small requests from this database"
    	 			 -- "одно-блоковые" дисковые операции, утилизация в % для каждой кластерной базы
    	 metricType:        	 Instantaneous
    	 objectType:        	 IORM_DATABASE
    	 unit:              	 %
    
    CellCLI> 
    
    -- Подготовим план для использования в будущем, но пока не будем активировать его.
    [oracle@x1 ~]$ dcli -g cell_group -l root cellcli -e "alter iormplan
    objective=\'low_latency\'\,
    dbPlan=\(\(name=\'DBA\',limit=1\),\(name=other,limit=99\)\)"
    c1: IORMPLAN successfully altered
    c2: IORMPLAN successfully altered
    c3: IORMPLAN successfully altered
    c4: IORMPLAN successfully altered
    c5: IORMPLAN successfully altered
    c6: IORMPLAN successfully altered
    c7: IORMPLAN successfully altered
    [oracle@x1 ~]$ 
    -- План создан на каждой "ячейке"
    
    -- Убедимся что  IORM планы не используются:
    [oracle@x1 ~]$ dcli -g cell_group -l root cellcli -e "list iormplan"
    c1: c1_IORMPLAN	 inactive
    c2: c2_IORMPLAN	 inactive
    c3: c3_IORMPLAN	 inactive
    c4: c4_IORMPLAN	 inactive
    c5: c5_IORMPLAN	 inactive
    c6: c6_IORMPLAN	 inactive
    c7: c7_IORMPLAN	 inactive
    [oracle@x1 ~]$ 
    

  • Существует способ для быстрой проверки "уровня потребления" дисковых операций каждой базой. Эта команда позволяет оценить ситуацию быстро и не требует вычислений общего числа IOPS:
  • -- Все IORM метрики должны показывать нули:
    [oracle@x1 ~]$ dcli -g cell_group -l root cellcli -e "LIST METRICCURRENT
    DB_IO_UTIL_LG, DB_IO_UTIL_SM, DB_IO_WT_SM_RQ, DB_IO_WT_LG_RQ ATTRIBUTES name,
    metricObjectName, metricValue  where metricObjectName=\'DBA\';"
    
    c1: DB_IO_UTIL_LG 	 DBA	 0 %		-- "много-блоковые" дисковые операции
    c1: DB_IO_UTIL_SM 	 DBA	 0 %		-- "одно-блоковые" дисковые операции
    c1: DB_IO_WT_SM_RQ	 DBA	 0.0 ms/request -- "одно-блоковая" запись
    c1: DB_IO_WT_LG_RQ	 DBA	 0.0 ms/request -- "много-блоковая" запись
    c2: DB_IO_UTIL_LG 	 DBA	 0 %
    c2: DB_IO_UTIL_SM 	 DBA	 0 %
    c2: DB_IO_WT_SM_RQ	 DBA	 0.0 ms/request
    c2: DB_IO_WT_LG_RQ	 DBA	 0.0 ms/request
    c3: DB_IO_UTIL_LG 	 DBA	 0 %
    c3: DB_IO_UTIL_SM 	 DBA	 0 %
    c3: DB_IO_WT_SM_RQ	 DBA	 0.0 ms/request
    c3: DB_IO_WT_LG_RQ	 DBA	 0.0 ms/request
    c4: DB_IO_UTIL_LG 	 DBA	 0 %
    c4: DB_IO_UTIL_SM 	 DBA	 0 %
    c4: DB_IO_WT_SM_RQ	 DBA	 0.0 ms/request
    c4: DB_IO_WT_LG_RQ	 DBA	 0.0 ms/request
    c5: DB_IO_UTIL_LG 	 DBA	 0 %
    c5: DB_IO_UTIL_SM 	 DBA	 0 %
    c5: DB_IO_WT_SM_RQ	 DBA	 0.0 ms/request
    c5: DB_IO_WT_LG_RQ	 DBA	 0.0 ms/request
    c6: DB_IO_UTIL_LG 	 DBA	 0 %
    c6: DB_IO_UTIL_SM 	 DBA	 0 %
    c6: DB_IO_WT_SM_RQ	 DBA	 0.0 ms/request
    c6: DB_IO_WT_LG_RQ	 DBA	 0.0 ms/request
    c7: DB_IO_UTIL_LG 	 DBA	 0 %
    c7: DB_IO_UTIL_SM 	 DBA	 0 %
    c7: DB_IO_WT_SM_RQ	 DBA	 0.0 ms/request
    c7: DB_IO_WT_LG_RQ	 DBA	 0.0 ms/request
    [oracle@x1 ~]$ 
    

  • Метрика "IORM_MODE" показывает какой режим оптимизации дисковых запросов активен на "ячейке" в данный момент:
  • [oracle@x1 ~]$ dcli -g cell_group -l root cellcli -e "LIST METRICCURRENT IORM_MODE;"
    
    c1: IORM_MODE	 c1	 0
    c2: IORM_MODE	 c2	 0
    c3: IORM_MODE	 c3	 0
    c4: IORM_MODE	 c4	 0
    c5: IORM_MODE	 c5	 0
    c6: IORM_MODE	 c6	 0
    c7: IORM_MODE	 c7	 0
    [oracle@x1 ~]$ 
    
    (For IORM_MODE:
     1 means the cell IORM objective was set to low_latency.
     2 means the cell IORM objective was set to balanced.
     3 means the cell IORM objective was set to high_throughput.
    A value in between 1-2 or 2-3 indicates the IORM objective was not the same
    throughout the metric period, and the value indicates proximity to a given objective. It
    is also indicative of a constantly-changing mix of workloads.
    )
    

  • Перейдем ко второму шагу - удалим схему "SOE" и запустим DataPump импорт, без всяких ограничений на число IOPS:
  • -- Test DataPump import:
    
    Import: Release 11.2.0.2.0 - Production on Sun May 1 12:11:30 2011
    ...
    Processing object type SCHEMA_EXPORT/TABLE/TABLE_DATA
    . . imported "SOE"."ORDER_ITEMS":"SYS_P181"              90.47 MB 4193090 rows
    . . imported "SOE"."ORDER_ITEMS":"SYS_P193"              90.34 MB 4187121 rows
    . . imported "SOE"."ORDER_ITEMS":"SYS_P185"              90.63 MB 4200389 rows
    ...
    . . imported "SOE"."PRODUCT_INFORMATION"                 72.67 KB     288 rows
    . . imported "SOE"."WAREHOUSES"                          11.78 KB     191 rows
    Processing object type SCHEMA_EXPORT/TABLE/INDEX/INDEX
         Completed 22 INDEX objects in 98 seconds	-- запомним это значение
    ...
    Job "SYS"."SYS_IMPORT_SCHEMA_03" completed with 2 error(s) at 12:14:36
    
    -- Запомним это значение, весь процесс импорта занял 3 min 6 sec
    

    Запомним время затраченное на создание индексов и время выполнения всего процесса, для сравнения с последующим DataPump тестом.

    Активация IORM плана на каждой "ячейке"

    Как мы помним, одинаковые IORM планы были созданы на всех "ячейках".

    -------------------- Активируем IORM план на всех "ячейках" ----------------
    
    [oracle@x1 ~]$ dcli -g cell_group -l root cellcli -e "alter iormplan active"
    c1: IORMPLAN successfully altered
    c2: IORMPLAN successfully altered
    c3: IORMPLAN successfully altered
    c4: IORMPLAN successfully altered
    c5: IORMPLAN successfully altered
    c6: IORMPLAN successfully altered
    c7: IORMPLAN successfully altered
    [oracle@x1 ~]$ dcli -g cell_group -l root cellcli -e "list iormplan"
    c1: c1_IORMPLAN	 active
    c2: c2_IORMPLAN	 active
    c3: c3_IORMPLAN	 active
    c4: c4_IORMPLAN	 active
    c5: c5_IORMPLAN	 active
    c6: c6_IORMPLAN	 active
    c7: c7_IORMPLAN	 active
    

    С этого момента абсолютно все дисковые запросы от базы "DBM" будут регистрироваться и становиться в очередь, как только их общая сумма превысит 1% от максимального числа IOPS.

    Второй DataPump import тест, с ограниченным числом IOPS

    Теперь повторим наш предыдущий импорт схемы "SOE". При этом ожидается что ячейки будут ограничивать количество дисковых операций от базы "DBA", увеличивая длительность создания индексов и всего импорта.

    -- IORM Data Pump test:
    
    Import: Release 11.2.0.2.0 - Production on Sun May 1 12:21:45 2011
    ...
    . . imported "SOE"."ORDER_ITEMS":"SYS_P181"              90.47 MB 4193090 rows
    . . imported "SOE"."ORDER_ITEMS":"SYS_P185"              90.63 MB 4200389 rows
    . . imported "SOE"."ORDER_ITEMS":"SYS_P193"              90.34 MB 4187121 rows
    ...
    . . imported "SOE"."PRODUCT_DESCRIPTIONS"                86.67 KB     288 rows
    . . imported "SOE"."PRODUCT_INFORMATION"                 72.67 KB     288 rows
    . . imported "SOE"."WAREHOUSES"                          11.78 KB     191 rows
    Processing object type SCHEMA_EXPORT/TABLE/INDEX/INDEX
         Completed 22 INDEX objects in 441 seconds		-- было 98 sec
    ...
    Job "SYS"."SYS_IMPORT_SCHEMA_03" completed with 2 error(s) at 12:30:35 -- 8 min 50 sec
    

    Как видно, создание индексов заняло в 5 раз дольше и длительность всего импорта возросла в 3 раза. Тем не менее, мы не нагрузили систему достаточно, чтобы увидеть изменения в % IO utilization:

    Во время импорта я периодически выполнял такую команду:
    
    [oracle@x1 ~]$ dcli -g cell_group -l root cellcli -e "LIST METRICCURRENT DB_IO_UTIL_LG, 
    DB_IO_UTIL_SM, DB_IO_WT_SM_RQ, DB_IO_WT_LG_RQ ATTRIBUTES name, metricObjectName, 
    metricValue  where metricObjectName=\'DBA\';"
    
    c1: DB_IO_UTIL_LG 	 DBA	 0 %
    c1: DB_IO_UTIL_SM 	 DBA	 0 %
    c1: DB_IO_WT_SM_RQ	 DBA	 4.8 ms/request
    c1: DB_IO_WT_LG_RQ	 DBA	 0.0 ms/request
    c2: DB_IO_UTIL_LG 	 DBA	 0 %
    c2: DB_IO_UTIL_SM 	 DBA	 0 %
    c2: DB_IO_WT_SM_RQ	 DBA	 0.0 ms/request
    c2: DB_IO_WT_LG_RQ	 DBA	 0.0 ms/request
    c3: DB_IO_UTIL_LG 	 DBA	 0 %
    c3: DB_IO_UTIL_SM 	 DBA	 0 %
    c3: DB_IO_WT_SM_RQ	 DBA	 24.5 ms/request
    c3: DB_IO_WT_LG_RQ	 DBA	 0.0 ms/request
    c4: DB_IO_UTIL_LG 	 DBA	 0 %
    c4: DB_IO_UTIL_SM 	 DBA	 0 %
    c4: DB_IO_WT_SM_RQ	 DBA	 0.0 ms/request
    c4: DB_IO_WT_LG_RQ	 DBA	 0.0 ms/request
    c5: DB_IO_UTIL_LG 	 DBA	 0 %
    c5: DB_IO_UTIL_SM 	 DBA	 0 %
    c5: DB_IO_WT_SM_RQ	 DBA	 0.0 ms/request
    c5: DB_IO_WT_LG_RQ	 DBA	 0.0 ms/request
    c6: DB_IO_UTIL_LG 	 DBA	 0 %
    c6: DB_IO_UTIL_SM 	 DBA	 0 %
    c6: DB_IO_WT_SM_RQ	 DBA	 0.0 ms/request
    c6: DB_IO_WT_LG_RQ	 DBA	 0.0 ms/request
    c7: DB_IO_UTIL_LG 	 DBA	 0 %
    c7: DB_IO_UTIL_SM 	 DBA	 0 %
    c7: DB_IO_WT_SM_RQ	 DBA	 180 ms/request
    c7: DB_IO_WT_LG_RQ	 DBA	 87.8 ms/request
    
    [oracle@x1 ~]$ dcli -g cell_group -l root cellcli -e "LIST METRICCURRENT
    DB_IO_UTIL_LG,
    DB_IO_UTIL_SM, DB_IO_WT_SM_RQ, DB_IO_WT_LG_RQ ATTRIBUTES name, metricObjectName,
    metricValue  where metricObjectName=\'DBA\';"
    
    c1: DB_IO_UTIL_LG 	 DBA	 0 %
    c1: DB_IO_UTIL_SM 	 DBA	 0 %
    c1: DB_IO_WT_SM_RQ	 DBA	 0.0 ms/request
    c1: DB_IO_WT_LG_RQ	 DBA	 0.0 ms/request
    c2: DB_IO_UTIL_LG 	 DBA	 0 %
    c2: DB_IO_UTIL_SM 	 DBA	 0 %
    c2: DB_IO_WT_SM_RQ	 DBA	 39.0 ms/request
    c2: DB_IO_WT_LG_RQ	 DBA	 44.1 ms/request
    c3: DB_IO_UTIL_LG 	 DBA	 0 %
    c3: DB_IO_UTIL_SM 	 DBA	 0 %
    c3: DB_IO_WT_SM_RQ	 DBA	 15.5 ms/request
    c3: DB_IO_WT_LG_RQ	 DBA	 0.0 ms/request
    c4: DB_IO_UTIL_LG 	 DBA	 0 %
    c4: DB_IO_UTIL_SM 	 DBA	 0 %
    c4: DB_IO_WT_SM_RQ	 DBA	 11.5 ms/request
    c4: DB_IO_WT_LG_RQ	 DBA	 37.3 ms/request
    c5: DB_IO_UTIL_LG 	 DBA	 0 %
    c5: DB_IO_UTIL_SM 	 DBA	 0 %
    c5: DB_IO_WT_SM_RQ	 DBA	 0.0 ms/request
    c5: DB_IO_WT_LG_RQ	 DBA	 0.0 ms/request
    c6: DB_IO_UTIL_LG 	 DBA	 0 %
    c6: DB_IO_UTIL_SM 	 DBA	 0 %
    c6: DB_IO_WT_SM_RQ	 DBA	 0.0 ms/request
    c6: DB_IO_WT_LG_RQ	 DBA	 0.0 ms/request
    c7: DB_IO_UTIL_LG 	 DBA	 0 %
    c7: DB_IO_UTIL_SM 	 DBA	 0 %
    c7: DB_IO_WT_SM_RQ	 DBA	 118 ms/request
    c7: DB_IO_WT_LG_RQ	 DBA	 103 ms/request
    
    [oracle@x1 ~]$ dcli -g cell_group -l root cellcli -e "LIST METRICCURRENT
    DB_IO_UTIL_LG,
    DB_IO_UTIL_SM, DB_IO_WT_SM_RQ, DB_IO_WT_LG_RQ ATTRIBUTES name, metricObjectName,
    metricValue  where metricObjectName=\'DBA\';"
    
    c1: DB_IO_UTIL_LG 	 DBA	 0 %
    c1: DB_IO_UTIL_SM 	 DBA	 0 %
    c1: DB_IO_WT_SM_RQ	 DBA	 0.0 ms/request
    c1: DB_IO_WT_LG_RQ	 DBA	 0.0 ms/request
    c2: DB_IO_UTIL_LG 	 DBA	 0 %
    c2: DB_IO_UTIL_SM 	 DBA	 0 %
    c2: DB_IO_WT_SM_RQ	 DBA	 0.0 ms/request
    c2: DB_IO_WT_LG_RQ	 DBA	 1.7 ms/request
    c3: DB_IO_UTIL_LG 	 DBA	 0 %
    c3: DB_IO_UTIL_SM 	 DBA	 0 %
    c3: DB_IO_WT_SM_RQ	 DBA	 0.0 ms/request
    c3: DB_IO_WT_LG_RQ	 DBA	 0.0 ms/request
    c4: DB_IO_UTIL_LG 	 DBA	 0 %
    c4: DB_IO_UTIL_SM 	 DBA	 0 %
    c4: DB_IO_WT_SM_RQ	 DBA	 44.9 ms/request
    c4: DB_IO_WT_LG_RQ	 DBA	 0.0 ms/request
    c5: DB_IO_UTIL_LG 	 DBA	 0 %
    c5: DB_IO_UTIL_SM 	 DBA	 0 %
    c5: DB_IO_WT_SM_RQ	 DBA	 0.0 ms/request
    c5: DB_IO_WT_LG_RQ	 DBA	 0.0 ms/request
    c6: DB_IO_UTIL_LG 	 DBA	 0 %
    c6: DB_IO_UTIL_SM 	 DBA	 0 %
    c6: DB_IO_WT_SM_RQ	 DBA	 0.0 ms/request
    c6: DB_IO_WT_LG_RQ	 DBA	 0.0 ms/request
    c7: DB_IO_UTIL_LG 	 DBA	 0 %
    c7: DB_IO_UTIL_SM 	 DBA	 0 %
    c7: DB_IO_WT_SM_RQ	 DBA	 157 ms/request		-- !!!!! запрос явно был поставлен в очередь
    c7: DB_IO_WT_LG_RQ	 DBA	 162 ms/request		-- !!!!!
    [oracle@x1 ~]$ 
    

    Выполним еще один, последний, SwingBench тест в надежде нагрузить систему достаточно до 1% от максимального числа дисковых операций.

    Второй SwingBench тест, с ограниченным числом IOPS

    Планы на ячейках по-прежнему активны, схема "SOE" создана заново и заполнена "эталонными" данными.

  • Запустим тест в такой же конфигурации, как в первый раз - 20 пользователей.
  • -- Start SwingBench
    [oracle@x1 bin]$ ./charbench 
    Version :	 2.3.0.422
    
    Results will be written to results.xml.
    Hit Return to Start & Terminate Run...
    
    Time		Users	TPM	TPS
    12:46:31 PM     20      22820   245   
    

  • Во время теста, будем периодически проверять IORM метрики. После первых 3 минут работы база "DBA" превысит свой "потолок" числа IOPS на первой "ячейке". Через некоторое время то же самое произойдет на других "ячейках".
  • [oracle@x1 ~]$ dcli -g cell_group -l root cellcli -e "LIST METRICCURRENT DB_IO_UTIL_LG, 
    DB_IO_UTIL_SM, DB_IO_WT_SM_RQ, DB_IO_WT_LG_RQ ATTRIBUTES name, metricObjectName, 
    metricValue  where metricObjectName=\'DBA\';"
    
    c1: DB_IO_UTIL_LG 	 DBA	 0 %
    c1: DB_IO_UTIL_SM 	 DBA	 1 %		-- !!!! "потолок" достигнут
    c1: DB_IO_WT_SM_RQ	 DBA	 0.0 ms/request
    c1: DB_IO_WT_LG_RQ	 DBA	 0.0 ms/request
    c2: DB_IO_UTIL_LG 	 DBA	 0 %
    c2: DB_IO_UTIL_SM 	 DBA	 0 %
    c2: DB_IO_WT_SM_RQ	 DBA	 19.2 ms/request
    c2: DB_IO_WT_LG_RQ	 DBA	 149 ms/request
    c3: DB_IO_UTIL_LG 	 DBA	 0 %
    c3: DB_IO_UTIL_SM 	 DBA	 0 %
    c3: DB_IO_WT_SM_RQ	 DBA	 42.4 ms/request -- !!!! Single block write ...
    c3: DB_IO_WT_LG_RQ	 DBA	 301 ms/request  -- ... and multiblock write
    c4: DB_IO_UTIL_LG 	 DBA	 0 %
    c4: DB_IO_UTIL_SM 	 DBA	 0 %
    c4: DB_IO_WT_SM_RQ	 DBA	 36.4 ms/request
    c4: DB_IO_WT_LG_RQ	 DBA	 126 ms/request
    c5: DB_IO_UTIL_LG 	 DBA	 0 %
    c5: DB_IO_UTIL_SM 	 DBA	 0 %
    c5: DB_IO_WT_SM_RQ	 DBA	 0.0 ms/request
    c5: DB_IO_WT_LG_RQ	 DBA	 0.0 ms/request
    c6: DB_IO_UTIL_LG 	 DBA	 0 %
    c6: DB_IO_UTIL_SM 	 DBA	 0 %
    c6: DB_IO_WT_SM_RQ	 DBA	 0.0 ms/request
    c6: DB_IO_WT_LG_RQ	 DBA	 0.0 ms/request
    c7: DB_IO_UTIL_LG 	 DBA	 0 %
    c7: DB_IO_UTIL_SM 	 DBA	 0 %
    c7: DB_IO_WT_SM_RQ	 DBA	 0.0 ms/request
    c7: DB_IO_WT_LG_RQ	 DBA	 0.0 ms/request
    [oracle@x1 ~]$ 
    
    [oracle@x1 ~]$ dcli -g cell_group -l root cellcli -e "LIST METRICCURRENT
    DB_IO_UTIL_LG, 
    DB_IO_UTIL_SM, DB_IO_WT_SM_RQ, DB_IO_WT_LG_RQ ATTRIBUTES name, metricObjectName, 
    metricValue  where metricObjectName=\'DBA\';"
    
    c1: DB_IO_UTIL_LG 	 DBA	 0 %
    c1: DB_IO_UTIL_SM 	 DBA	 1 %
    c1: DB_IO_WT_SM_RQ	 DBA	 27.8 ms/request
    c1: DB_IO_WT_LG_RQ	 DBA	 65.0 ms/request
    c2: DB_IO_UTIL_LG 	 DBA	 0 %
    c2: DB_IO_UTIL_SM 	 DBA	 0 %
    c2: DB_IO_WT_SM_RQ	 DBA	 0.0 ms/request
    c2: DB_IO_WT_LG_RQ	 DBA	 0.0 ms/request
    c3: DB_IO_UTIL_LG 	 DBA	 0 %
    c3: DB_IO_UTIL_SM 	 DBA	 1 %
    c3: DB_IO_WT_SM_RQ	 DBA	 18.4 ms/request
    c3: DB_IO_WT_LG_RQ	 DBA	 272 ms/request
    c4: DB_IO_UTIL_LG 	 DBA	 0 %
    c4: DB_IO_UTIL_SM 	 DBA	 0 %
    c4: DB_IO_WT_SM_RQ	 DBA	 18.8 ms/request
    c4: DB_IO_WT_LG_RQ	 DBA	 84.1 ms/request
    c5: DB_IO_UTIL_LG 	 DBA	 0 %
    c5: DB_IO_UTIL_SM 	 DBA	 0 %
    c5: DB_IO_WT_SM_RQ	 DBA	 0.0 ms/request
    c5: DB_IO_WT_LG_RQ	 DBA	 0.0 ms/request
    c6: DB_IO_UTIL_LG 	 DBA	 0 %
    c6: DB_IO_UTIL_SM 	 DBA	 1 %
    c6: DB_IO_WT_SM_RQ	 DBA	 0.0 ms/request
    c6: DB_IO_WT_LG_RQ	 DBA	 0.0 ms/request
    c7: DB_IO_UTIL_LG 	 DBA	 0 %
    c7: DB_IO_UTIL_SM 	 DBA	 1 %
    c7: DB_IO_WT_SM_RQ	 DBA	 8.1 ms/request
    c7: DB_IO_WT_LG_RQ	 DBA	 39.8 ms/request
    [oracle@x1 ~]$ 
    
    [oracle@x1 ~]$ dcli -g cell_group -l root cellcli -e "LIST METRICCURRENT
    DB_IO_UTIL_LG, DB_IO_UTIL_SM, DB_IO_WT_SM_RQ, DB_IO_WT_LG_RQ ATTRIBUTES name,
    metricObjectName, metricValue  where metricObjectName=\'DBA\';"
    
    c1: DB_IO_UTIL_LG 	 DBA	 0 %
    c1: DB_IO_UTIL_SM 	 DBA	 1 %			-- !!!!
    c1: DB_IO_WT_SM_RQ	 DBA	 1.7 ms/request
    c1: DB_IO_WT_LG_RQ	 DBA	 79.4 ms/request
    c2: DB_IO_UTIL_LG 	 DBA	 0 %
    c2: DB_IO_UTIL_SM 	 DBA	 1 %			-- !!!!
    c2: DB_IO_WT_SM_RQ	 DBA	 0.0 ms/request
    c2: DB_IO_WT_LG_RQ	 DBA	 0.0 ms/request
    c3: DB_IO_UTIL_LG 	 DBA	 0 %
    c3: DB_IO_UTIL_SM 	 DBA	 1 %			-- !!!!
    c3: DB_IO_WT_SM_RQ	 DBA	 8.9 ms/request
    c3: DB_IO_WT_LG_RQ	 DBA	 134 ms/request
    c4: DB_IO_UTIL_LG 	 DBA	 0 %
    c4: DB_IO_UTIL_SM 	 DBA	 1 %			-- !!!!
    c4: DB_IO_WT_SM_RQ	 DBA	 1.9 ms/request
    c4: DB_IO_WT_LG_RQ	 DBA	 20.8 ms/request
    c5: DB_IO_UTIL_LG 	 DBA	 0 %
    c5: DB_IO_UTIL_SM 	 DBA	 0 %
    c5: DB_IO_WT_SM_RQ	 DBA	 0.0 ms/request
    c5: DB_IO_WT_LG_RQ	 DBA	 0.0 ms/request
    c6: DB_IO_UTIL_LG 	 DBA	 0 %
    c6: DB_IO_UTIL_SM 	 DBA	 1 %			-- !!!!
    c6: DB_IO_WT_SM_RQ	 DBA	 0.0 ms/request
    c6: DB_IO_WT_LG_RQ	 DBA	 0.0 ms/request
    c7: DB_IO_UTIL_LG 	 DBA	 0 %
    c7: DB_IO_UTIL_SM 	 DBA	 1 %			-- !!!!
    c7: DB_IO_WT_SM_RQ	 DBA	 0.0 ms/request
    c7: DB_IO_WT_LG_RQ	 DBA	 0.0 ms/request
    [oracle@x1 ~]$ 
    

  • В то же время, мы можем проверить общее число IOPS на всех дисках всех ячеек, в точности как было сделано в первом тесте. В этот раз мы позволим "awk" сделать необходимые вычисления за нас:
  • -- Check the overall Small Block IOPS on all cells:
    [oracle@x1 ~]$ dcli -g cell_group -l root cellcli -e "list METRICCURRENT GD_IO_RQ_W_SM_SEC 
    where metricObjectName like \'DATA_.*\'" | grep -v "0.0 IO/sec" | 
    awk '{x=x+ $4} END{print "Total Single block write IOPS:",x}'
    
    Total Single block write IOPS: 3094.8
    [oracle@x1 ~]$
    

  • Также мы можем проверить число IOPS на уровне ASM datafiles, на каждом instance базы "DBA":
  • --  On each of the instances, run this and calculate:
    
    13:11:36 SQL> select distinct systimestamp, sum(SMALL_WRITE_REQS)
      from V$IOSTAT_FILE
      where FILE_NO in (select file_no from v$asm_file
      where GROUP_NUMBER in (
      select GROUP_NUMBER from v$asm_diskgroup where name = 'DATA_X')
      )
    13:11:41 SQL> 
    
    SYSTIMESTAMP								    SUM(SMALL_WRITE_REQS)
    --------------------------------------------------------------------------- ---------------------
    01-MAY-11 01.11.44.002381 PM +02:00							  2362057
    
    1 row selected.
    
    Elapsed: 00:00:02.53
    13:11:46 SQL> /
    
    SYSTIMESTAMP								    SUM(SMALL_WRITE_REQS)
    --------------------------------------------------------------------------- ---------------------
    01-MAY-11 01.11.50.377955 PM +02:00							  2372665
    
    1 row selected.
    
    -- This instance (#2) makes 1768 IOPS for single block writes (2372665-2362057)/6).
    -- Instance #3 makes 604 IOPS, instance #4 makes 751 IOPS.
    -- There are no swingbench session connected to instance #1:
    
    13:12:06 SQL> select inst_id, count(*)
    13:14:19   2  from gv$session
    13:14:23   3  where username  = 'SOE'
    13:14:31   4  group by inst_id;
    
       INST_ID   COUNT(*)
    ---------- ----------
    	 2	    7
    	 4	    7
    	 3	    6
    
    3 rows selected.
    Elapsed: 00:00:00.01
    

    Как видно, все 20 сессий SwingBench (и все IOPS, потребляемые нашим тестом) распределились между instances 2,3 и 4.

  • Завершим последний тест и проверим как это отразится на общем числе дисковых операций, производимых базой "DBA" на всех "ячейках":
  • -- Finish SwingBench and check:
    -- IOPS on the cells:
    [oracle@x1 ~]$ dcli -g cell_group -l root cellcli -e "list METRICCURRENT
    GD_IO_RQ_W_SM_SEC where metricObjectName like \'DATA_.*\'" | grep -v "0.0
    IO/sec" | awk '{x=x+ $4} END{print "Total Single block write IOPS:",x}'
    
    Total Single block write IOPS: 3.5
    

    Очевидно, что почти все IOPS были результатом работы генератора нагрузки. Обратите внимание, что я рассматриваю только "одно-блоковые" дисковые запросы на запись, поскольку первый тест показал значительное превосходство их числа над всеми другими типами IO.

  • Оценим результаты работы нашего последнего, второго SwingBench теста:
  • -- SwingBench result file:
    -rw-r--r-- 1 oracle oinstall 2.8K May  1 13:20 results00006.xml
    
    [oracle@x1 bin]$ cat results00006.xml
    <Results>
       <Overview>
          <BenchmarkName>Order Entry (jdbc)</BenchmarkName>
          <Comment>"Simple Order Entry benchmark using client side jdbc calls"</Comment>
          <TimeOfRun>May 1, 2011 12:45:55 PM</TimeOfRun>
          <TotalRunTime>0:34:34</TotalRunTime>
          <TotalLogonTime>0:00:00</TotalLogonTime>
          <TotalCompletedTransactions>1709279</TotalCompletedTransactions>
          <TotalFailedTransactions>43</TotalFailedTransactions>
          <AverageTransactionsPerSecond>824.15</AverageTransactionsPerSecond>
          <MaximumTransactionRate>54720</MaximumTransactionRate>
       </Overview>
       <Configuration>
          <NumberOfUsers>20</NumberOfUsers>
          <MinimumThinkTime>0</MinimumThinkTime>
          <MaximumThinkTime>0</MaximumThinkTime>
          <ConnectString>//x-scan:1521/DBA</ConnectString>
          <TimingsIn>miliseconds</TimingsIn>
       </Configuration>
       <DMLResults>
          <SelectStatements>8643481</SelectStatements>
          <InsertStatements>2892938</InsertStatements>
          <UpdateStatements>1772581</UpdateStatements>
          <DeleteStatements>0</DeleteStatements>
          <CommitStatements>2175916</CommitStatements>
          <RollbackStatements>0</RollbackStatements>
       </DMLResults>
       <TransactionResults>
          <Result id="Customer Registration">
             <AverageResponse>11</AverageResponse>
             <MinimumResponse>2</MinimumResponse>
             <MaximumResponse>9816</MaximumResponse>
             <TransactionCount>155277</TransactionCount>
             <FailedTransactionCount>0</FailedTransactionCount>
          </Result>
          <Result id="Browse Products">
             <AverageResponse>24</AverageResponse>
             <MinimumResponse>3</MinimumResponse>
             <MaximumResponse>5271</MaximumResponse>
             <TransactionCount>434885</TransactionCount>
             <FailedTransactionCount>0</FailedTransactionCount>
          </Result>
          <Result id="Order Products">
             <AverageResponse>60</AverageResponse>
             <MinimumResponse>10</MinimumResponse>
             <MaximumResponse>12640</MaximumResponse>
             <TransactionCount>311317</TransactionCount>
             <FailedTransactionCount>43</FailedTransactionCount>
          </Result>
          <Result id="Process Orders">
             <AverageResponse>9</AverageResponse>
             <MinimumResponse>1</MinimumResponse>
             <MaximumResponse>6499</MaximumResponse>
             <TransactionCount>372121</TransactionCount>
             <FailedTransactionCount>0</FailedTransactionCount>
          </Result>
          <Result id="Browse Orders">
             <AverageResponse>12</AverageResponse>
             <MinimumResponse>1</MinimumResponse>
             <MaximumResponse>18717</MaximumResponse>
             <TransactionCount>435679</TransactionCount>
             <FailedTransactionCount>0</FailedTransactionCount>
          </Result>
       </TransactionResults>
    </Results>
    [oracle@x1 bin]$ 
    

    Результат второго SwingBench теста

  • После применения IORM плана, все 20 пользователей производили около 800 транзакций в секунду, со средним временем отклика 24 миллисекунды. При этом все "ячейки" обеспечивали около 3000 дисковых операций в секунду (IOPS). Первый узел кластера не генерировал транзакций.
  • Для сравнения, приведу тут же результаты первого SwingBench теста, без IORM:

  • Все вместе наши 20 пользователей производили около 1500 транзакций в секунду, со средним временем отклика 12 миллисекунд. При этом все "ячейки" обеспечивали около 5000 дисковых операций в секунду (IOPS). Первый узел кластера генерировал приблизительно 50% общего числа транзакций, согласно сравнению статистики использования ресурсов процессора на всех узлах кластера.
  • Результат налицо - мы решили поставленную задачу по ограничению числа дисковых операций для базы данных "DBA", не изменяя раскладки дисковой системы и без вовлечения ее администратора.

    Деактивация IORM плана на каждой "ячейке"

  • Выключить план также просто, как и включить - при этом все его директивы остаются на своих местах:
  • [oracle@x1 ~]$ dcli -g cell_group -l root cellcli -e "alter iormplan inactive"
    c1: IORMPLAN successfully altered
    c2: IORMPLAN successfully altered
    c3: IORMPLAN successfully altered
    c4: IORMPLAN successfully altered
    c5: IORMPLAN successfully altered
    c6: IORMPLAN successfully altered
    c7: IORMPLAN successfully altered
    [oracle@x1 ~]$
    [oracle@x1 ~]$ dcli -g cell_group -l root cellcli -e "list iormplan"
    c1: c1_IORMPLAN  inactive
    c2: c2_IORMPLAN  inactive
    c3: c3_IORMPLAN  inactive
    c4: c4_IORMPLAN  inactive
    c5: c5_IORMPLAN  inactive
    c6: c6_IORMPLAN  inactive
    c7: c7_IORMPLAN  inactive
    [oracle@x1 ~]$
    

    Заметьте, что я мог бы выключить IORM план на некоторых ячейках избирательно, а не на всех сразу.

  • Чтобы удалить план полностью без следов, выполним:
  • -- To reset IORM plans:
    cellcli -e ALTER IORMPLAN dbPlan=\"\"\, catPlan=\"\"
    

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

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


    Сайт не содержит активных элементов - скриптов и cookies