Руководство по наилучшим практикам для racle 11 и · PDF fileOracle Database 11g ... также расширяет утилиту конверсии

Компания Netwell ‐ российский дистрибьютор высокотехнологичного оборудования. Основные направления деятельности – сетевые технологии, системы хранения данных, сетевая и информационная безопасность. Netwell является официальным дистрибьютором компании NetApp.

NETAPP TECHNICAL REPORT

Руководство по наилучшим практикам

для Oracle 11g и системам хранения NetApp

Oracle Alliance Engineering Team, NetApp

Август 2011 | TR-3633

Коротко о главном:

Документ описывает рекомендации и наилучшие практики по эксплуатации баз данных Oracle

Database 11g на системах хранения NetApp, с использованием OS Solaris, HP/UX, AIX, Linux®, и

Windows®. Этот документ отражает работу, проделанную инженерами NetApp и Oracle на

множестве пользовательских системах, использующих совместно наши продукты. Данный

документ следует рассматривать как стартовую справочную точку и минимальный

рекомендованный уровень для развертывания Oracle на NetApp.

Оглавление 1 Введение .................................................................................................................................................. 5

2 Новые возможности Oracle Database 11g.............................................................................................. 5

2.1 Обзор новых возможностей ............................................................................................................ 5

2.2 Direct NFS ........................................................................................................................................... 5

2.3 ASM .................................................................................................................................................... 6

2.4 Real Application Testing ..................................................................................................................... 7

2.5 Advanced compression ...................................................................................................................... 8

2.6 Active Data Guard .............................................................................................................................. 9

2.7 Snapshot Standby Database ............................................................................................................... 9

2.8 Новая инфраструктура grid .............................................................................................................. 9

2.9 Создание сегмента по требованию (On-demand segment creation) ........................................... 10

2.10 Переносимая база данных........................................................................................................... 10

3 Конфигурация системы хранения NetApp ........................................................................................... 10

3.1 Сетевые настройки ......................................................................................................................... 10

Ethernet: Gigabit Ethernet, Autonegotiation, и Full Duplex ............................................................... 11

3.2 Установки для тома и aggregate, а также опции базы данных ................................................... 11

Aggregates и тома типа FlexVol ......................................................................................................... 12

Размеры тома..................................................................................................................................... 12

Рекомендуемые тома для файлов баз данных и логов Oracle ...................................................... 13

Oracle Optimal Flexible Architecture (OFA) на системе хранения NetApp ...................................... 13

Расположение Oracle Home .............................................................................................................. 14

Наилучшие практики и рекомендации для Control- и Log-файлов ............................................... 15

3.3 Размер RAID-групп .......................................................................................................................... 15

3.4 Snapshot и SnapRestore .................................................................................................................. 16

3.5 Snap Reserve .................................................................................................................................... 17

3.6 Системные опции ........................................................................................................................... 17

Опция minra ....................................................................................................................................... 17

Обновление времени последнего обращения к файлу (File access time update) ........................ 18

Настройки NFS V3 .............................................................................................................................. 18

Настройки NFS V4 .............................................................................................................................. 19

Управление свободным пространством и ENOSPC ........................................................................ 19

Direct NFS ............................................................................................................................................ 23

4 Настройка Oracle Database .................................................................................................................... 26

4.1 DISK_ASYNCH_IO .............................................................................................................................. 26

4.2 DB_FILE_MULTIBLOCK_READ_COUNT ............................................................................................. 27

4.3 DB_BLOCK_SIZE ................................................................................................................................ 28

4.4 DBWR_IO_SLAVES и DB_WRITER_PROCESSES ................................................................................ 29

4.5 Flashback и Flash recovery area ....................................................................................................... 30

Flashback ............................................................................................................................................. 30

Flash recovery area ............................................................................................................................. 30

4.6 Oracle Cluster File System 2 (OCFS2) ............................................................................................... 31

Обзор OCFS2 ....................................................................................................................................... 31

Конфигурация OCFS2 ......................................................................................................................... 32

Сервисы O2CB .................................................................................................................................... 32

Монтирование партиций OCFS2 ....................................................................................................... 32

4.7 Хранение файлов Oracle ................................................................................................................ 33

5 Варианты использования ...................................................................................................................... 33

5.1 Защита данных ................................................................................................................................ 33

Резервное копирование и восстановление .................................................................................... 33

5.2 Жизненный цикл данных: Архивация и долговременное хранение ......................................... 41

Создание клонов данных для задач тестирования и разработки ................................................. 41

Использование Oracle Real Application Testing с NetApp FlexClone ............................................... 44

Безопасность Oracle Database 11g .................................................................................................... 52

5.3 Высокая доступность ...................................................................................................................... 55

Отказоустойчивая конфигурация ..................................................................................................... 55

SnapMirror .......................................................................................................................................... 60

MetroCluster ....................................................................................................................................... 65

CFO (Clustered Failover) ...................................................................................................................... 65

Обновление Data ONTAP и NDU ....................................................................................................... 66

5.4 Виртуализация ................................................................................................................................ 68

Концепции виртуализации ............................................................................................................... 68

Преимущества виртуализации ......................................................................................................... 68

Недостатки виртуализации ............................................................................................................... 68

Xen ....................................................................................................................................................... 69

VMware ............................................................................................................................................... 69

6 Приложения ........................................................................................................................................... 70

6.1 Операционные системы................................................................................................................. 70

Linux .................................................................................................................................................... 70

Solaris Operating System .................................................................................................................... 74

IBM AIX ................................................................................................................................................ 83

HP-UX .................................................................................................................................................. 83

6.2 ASM .................................................................................................................................................. 83

ASM с использованием iSCSI/FCP ..................................................................................................... 83

ASM с использованием NFS .............................................................................................................. 84

7 Справочные материалы ........................................................................................................................ 85

8 История изменений документа ............................................................................................................ 86

1 Введение Тысячи пользователей систем NetApp успешно внедряют и эксплуатируют информационные

системы с использованием Oracle® Databases на системах хранения NetApp® для бизнес-

критичных приложений. Специалисты NetApp и Oracle много лет успешно проводят валидацию

продуктов Oracle для использования их с системами хранения NetApp и на различных серверных

платформах. Службы поддержки NetApp и Oracle организовали совместную группу для разбора

пользовательских ситуаций, связанных c совместным использованием наших продуктов, чтобы

разрешать связанные проблемы максимально быстро. В ходе анализа таких проблем специалисты

этой группы отметили, что большинство их связаны с невыполнением рекомендаций наилучших

практик, разработанных для Oracle Databases на системах хранения NetApp.

Этот документ описывает рекомендации и наилучшие практики по эксплуатации баз данных

Oracle Database 11g на системах хранения NetApp, с использованием OS Solaris, HP/UX, AIX, Linux®,

и Windows®. Этот документ отражает работу, проделанную инженерами NetApp и Oracle на

множестве пользовательских системах, использующих совместно наши продукты. Данный

документ следует рассматривать как стартовую справочную точку и минимальный

рекомендованный уровень для развертывания Oracle на NetApp. От него следует ожидать задание

принципов, проверенных методов и приемов, но он не покрывает полностью все возможные

поддерживаемые методы.

Это руководство подразумевает в читателе базовое понимание технологий и операций продуктов

NetApp, и предлагает рекомендации по планированию, внедрению и эксплуатации продуктов

NetApp для максимально эффективного их использования.

2 Новые возможности Oracle Database 11g

2.1 Обзор новых возможностей Oracle Database 11g это новый релиз системы Oracle Database, с впечатляющим списком новых

возможностей. Сотрудничая с Oracle в разработке и тестировании новых возможностей систем

хранения, дополняющих возможности Oracle Database 11g, NetApp находится на самом переднем

краю взаимодействия с Oracle Database 11g.

В этой главе мы рассмотрим некоторые из новых возможностей, которые могут представлять

интерес для пользователей систем хранения NetApp.

2.2 Direct NFS Direct NFS, это клиент NFS, разработанный Oracle, который встроен непосредственно в ядро

приложения Oracle Database 11g. Стандартный клиент NFS, предлагаемый производителями

операционных систем, не оптимизирован под работу с характерным для Oracle Database

паттерном доступа. Используя Oracle Database 11g, вы можете сконфигурировать базу Oracle

Database на доступ к NAS-устройству, работающему по протоколу NFSv3, непосредственно из

Oracle Direct NFS client, вместо необходимости использовать клиент NFS из ядра OS. Direct NFS

client обращается к файлам сервера NFS, устраняя дополнительные накладные расходы,

связанные с использованием клиента NFS из ядра OS. Эти файлы также по-прежнему остаются

доступны клиентам NFS ядра OS, что позволяет администрировать систему традиционным

образом. Oracle Real Application Cluster (RAC) также поддерживает Direct NFS client не требуя

специальной конфигурации. Direct NFS client автоматически обнаруживает, когда база Oracle

является частью RAC, и соответствующим образом оптимизирует монтирование NFS для

использования его в RAC.

2.3 ASM Oracle Automatic Storage Management (ASM) стал очень популярным средством Oracle Database и в

настоящее время хорошо протестирован и интегрирован с системами хранения NetApp. В версии

Oracle Database 11g сделано множество улучшений и расширений в ASM, и ниже приводятся

некоторые новые возможности ASM.

ASM fast mirror resync. После восстановления сбойного диска выполняется команда, ALTER

DISKGROUP ... DISK ONLINE. Команда переводит диск в онлайн на запись, для того, чтобы

новые записи не пропали. Затем инициируется копирование всех экстентов, маркированных

как stale с избыточной копии. Время восстановления пропорционально числу экстентов,

которые были записаны или изменены за время отказа диска.

Следует отметить, что NetApp RAID-DP® и/или SyncMirror® выполняют данную

функциональность по восстановлению данных и замене вышедшего из строя диска прозрачно

для Oracle, поэтому данная возможность ASM при использовании систем хранения NetApp не

требуется.

• Улучшения управляемости ASM. Был добавлен ряд дополнительных возможностей для

дальнейшего упрощения и снижения уровня сложности при администрировании систем

Oracle Database. В их число входят совместимость дисковых групп между программными

версиями, атрибуты дисковых групп, резервное копирование метаданных дисковых групп,

улучшенная обработка потерянного диска в момент монтирования, новый метод

монтирования, улучшения ребалансировки производительности и расширения для утилиты

ASMCMD.

• ASMCA. ASMCA это новый GUI и CLI для администрирования дисковых групп ASM. Это

расширенная версия ASMCMD. Ранее для создания инстансов ASM использовались OUI или

DBCA; теперь все это можно делать с помощью ASMCA. Кроме этого ASMCA интегрирован с

automatic storage management dynamic volume manager (ADVM) и automatic storage

management cluster file system (ACFS).

• ASM rolling upgrade. Rolling upgrade это возможность для кластерного ПО работать, если на

одном или более узле кластера работает ПО иной версии. Различные версии ПО могут по-

прежнему взаимодействовать между собой, и обеспечивать целостный образ системы.

Возможности rolling upgrade доступны, начиная с обновления Oracle Database 11g Release 1.

Эта возможность позволяет независимым узлам кластера ASM мигрировать или патчиться без

влияния на доступность базы данных в целом. Возможность rolling upgrade обеспечивает

более высокий аптайм и удобную миграцию для новых релизов.

Расширения масштабируемости и производительности ASM. Они позволяют Oracle

эффективнее поддерживать очень большие базы данных, прозрачно увеличивая размеры

экстентов. Это увеличивает максимальный размер файла, поддерживаемый Oracle, до 128TB.

Пользователи также могут увеличивать размер allocation unit для дисковой группы с

множителем 2 вплоть до 64MB. Эти улучшения уменьшают время запуска базы и требования

по памяти, а также позволяют поддерживать файлы ASM большего размера, делая

возможным реализацию баз данных Oracle с использованием ASM на объемах в несколько

сотен терабайт и даже до петабайт. Больший размер allocation units обеспечивает лучшую

производительность последовательного чтения. Однако отметьте, что каждый диск в ASM

может масштабироваться лишь до 2TB. Для достижения более высоких лимитов,

сконфигурируйте несколько дисков в дисковую группу. Для более подробного рассмотрения

темы масштабируемости ASM и ее ограничений, смотрите:

https://support.oracle.com/CSP/main/article?cmd=show&type=NOT&doctype=HOWTO&id=37092

1.1.

• Конвертация single-instance ASM в clustered ASM. Эта возможность обеспечивает поддержку

в Enterprise Manager конвертирования некластеризованной (nonclustered) базы ASM в

кластеризованную (clustered) базу ASM, косвенным конфигурированием ASM на всех узлах.

Она также расширяет утилиту конверсии одиночного инстанса базы Oracle в Oracle RAC,

поддержкой standby-баз данных. Упрощение преобразования делает проще миграцию для

пользователя его баз в кластерную, масштабируемую и высокодоступную систему Oracle RAC.

• Роль SYSASM для администрирования ASM. В Oracle Database 11g появилась новая

дополнительная роль системных привилегий, SYSASM, и дополнительная группа привилегий

операционной системы, OSASM, для обеспечения лучшей безопасности при выполнении

задач администрирования ASM. Oracle рекомендует использовать роль SYSASM вместо

SYSDBA при администрировании Automatic Storage Management, для того, чтобы отделить

администрирование Automatic Storage Management от администрирования базы данных.

Внимание: Вы можете создать группу операционной системы (operating system group) для

администратора Automatic Storage Management, дополнительно к группам dba и

oper.

2.4 Real Application Testing Real Application Testing это новая функциональность Oracle Database 11g, которая очень хорошо

ложится на возможности технологий NetApp FlexVol® и FlexClone®. Real Application Testing

использует возможности «повторного воспроизведения» (replay) запросов к базе данных,

захваченных с реальной работающей базы данных, и которые адресуются к тестовой базе для

целей тестирования. Real Application Testing также поставляется с инструментами анализа

производительности.

Администраторы базы данных постоянно сталкиваются лицом к лицу с необходимостью

проводить различные тестирования базы данных. Это может быть тестирование обновлений,

новых приложений, нового кода SQL-запросов, или иные модификации системы, все это следует

предварительно протестировать, перед тем, как выпускать в рабочее использование.

Обычный сценарий тестирования базы данных может потребовать:

• Обновление баз данных, наложение патчей, изменений параметров и схемы, и так далее

• Конфигурационные изменения, такие как преобразование из отдельного инстанса в RAC,

использование ASM, и так далее

• Изменения в хранилище данных, в сети и интерконнектах

• Изменения операционной системы, изменения аппаратной части, установка патчей,

обновлений и параметров в OS

В прошлом, провести адекватное тестирование было трудно, и часто оно приводило лишь к

незначительному успеху. DBA и системные администраторы пытались найти генераторы нагрузки

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

базу данных. Ранее достижение максимального приближения к рабочей нагрузке и рабочей

системе было труднодостижимо, дорогостояще и занимало много времени при воспроизведении.

https://support.oracle.com/CSP/main/article?cmd=show&type=NOT&doctype=HOWTO&id=370921.1


Real Application Testing имеет возможность захватывать реальную нагрузку рабочей базы данных,

и воспроизводить ее, когда и как это нужно для задач тестирования.

Идеальная ситуация заключается в создании снэпшота NetApp Snapshot™ с содержимого базы и

запуска захвата всего рабочего трафика к базе. Когда захват завершен, создается клон базы из

взятого снэпшота, и на нем воспроизводится записанный трафик запросов к базе на созданном

клоне. Это будет точной копией рабочей нагрузки, обращающейся к клону базы, идентичной той,

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

запросов воспроизведен на нем снова и снова, без затрат времени на переустановку.

Средства Real Application Testing предоставляют следующие возможности:

• Захват рабочей нагрузки (workload)

• Обработка рабочей нагрузки

• Воспроизведение записанной рабочей нагрузки

• Анализ и создание отчетов по результатам

• Анализ производительности SQL

Для более подробного рассмотрения темы: TR 3803: Upgrading to Oracle Database 11g with NetApp

SnapMirror, FlexClone, and Oracle Real Application Testing

2.5 Advanced compression За несколько прошедших лет базы данных пережили взрывной рост своих объемов. Oracle

Database 11g встретила эти процессы рядом новых возможностей, и в их числе – опция

компрессии данных под названием advanced compression. Advanced compression работает со

всеми типами данных, такими как, например, регулярные структурированные данные (числа,

символы), неструктурированные данные (текстовые документы,электронные таблицы, XML, и

другие файлы), и файлы резервных копий.

Advanced compression в Oracle Database 11g не только снижает объемы занятого места для всех

типов данных; она также улучшает производительность приложений и увеличивает

эффективность использования памяти и сети. Кроме этого стоит отметить, что она может быть

использована с любым типом приложений, без каких-либо изменений на их стороне.

Опция advanced compression в Oracle Database 11g имеет следующие возможности:

• OLTP Table Compression. Позволяет структурированным и реляционным данным быть

сжатыми во время всех типов операций манипуляции данными, включая INSERT, UPDATE, или

DELETE. Эта новая возможность использует сложный и интеллектуальный алгоритм, который

минимизирует оверхед компрессии во время операций записи, тем самым делая ее

пригодной для любых нагрузок. Кроме этого значительно улучшается производительность

запросов, путем снижения объемов дискового ввода-вывода и улучшения эффективности

использования памяти. Более ранние версии Oracle Database поддерживали компрессию

лишь для операций загрузки данных, обычно используемых для приложений data

warehousing. Oracle Database 11g с функцией OLTP table compression улучшает

производительность баз данных за счет более эффективного использования памяти для

кэширования данных и снижения трафика ввода-вывода при сканировании таблиц (table

scans). С использованием OLTP table compression, вы можете достичь двух-трехкратной

компрессии с минимальной загрузкой процессора.

http://www.netapp.com/us/library/technical-reports/tr-3803.html


• Быстрая дедупликация данных. Интеллектуальная технология, устраняющая дубликаты

хранимых файлов в Oracle Database 11g. Кроме снижения объемов занятого пространства, эта

опция также значительно улучшает производительность на запись и при копировании, с

участием дублирующегося контента.

• Быстрая компрессия. Компрессия неструктурированных или файловых данных, хранимых в

базе данных. Доступно два уровня компрессии, поэтому вы можете выбрать между более

высоким уровнем компрессии или более низким уровнем использования ресурсов CPU.

• Компрессия файлов резервных копий. Требования к хранилищу для хранения резервных

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

базы данных. С этой целью advanced compression включает в себя средства сжатия резервных

копий, создаваемых с помощью Recovery Manager (RMAN) или Oracle Data Pump для базы

данных.

• Компрессия сетевого трафика. Advanced compression также предлагает возможности сжатия

данных Oracle Data Guard redo data (standby databases) когда Data Guard воспроизводит логи

redo. Это улучшает эффективность использования сети и ускоряет процессы восстановления в

ходе применения redo logs.

2.6 Active Data Guard Опция Oracle Active Data Guard позволяет физической standby-базе использоваться для

приложений, осуществляющих чтение, одновременно с приемом ей обновлений с первичной

базы. Запросы SQL выполняются на активной standby-базе, принимающей актуальные результаты.

2.7 Snapshot Standby Database Oracle Data Guard имеет новый тип standby-базы, которая называется snapshot standby database.

Standby-база это транзакционно-консистентная копия первичной базы. Snapshot standby database

дополняет physical standby- и logical standby-базы в предыдущих версиях Oracle Data Guard.

База типа snapshot standby database это доступная для обновлений standby-база данных, которая

создается преобразованием physical standby database в snapshot standby database. База типа

snapshot standby продолжает принимать, но не применяет к содержимому базы, обновления,

генерируемые primary-базой. Но эти обновления автоматически применятся к standby-базе, когда

snapshot standby будет преобразована назад, в physical standby-базу. Первичные данные остаются

защищены все время. Эта функциональность предлагает комбинированные преимущества как для

катастрофоустойчивых решений, так и для задач создания отчетов или тестирования.

Данные redo, принимаемые базой snapshot standby database не применяются к ней до тех пор,

пока snapshot standby database не будет сконвертирована назад в physical standby database, после

первого отбрасывания любых локальных изменений, сделанных в snapshot standby database.

База snapshot standby database наилучшим образом подходит для сценариев, которые требуют

использования временной, обновляемой снэпшот-копии с physical standby database. Обратите

внимание на то, что redo data, принимаемые базой snapshot standby database не применяются к

ней до тех пор, пока она не будет преобразована в physical standby, время, необходимое для

выполнения смены роли, прямо пропорционально объемам redo data, требующим применения

на данные базы.

2.8 Новая инфраструктура grid Oracle Database 11g R2 предлагает новое унифицированное хранилище для инсталляций Oracle.

Оно позволяет размещать Oracle Cluster Registry (OCR) и voting disks на дисковой группе ASM.

«Инфраструктура grid» это набор инфраструктурных компонентов, предлагаемых для Oracle

Database и другого ПО. Они обеспечивают интегральную функциональность Clusterware для

кластерных соединений, передачу сообщений, локирование и управление кластером. ASM теперь

является частью grid infrastructure и тоже содержит ПО Clusterware.

Инфраструктура grid теперь доступна также и для единственного инстанса. Наряду с

перечисленными выше компонентами также имеется так называемый Oracle Restart, который

обеспечивает высокую доступность для некластеризованных баз данных. Он может мониторить и

перезапускать в случае отказа следующие компоненты: DB Instance, Oracle Net Listener, Database

Services, ASM instance, и так далее.

Однако если какие-то сервисы были корректно остановлены администратором, процесс Restart

не будет запускать их самостоятельно. Restart обеспечивает запуск компонентов базы данных в

правильном порядке, в соответствии с взаимозависимостями этих компонентов.

SCAN: Single Client Access Name

Все сервера в кластере теперь действуют под единым именем хоста. SCAN позволяет кластеру

быть полностью прозрачным для пользователей.

2.9 Создание сегмента по требованию (On-demand segment creation) В новом релизе 11g, Oracle может отложить создание сегмента для несекционированной

традиционной таблицы (nonpartitioned heap-organized table) существующей в локально-

управляемом табличном пространстве (locally managed tablespace). В этом сценарии, создание

сегмента таблицы откладывается до момента, когда в нее будет занесена первая строка.

Преимущества этой новой функциональности:

• Экономятся значительные объемы дискового пространства приложений, которые создают

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

• Время установки приложений уменьшается.

Внимание: Существует небольшое влияние на производительность, когда вставляется первая

строка в таблицу, так как в этот момент должен быть создан новый сегмент.

2.10 Переносимая база данных Используя Oracle 11g, пользователь может мигрировать базу данных с одной платформы на

другую, с применением «переносимой» базы данных (transportable database). В этом релизе

Oracle поддерживает кроссплатформенную physical standby между Linux и Windows. Это

расширение поддержки в Oracle так называемой transportable tablespace. Для полного описания

смотрите http://support.oracle.com.

3 Конфигурация системы хранения NetApp

3.1 Сетевые настройки Когда вы конфигурируете сетевые интерфейсы на новой системе, наилучшим решением будет

запустить команду setup, которая автоматически настроит все интерфейсы и обновит файлы

/etc/rc и /etc/hosts. Команда setup потребует перезагрузки для применения сделанных

настроек.

http://support.oracle.com/

Однако, если система в работе и не может быть перезапущена, сетевые интерфейсы можно

сконфигурировать командой ifconfig. Если сетевые интерфейсы в состоянии online и требуется

их переконфигурирование, они должны быть отключены (down). Для минимизации простоя

интерфейса, последовательность команд может быть введена в одну строку, как одна команда, с

отделением ее составляющих подкоманд между собой символом «точка с запятой» (;).

Пример:

netapp>ifconfig e0 down;ifconfig e0 'hostname'-e0 mediatype auto netmask

255.255.255.0 partner e0

Наилучшее решение

При конфигурировании или изменении конфигураций сетевых портов NIC или VIF в кластере,

необходимо включить имя соответствующего партнерского интерфейса, NIC или VIF, в

конфигурацию кластерных партнеров, что позволит правильно отрабатывать переключение при

кластерном takeover. Если потребуется помощь в настройке – свяжитесь с нашим представителем

в NetApp Support. Физический сетевой интерфейс (NIC) или виртуальный интерфейс (VIF)

используемый базой данных, не должен реконфигурироваться, пока база, его использующая,

активна, это может привести к остановке базы данных.

Ethernet: Gigabit Ethernet, Autonegotiation, и Full Duplex

Любая база данных, использующая систему хранения NetApp, должна использовать Gigabit

Ethernet как на стороне системы хранения NetApp, так и на стороне сервера базы данных.

Сетевые карты типа NetApp Gigabit II, III, и IV разработаны для автораспознавания (autonegotiate)

сетевой конфигурации и могут интеллектуально самоконфигурироваться, если процесс

autonegotiation окажется неудачен. По этой причине NetApp рекомендует оставлять линки Gigabit

Ethernet на клиенте, коммутаторах и системе хранения в состоянии autonegotiation по умолчанию,

за исключением ситуаций, когда линк не устанавливается, полученная производительности

низкая, или имеются иные условия, требующие специального решения.

Параметр flow control должен быть установлен в «full» на системе хранения NetApp в его файле

/etc/rc, включением следующей строки (считаем, что интерфейс Ethernet имеет имя e5):

ifconfig e5 flowcontrol full

Если вывод команды ifstat –a не показывает наличия full flow control, тогда следует

сконфигурировать порт коммутатора на его поддержку. (Команда ifconfig на системе хранения

NetApp всегда показывает запрошенную настройку; ifstat показывает состояние flow control

фактически установленное с коммутатором.)

3.2 Установки для тома и aggregate, а также опции базы данных В настоящий момент нет эмпирических данных для того, чтобы однозначно определить то,

насколько разбивка базы данных по нескольким физическим носителям улучшает или ухудшает

производительность. Тем не менее, решение какую именно структуру томов следует использовать

для хранения базы данных, следует принимать исходя из требований к резервному копированию,

восстановлению и репликации базы.

Один инстанс базы данных не должен размещаться на нескольких некластеризованных системах

хранения NetApp, так как разделенная на части база данных на нескольких хранилищах NetApp,

усложняет администрирование и вызывает повышенный риск остановки работы базы данных в

результате сбоя на хранилище или необходимости его обслуживания. Если одна база данных

должна быть распределена на несколько систем хранения NetApp для повышения

производительности, необходимо предусмотреть и принять необходимые меры на случай

возможной остановки работы одного из хранилищ, или затруднения его работы на период

резервного копирования. Рекомендуется сегментировать базу данных таким образом, чтобы

фрагмент ее, находящийся на определенной системе хранения, мог бы быть безболезненно

переведен в оффлайн (например, для задач обслуживания этой системы хранения).

Aggregates и тома типа FlexVol

NetApp поддерживает объединение большого числа дисков в aggregate и создание «виртуальных

томов» (томов типа FlexVol) поверх этого набора дисков. Такое использование имеет ряд

преимуществ для системы Oracle Database; см. документ [1] в справочных материалах в конце

данной работы. Для данного релиза NetApp также поддерживает 64-bit aggregates.

При использовании Oracle Databases мы рекомендуем объединять все диски в единый пул в

одном большом aggregate и использовать тома FlexVol для размещения файлов базы данных и

логов, как описано ниже. Это дает преимущество в части более простого администрирования, в

особенности для растущей или уменьшающейся базы, без влияния на производительность. Для

подробного описания структуры смотрите документ [2] в Справочных материалах, в конце

данного документа.

Размеры тома

Начиная с Data ONTAP® 8.0, тома типа FlexVol могут быть двух типов: 32-bit или 64-bit, что зависит

от типа содержащего их aggregate. Том типа 64-bit может иметь больший максимальный размер,

чем том типа 32-bit.

Том типа 32-bit имеет максимальный размер, равный 16TB. Максимальный размер тома типа 64-

bit определяется размером содержащего его aggregate: он может достигать 100TB, что зависит от

модели системы хранения.

Внимание: Для обоих типов томов, максимальный размер LUN-ов и файлов на них равен 16TB.

Например, несмотря на то, что дедуплицированный том на системе хранения NetApp FAS3270

может увеличиться в размере до 16TB, некоторые файловые системы не распознают тома

размером более 2TB. По этой причине NetApp рекомендует проверить системные ограничения

вашей операционной системы перед развертыванием решения. При разработке решения базы

данных с использованием Oracle Automated Storage Management (ASM), примите во внимание

максимальный размер поддерживаемых Oracle ASM дисков.

Использование правильно выбранного размера тома:

• Снижает время резервного копирования тома

• Позволяет индивидуально сгруппировать снэпшоты и qtree

• Улучшает безопасность и управляемость за счет разделения данных

• Снижает риски административных ошибок, отказов оборудования, и так далее

Для того, чтобы посмотреть подробную информацию о максимально допустимом размере тома

для разных систем хранения, смотрите Data ONTAP Storage Management Guide на сайте NetApp

Support (ранее NOW®).

Для подробной информации о развертывании Oracle с использованием ASM, смотрите «ASM:

Scalability and Limits» ID 370921.1 на Oracle Metalink.

Рекомендуемые тома для файлов баз данных и логов Oracle

Основываясь на результатах нашего тестирования, мы нашли, что описываемая далее структура

адекватна большинству сценариев использования. Общие рекомендации заключаются в совете

использовать единый aggregate, содержащий все тома, хранящие компоненты базы данных.

Таблица 1) Структура томов и aggregate.

Бинарные файлы Выделенный FlexVol

Конфигурационные файлы Выделенный FlexVol Мультиплексируйте с логами транзакций

Лог транзакций Выделенный FlexVol Мультиплексируйте с конфиг-файлами

Архивные логи Выделенный FlexVol Используйте SnapMirror

Файлы данных Выделенный FlexVol

Временные файлы данных Выделенный FlexVol Не делайте снэпшоты на этом томе

Файлы кластерной службы Выделенный FlexVol Можно использовать ASM в 11gR2

Oracle Optimal Flexible Architecture (OFA) на системе хранения NetApp

Модель Oracle OFA помогает достичь следующего:

• Простое резервное копирование и восстановление данных и логов Oracle, размещением их

на отдельные логические тома

• Быстрое восстановление в случае аварии, с минимальным простоем

• Использовать логическое разделение компонентов Oracle для упрощения обслуживания и

администрирования

• Хорошо работать в случае схемы с множественными Oracle home (MOH)

Для подробной информации об Oracle OFA for RAC или non-RAC, смотрите:

• OFA для non-RAC:

http://download.oracle.com/docs/cd/E11882_01/install.112/e16763/appendix_ofa.htm

• Для RAC, OFA для ORACLE_HOME изменяется:

http://download.oracle.com/docs/cd/E11882_01/install.112/e17214/whatsnew.htm#sthref

http://now.netapp.com/


https://support.oracle.com/

http://download.oracle.com/docs/cd/E11882_01/install.112/e16763/appendix_ofa.htm

http://download.oracle.com/docs/cd/E11882_01/install.112/e17214/whatsnew.htm#sthref

Таблица 2) Структуры Oracle OFA.

Тип Описание Точка монтирования по OFA Размещение

ORACLE_BASE /u01/app/oracle/ Локально или NetApp

ORACLE_HOME Библиотеки и двоичные файлы Oracle

/u01/app/oracle/11.2.0/ or /u01/app/oracle/11.2.0/db_unique_name

Локально или NetApp

Data files Файлы данных Oracle Database

/u03/oradata NetApp

Log files Файлы Oracle redo и archive logs

/u04/oradata NetApp

CRS_HOME (для 10.2.x.x RAC

Oracle CRS HOME

/u02/crs/product/10.2.0/app/ Локально или NetApp

CRS_HOME (для 11.2.x.x RAC)

Oracle CRS HOME

/u01/app/crs/ (не должен быть поддректорией ORACLE_BASE)

Локально или NetApp

Расположение Oracle Home

Структура OFA достаточно гибка, и позволяет размещать ORACLE_HOME на локальной файловой

системе или на смонтированном по NFS томе. Для Oracle Database 11g, ORACLE_HOME может быть

совместно используемым (shared) для конкретной конфигурации RAC, когда один набор бинарных

файлов Oracle и его библиотек совместно используется несколькими инстансами одной базы

данных. Несколько подробнее тема shared ORACLE_HOME рассматривается ниже.

Что такое Shared ORACLE_HOME?

• Shared ORACLE_HOME это директория ORACLE_HOME, используемая двумя или более хостами.

Эта директория используется для установки в нее ПО, бинарных файлов Oracle, библиотек,

сетевых файлов (listener, tnsnames, и так далее), oraInventory, dbs, и так далее.

• Shared ORACLE_HOME это термин, используемый для описания директории с установленным

ПО Oracle, которая монтируется с сервера NFS, и доступ к которой осуществляется с двух или

более хостов по одному и тому же пути.

• Директория ORACLE_HOME, согласно OFA, выглядит примерно так:

/u01/app/oracle/11.1.0/db_1.

Что поддерживает Oracle в Oracle Database 11g?

• Oracle Database 11g поддерживает отдельный инстанс, использующий смонтированную по

NFS директорию ORACLE_HOME на один хост.

• Oracle Database 11g поддерживает RAC, использующий смонтированную по NFS директорию

ORACLE_HOME для одного и более хостов.

Какие преимущества использования Shared ORACLE_HOME в Oracle Database 11g?

• Не нужно держать избыточные копии на хостах. Такой вариант крайне эффективен для

системы, используемой для тестирования, в которой необходим быстрый доступ к двоичным

файлам Oracle со сходных хост-систем.

• Экономится пространство на дисках.

• Применение патчей на множестве систем может быть выполнено быстрее. Например, если

вы тестируете приложение на 10 отдельных хостах, и хотите чтобы они использовали в

точности одну версию Oracle DB, в случае Shared ORACLE_HOME это просто.

• Проще добавлять узлы RAC.

Какие недостатки использования Shared ORACLE_HOME в Oracle Database 11g?

• Когда патчится содержимое директории ORACLE_HOME, изменения повлияют на все базы

данных, использующих тот же home.

• Использование shared ORACLE_HOME и сбой в нем, может вызвать перебой или повлиять на

работу большого числа серверов.

Что поддерживает NetApp в случае Shared ORACLE_HOME?

• Поддерживается shared ORACLE_HOME для RAC.

• Поддерживается shared ORACLE_HOME для одного отдельного инстанса Oracle, когда он

смонтирован на одной отдельной хост-системе.

• НЕ ПОДДЕРЖИВАЕТСЯ использование shared ORACLE_HOME в продакшн-системе,

требующей высокой доступности отдельного инстанса Oracle. Другими словами,

множественные базы данных на должны совместно использовать один смонтированный

по NFS ORACLE_HOME, если база работает в продакшне.

Наилучшие практики и рекомендации для Control- и Log-файлов

Файлы Online Redo Log

Мультиплексируйте ваши лог-файлы. Сделайте это, следуя таким рекомендациям:

Создайте минимум две группы online redo log, по два члена в каждой. Поместите первого члена

каждой online redo log на один том, а следующего – на другой. Процесс инстанса log writer (LGWR)

производит сброс (flush) буфера redo log, содержащего как подтвержденные (committed), так и

неподтвержденные (uncommitted) транзакции для всех членов текущей группы online redo log

group, и когда группа наполняется, производит переключение логов на следующую группу, затем

LGWR пишет на всех членов, входящих в следующую группу, пока она не заполнится, и так далее.

Чекпойнты (сheckpoints) не вызывают переключение логов; фактически, пока заполняется группа

логов, может быть создано множество чекпойнтов.

Файлы Archived Log

Установите ваш инициализационный параметр LOG_ARCHIVE_DEST на директорию на томе логов,

например /u3/log/ArchiveLog (на томе системы хранения NetApp /vol/oralog3).

Файлы Control

Мультиплексируйте ваши control-файлы:

1. Установите инициализационный параметр CONTROL_FILES указывающим на по меньшей мере

два различных тома на системе хранения NetApp, например:

Dest 1: /u4/Control_File1 (на локальной файловой системе или на томе системы хранения

NetApp /vol/oralog)

Dest 2: /u5/log/Control_File2 (на томе системы хранения NetApp /vol/oradata)

3.3 Размер RAID-групп Конфигурирование оптимального размера RAID-группы требует принятия в расчет различных

аспектов, таких как скорости восстановления при выходе из строя диска, устойчивости к потере

данных, и максимизации доступного пространства. В большинстве случаев размер RAID-группы

выбранный в системе по умолчанию это наилучший выбор. Однако вы можете изменить размер

группы вплоть до максимально поддерживаемого.

Когда время восстановления (время, которое требуется для полного перестроения RAID после

выхода из строя диска в нем) это важный фактор, следует использовать RAID-группу меньшего

размера. Ниже приведены рекомендации по наилучшему выбору размера RAID-группы при

использовании NetApp RAID-DP.

Максимальный размер и размер по умолчанию для RAID-группы может различаться в

зависимости от модели системы хранения, уровня RAID для группы и типа используемых дисков.

NetApp рекомендует следующие значения по умолчанию для размеров группы RAID типа RAID-DP:

• Значение размера RAID-группы по умолчанию для Data ONTAP 8.0.1 равно 14 дисков для ATA

или SATA и 16 для FC или SAS.

• Максимально поддерживаемый размер RAID-группы равен 28 дисков для FC и SAS и 20

дисков для ATA или SATA.

Для подробностей смотрите System configuration guide на сайте NetApp Support.

RAID-группа большего размера увеличивает время перестроения RAID по причинам:

• Увеличивается необходимое число чтений

• Увеличивается объем использования ресурсов RAID

• Увеличивается период, в течение которого производительность ввода-вывода снижена

(Реконструкция большой RAID-группы занимает большее время; поэтому производительность

по вводу-выводу снижается на более длительный срок)

Эти факторы влияют на производительность под рабочей нагрузкой и/или увеличение времени

восстановления после сбоя.

3.4 Snapshot и SnapRestore NetApp настоятельно рекомендует использовать Snapshot и SnapManager® for Oracle Database в

качестве средств резервного копирования и восстановления. Снэпшоты (Snapshot) обеспечивают

создание мгновенной копии всей базы данных за считанные секунды, без какого-либо влияния на

производительность, и независимо от ее размера, в то время, как SnapRestore может мгновенно

восстановить всю базу данных из сделанного снэпшота, на любой момент времени в прошлом.

Внимание: Эта глава подразумевает, что вы не используете снэпшоты или SnapRestore вместе со

SnapMirror. Если вы используете SnapMirror, смотрите главу Консолидация

резервных копий с помощью SnapMirror.

Эффективное использование снэпшотов для возможного восстановления Oracle Databases требует

координации со средствами Oracle hot backup. По этой причине NetApp рекомендует отключить

автоматическое создание снэпшотов для томов, которые использованы для хранения файлов

Oracle Database.

Для отключения функциональности создания автоматических снэпшотов на томе, выполните

команду:

vol options <volname> nosnap on

Если вы хотите сделать директорию .snapshot видимой, то выполните команду:

vol options <volname> nosnapdir on

При отключении автоматического создания снэпшотов на томе, снэпшоты, создаваемые как часть

процесса резервного копирования Oracle, будут создаваться для базы данных, находящейся в

консистентном состоянии.

Для более подробного рассмотрения темы использования снэпшотов и SnapRestore для создания

резервной копии и восстановления из нее для Oracle Database, смотрите документ [3] в

Справочных материалах, в конце данного документа.

3.5 Snap Reserve Snap reserve это пространство на томе, зарезервированное на использование в снэпшотах, его

размер задается в процентах от емкости тома.

Внимание: Снэпшоты могут занимать на томе больше места, чем задано в качестве snap reserve,

но пользователь не может занять место, находящееся в зарезервированном

пространстве.

Для того, чтобы увидеть установленный размер резерва на томе, выполните команду:

snap reserve

Для установки заданного размера snap reserve (значение по умолчанию 20%), выполните команду:

snap reserve <volume> <percentage>

Не используйте значок процента (%) когда задаете величину резерва в команде.

Обычно величина snap reserve задается слегка превышающей пиковую величину занятого

снэпшотами места на томе. Пиковую величину занятого снэпшотами место можно оценить

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

Величина snap reserve может быть изменена в любое время. Не устанавливайте величину snap

reserve выше, чем количество свободного места на томе; в противном случае подключенные к

тому клиенты могут увидеть отсутствие свободного места и аварийно прекратить работу.

Best Practice

NetApp рекомендует регулярно наблюдать и контролировать то, сколько места занято в snap

reserve. Не позволяйте использованному снэпшотами месту выходить за пределы snap reserve.

Если занятое место в snap reserve превысило заданный лимит, увеличьте объем резерва в

процентах от емкости тома, или удалите ненужные снэпшоты.

3.6 Системные опции

Опция minra

Когда на системе хранения включена опция minra, это минимизирует число блоков, читаемых с

упреждением (readahead) при каждой операции чтения. По умолчанию, minra выключена, и

система хранения активно использует упреждающее чтение для каждого тома. Эффект от

использования упреждающего чтения зависит от характеристик ввода-вывода приложения. Если к

данным обращаются последовательно, например, когда база данных производит сканирование

таблиц и индексов (full table and index scans), упреждающее чтение повысит производительность

ввода-вывода. Если порядок доступа к данным полностью произволен (random), то упреждающее

чтение должно быть выключено, так как может ухудшить производительность за счет того, что

считываемые с упреждением дисковые блоки, которые не потребовались приложению, занимают

пространство кэша и непроизводительно тратят системные ресурсы.

Команда для того, чтобы активизировать режим minra на томе и отключить упреждающее чтение:

vol options <volname> minra on

В общем случае упреждающее чтение полезно для баз данных, и опцию minra стоит оставить

выключенной. Однако NetApp рекомендует провести эксперимент с установкой minra, чтобы

оценить влияние ее на систему и производительность, так как не всегда можно точно определить

то, насколько приложение считывает данные последовательно или произвольно. Эта опция

прозрачна с точки зрения клиентского доступа, и может быть включена или выключена без

прерывания работы и доступа к тому. Убедитесь, что отвели две или три минуты на то, чтобы кэш

системы хранения установился с данными нового значения minra, перед тем, как оценивать

изменения в производительности.

Внимание: Исторически NetApp рекомендовал отключать активное упреждающее чтение для

баз данных OLTP, устанавливая параметр minra в значение «on». Начиная с Data

ONTAP 6.5.1, однако, была проделана большая работа и значительно изменен

алгоритм упреждающего чтения, делая его более интеллектуальным и

эффективным. По этой причине сейчас NetApp больше не рекомендует отключать

упреждающее чтение активацией minra для баз данных.

Включение опции minra может снизить общую производительность баз данных. Сейчас NetApp

рекомендует оставлять настройку minra в состоянии по умолчанию, «off», если нет ясного

указания на иное для вашей конфигурации от NetApp Global Support.

Обновление времени последнего обращения к файлу (File access time update)

Еще одна опция, использование которой может улучшить время доступа это опция отключения

обновления времени последнего обращения к файлу. Если приложению не требуется получать

время последнего обращения к файлу, то этой опцией вы можете отключить обновления этого

атрибута для файлов. Используйте эту опцию только в случае, если приложение генерирует

большой трафик ввода-вывода по чтению. Команда для выключения обновления времени

последнего обращения к файлам:

vol options <volname> no_atime_update on

Настройки NFS V3

NFS v3 в настоящий момент поддерживается всеми версиями Oracle, поддерживающими NFS.

Сюда входят как системы Oracle single instance так и RAC. Подробную информацию о

конфигурировании NFS v3 можно найти в руководствах NetApp по инсталляции Oracle на

конкретную платформу. NetApp поддерживает использование TCP как механизм транспорта

данных для текущего клиента NFS v3 на хосте. UDP не поддерживается в качестве транспорта для

данных Oracle.

Подробнее об опциях монтирования базы данных:

http://kb.netapp.com/support/index?page=content&id=3010189.

http://kb.netapp.com/support/index?page=content&id=3010189

Настройки NFS V4

Network File System (NFS) version 4 это протокол распределенной файловой системы,

основывающийся на протоколе NFS версии 2 [RFC1094] и 3 [RFC1813]. В отличие от

предшествующих версий, протокол NFS версии 4 поддерживает традиционный доступ к файлам, с

интегрированной поддержкой локирования файлов и протокола монтирования. Дополнительно

поддерживаются сильные средства обеспечения безопасности (и их согласование), составные

операции, кэширование на стороне клиента, и поддержка национальных кодировок

(internationalization, i18n). Также внимание уделено применению NFS версии 4 в среде Интернет.

Цели, поставленные при разработке NFS v4 были следующие:

• Улучшенный доступ и хорошая производительность при работе в Интернет

• Усиленные средства безопасности, встроенные в протокол

• Хорошая кросс-платформенная интероперабельность

• Возможность расширения протокола

В общем случае, модель использования файловой системы NFS v4 та же, что и для предыдущих

версий.

Серверная файловая система иерархическая; находящиеся на файловой системе файлы

трактуются как непрозрачный поток байтов. Имена файлов и директорий кодируются в UTF-8 для

обеспечения базовой поддержки национальных алфавитов (i18n). NetApp впервые обеспечил

поддержку сервера NFSv4 в Data ONTAP 6.4. Клиенты версии NFSv4 изменялись с момента выхода

Data ONTAP 6.4, что вызывало ряд проблем совместимости. В Data ONTAP 7.3 были решены

многие из накопившихся проблем. Сегодня клиенты разных OS поддерживают возможности

NFSv4 в разной степени.

Для подробностей о поддержке NFSv4 в Oracle, смотрите Interoperability Matrix, расположенный

на сайте NetApp Support.

Управление свободным пространством и ENOSPC

Использующим Oracle важно понимать эффекты управления свободным местом в NetApp, и то, за

что они отвечают при управлении этим свободным местом. В этой главе мы рассмотрим

некоторые варианты эффективного управления свободным пространством, а также покажем, как

NetApp обрабатывает ситуацию, когда свободное место закончилось, и операционная система

вернула ошибку ENOSPC.

ENOSPC это ошибка OS UNIX®, которая иногда сопровождается сообщением «Not enough space is

available to service your request» - «Нет достаточно места для выполнения вашего запроса». Эта

ошибка появляется при нехватке доступных блоков на файловой системе. Например, при

использовании OS Solaris, это errno 28 как она определена в заголовочном файле:

/usr/include/sys/errno.h:

28 ENOSPC No space left on device

Проблема была связана в прошлом с блочными устройствами, которые хотели резервировать

пространство в объеме 2X+delta. Ошибка ENOSPC может также происходить при использовании

хранилища NFS, и становится более частой при использовании FlexVol и FlexClone, когда не

проделано правильное планирование емкости системы хранения. Хотя ошибка ENOSPC вызывает

некатастрофическую остановку инстанса Oracle, нежелательных прерываний работы можно легко

избежать путем правильного планирования.

Ошибка может быть вызвана одним из следующих состояний:

• Приложение пытается выйти за пределы устройства (выполняется переход за EOM/EOP).

• Устройство, содержащее файл, на который ссылается дескриптор, не имеет места для данных.

• Квота диска исчерпана, и он не принимает запросы на запись.

• Нижележащая файловая система заполнена, и нет места для метаданных, чтобы расширить.

Вот некоторые причины, которые могут вызвать ошибку ENOSPC:

• Снэпшоты заняли места значительно больше ожидаемого

• На томе много клонов FlexClone с большим количеством записей/изменений в них

Давайте рассмотрим, что происходит, когда Oracle получает сообщение об ошибке ENOSPC. Oracle

заранее определяет и занимает (preallocate) пространство, необходимое для размещения данных.

Когда Oracle получает сообщение об ошибке ENOSPC на таком заранее определенном

пространстве, он может отреагировать различным способом, в зависимости от того, какой тип

файлов базы данных вызвал такую ошибку. Метод восстановления зависит от типа ошибки.

Помните, что данная проблема не является проблемой Oracle или его повреждения.

Часто задается вопрос: Почему мы получаем ENOSPC, если пространство заранее занимается

(precommitted)? Мы получаем ENOSPC потому что Data ONTAP позволяет снэпшотам расти в

пространство тома. Каждая запись в WAFL® пишется в новый блок. Если старый блок находится в

снэпшоте, Data ONTAP необходимо сохранить старый блок и новый блок с изменениями. Это не

проблема конкретно NetApp. Каждый производитель систем хранения, который реализует

функциональность снэпшотов, сталкивается с ней. Существует две возможности, когда возникает

ситуация с нехваткой места для размещения данных снэпшота:

• Удалить старые снэпшоты

• Сохранить старые снэпшоты и сгенерировать ошибку в активной файловой системе

Data ONTAP выбирает по умолчанию второй вариант. Удаление резервных копий данных может

быть более опасным.

Почему Oracle ведет себя по-разному в разные моменты? Ядро Oracle реагирует на ошибку по-

разному в зависимости от того, какой файл вызывает ошибку. При ошибке записи любого файла,

который критичен для консистентности базы данных (system tablespace, online redo logs), инстанс

прекращает работу. Ошибка в пользовательских файлах данных приводит к выводу файла в

оффлайн и генерации сообщения об ошибке при операции append. Например, операция записи

(append) должна добавить данные в файл. Ошибка записи в archive log поставит базу в режим

ожидания (wait), до тех пор, пока не появится доступное пространство для записи на томе, где

находится archive log. После добавления места для записи на томе, база продолжает работать

обычным образом. Для подробностей смотрите Таблицу 3.

В отношении FlexVol или FlexClone нет ничего специального, относящегося только к этим

технологиям, важно, прежде всего, то, сколько свободного пространства остается в

соответствующем «виртуальном контейнере».

Если ошибка ENOSPC произошла с пользовательскими файлами данных, эти файлы переводятся в

recovery mode и в оффлайн. Процедура восстановления также проста, как и в случае

восстановления инстанса. Все что нужно, это воспроизвести на данных содержимое online redo

logs. Блоки, соответствующие предшествующим чекпойнтам, уже записаны в файл данных.

Отметьте, что замещение старой копии данных, и затем выполнение восстановления занимает

больше времени и может вызвать череду отказов «каскадом» (при получении следующих ENOSPC

уже в процессе восстановления). Добавьте достаточно места на томе, прежде чем начнете

выполнять восстановление, чтобы избежать проблемы «каскадных» отказов.

Как уберечься от получения ошибок ENOSPC

Этот тип ошибок появляется не слишком часто. Однако чтобы вовсе никогда такие ошибки не

прерывали работу вашей базы, NetApp рекомендует предпринять следующие шаги:

• Хорошо спланируйте ваше хранилище данных.

• Определите объемы хранения, необходимые вашей системе и переоценивайте ваш план

ежемесячно.

• Используйте опцию autogrow для тома FlexVol, если вы используете Data ONTAP 7.1 и новее.

• Зарезервируйте 100% от занятой емкости тома в вашей продакшн-системе.

• Убедитесь, что вы имеете достаточно места на томе и/или aggregate перед тем, как

развертывать тестовую среду с FlexClone.

• Выделите достаточно места под snapshot reserve, в особенности, если вы ожидаете большой

объем изменений в данных (большой объем записей) между одним сделанным снэпшотом и

другим.

• Если вы получили ошибку ENOSPC, убедитесь, увеличили ли вы размер тома прежде, чем

начнете восстановительные операции.

Таблица 3) ENOSPC.

Тип файлов данных Тип ошибки Что необходимо сделать, когда ошибка произошла?

Необходимые шаги восстановления

Том NetApp, содержащий файлы пользовательских данных (users01.dbf, и так далее)

ORA-27072 KCF: write/open error No space left on device ORA-00603: Oracle server session terminated by fatal error

1. Восстановить файлы данных 2. Перевести в онлайн файл данных alter database /ab/ab.dbf

Восстановите данные, которые оказались offline. Вы должны сделать это в онлайне, без перезапуска базы данных, при условии, что у вас имеются корректные archived logs. Если archived logs отсутствуют, вы можете восстановить данные из redo logs. Если база повреждена и out of sync, то вам следует провести восстановление из резервной копии.

Том NetApp, содержащий файлы control (control01.ctl, и так далее)

ORA-27072: File I/O error Сигнал об ошибке подает logwriter (lgwr)

Добавить свободного пространства и рестартовать базу данных

База данных запускается нормально

Том NetApp, содержащий файлы данных transaction log (redo01.log, и так далее)

ORA-03113: end-of-file on communication channel Сигнал об ошибке подает logwriter (lgwr)

Добавить свободного пространства и рестартовать базу данных

Восстановление не требуется. - startup nomount - alter database mount - alter database open

Том NetApp, содержащий файлы данных системного уровня (system01.dbf, и так далее)

ORA-27072: File I/O error ORA-01243: system tablespace file suffered media failure. Сигнал об ошибке подает dbwriter (dbw0)

Добавить свободного пространства, определить стартовую точку монтирования, и открыть alter database

База данных сообщает об отказе типа media failure, но работа будет восстановлена при перезапуске

Том NetApp, содержащий temporary database (undotbs01.dbf, и так далее)

KCF: write/open error=27072 No space left on device ENOSPC подает процесс dbwriter (dbw0)

Восстановить вызвавший ошибку файл и продолжить работу 1. Восстановить файлы данных 2. Перевести в онлайн файл данных alter database /ab/ab.dbf

Восстановиться в онлайне, без рестарта базы данных

Том NetApp, содержащий archive logs (arc0805_xxx.dbf, и так далее)

ENOSPC подает процесс archiver

Когда том archive log полон, то записи на него перестают производиться

Увеличить размеры тома и archiver продолжит работу

Direct NFS

Direct NFS (DNFS) это новая возможность, появившаяся в Oracle Database 11g. Одна из наиболее

важных проблем использования kernel NFS из состава операционной системы, это разница и

отличия в администрировании клиента между разными операционными системами и

платформами. Клиент Direct NFS устраняет эту проблему, предлагая стандартизованную

реализацию для всех платформ, поддерживаемых Oracle Database. Это делает NFS подходящим

решением даже для платформ, которые сами не поддерживают NFS, как, например, Windows.

Клиент Oracle Direct NFS реализован как интерфейс Oracle Disk Manager (ODM) и может быть

просто включен или выключен, подсоединением соответствующих библиотек.

Преимущества Direct NFS Client (DNFS)

Клиент Direct NFS в Oracle Database 11g преодолевает нестабильность производительности ввода-

вывода NFS, путем размещения кода клиента NFS непосредственно внутри ядра базы данных, что

делает его независимым от работы ядра операционной системы.

Клиент NFS, встроенный в Oracle 11g обеспечивает следующие преимущества:

• Стабильная и целостная производительность NFS для всех платформ OS.

• Клиент Direct NFS специально оптимизирован для лучшего кэширования и обработки

типичных паттернов ввода-вывода базы данных, для более эффективной работы операций

чтения и записи.

• Клиент Direct NFS позволяет использовать асинхронный прямой ввод-вывод (asynchronous

direct I/O), который работает наиболее эффективным образом в случае баз данных. Это

значительно улучшает производительность записи-чтения базы данных за счет того, что

операции ввода-вывода могут продолжаться в то время, как уже обрабатываются новые

запросы.

Требования целостности базы данных требуют получения немедленного доступа на запись к базе,

когда это запрошено. Кэширование в операционной системе задерживает операции записи из

соображений эффективности операций, потенциально ухудшая ситуацию с целостностью данных

в случае отказа. Клиент Direct NFS позволяет базе данных использовать технику кэширования

вместе с асинхронным непосредственным вводом-выводом, чтобы обеспечить своевременную

запись на диск, снижающую риск для целостности данных.

• Клиент NFS обеспечивает управление балансировкой нагрузки и высокой доступностью,

путем интеграции этих возможностей непосредственно в клиент Direct NFS. Это значительно

упрощает установку сети в высокодоступных средах и снижает зависимость от сетевых

администраторов. Устраняется необходимость задания подсетей, bonded-портов, например с

использование Link Aggregation Control Protocol (LACP), и так далее.

• Клиент Direct NFS позволяет использовать до четырех параллельных сетевых пути/порта,

используемых для ввода-вывода между сервером базы данных и системой хранения. Для

эффективности и производительности они управляются и балансируются непосредственно из

клиента Direct NFS, и не зависят от операционной системы.

• DNFS не использует средства локирования на запись операционной системы, которые могут

быть неподходящими для данного использования, и могут вызывать проблемы и «узкие

места» ввода-вывода.

• Нагрузка на CPU и память сервера баз данных снижается, за счет устранения оверхеда при

копировании данных между кэшем OS и system global area (SGA) базы данных.

Установка Direct NFS

Установка клиента Direct NFS не требует специальных усилий, так как автоматически

устанавливается во время обычной инсталляции Oracle 11g. Он выключен по умолчанию, но

может быть включен следующим образом:

Linux или UNIX:

OSPROMPT> cd $ORACLE_HOME/lib

OSPROMPT> cp libodm11.so libodm11.so_orignal_stub

OSPROMPT> ln –s libnfsodm11.so libodm11.so

Windows:

OSPROMPT> cd %ORACLE_HOME%\bin

OSPROMPT> copy libodm11.dll libodm11.dll_orignal_stub

OSPROMPT> copy /Y libnfsodm11.dll libodm11.dll

Конфигурирование Direct NFS

Для первого шага к использованию клиента Direct NFS необходимо убедиться, что все файлы

Oracle Database размещены на системе хранения NetApp, в томах, смонтированных для доступа с

помощью kernel NFS. Direct NFS не требует каких-либо специальных опций монтирования. Однако

необходимо установить параметры монтирования NFS rsize и wsize на величину 32768 (32K) как

максимальную величину DB_BLOCK_SIZE.

Смотрите рекомендации по опциям монтирования NFS для Oracle Databases:


Клиент Direct NFS использует новый конфигурационный файл, oranfstab, или файл монтирования

(/etc/mtab в Linux) для определения установок и точек монтирования. Клиент Direct NFS требует

только одного конфигурационного файла, формат которого практически идентичен для всех

операционных систем. Краткое описание этих файлов ниже.

Linux или UNIX:

• oranfstab: oranfstab это специальный конфигурационный файл клиента Direct NFS. Этот

файл расположен в $ORACLE_HOME/dbs/oranfstab или /etc/oranfstab. Файл oranfstab

также позволяет использовать клиент Direct NFS в Oracle Database на платформе Windows.

Файл oranfstab содержит детали интерфейса NFS-сервера и локальных интерфейсов, а

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

• kernel mount tab: Файл kernel mount tab расположен в /etc/mtab на большинстве систем

UNIX. Этот файл хранит информацию о смонтированных томах системы. Клиент Direct NFS

использует этот файл, если не может обнаружить необходимые сведения в oranfstab, или

oranfstab недоступен в системе. Клиент Direct NFS ищет назначения монтирования в

следующем порядке и использует первую же найденную запись:

1. $ORACLE_HOME/dbs/ornfstab

2. /etc/oranfstab

3. /etc/mtab

Следующий пример показывает конфигурационный файл oranfstab, в котором монтируются три

тома по NFS, и обращение к которым идет через несколько (4) имен по разным путям.


Пример: oranfstab в Linux

server: MyDataServer1

local: LocalPath1

path: NfsPath1

local: LocalPath2

path: NfsPath2

local: LocalPath3

path: NfsPath3

dontroute

export: /vol/oradata1 mount: /mnt/oradata1




Где:

• server соответствует имени сервера NFS.

• MyDataServer1 имя системы хранения. Даже несмотря на то, что возможно держать все

пути в одной подсети, рекомендуется организовать каждый путь в своей собственной

подсети для обеспечения наилучшей доступности.

• local это сетевой путь со стороны хоста базы данных. Может быть использовано до

четырех локальных путей на хосте базы, определенных с помощью IP-адреса или имени,

как они отображаются с помощью команды ifconfig на хосте.

• path это сетевые интерфейсы на системе хранения. Может быть использовано до четырех

сетевых путей к системе хранения, определенных с помощью IP-адреса, или по имени, как

они отображаются с помощью команды ifconfig на системе хранения.

• dontroute определяет, что исходящие сообщения дне должны маршрутизироваться

операционной системой, а посылаться, используя тот IP, на который они привязаны.

• export это экспортируемый путь с сервера NFS.

• mount атрибут представляет локальную точку монтирования на хосте базы данных.

Внимание: Параметры local и dontroute доступны начиная с patchset 11.1.0.7.

Direct NFS может использовать до 4 сетевых путей, определенных для сервера NFS. Клиент Direct

NFS выполняет балансировку нагрузки по всем заданным путям. Если один из путей перестает

работать, Direct NFS продолжает ввод-вывод по оставшимся путям. Подробнее про

конфигурирование DNFS по нескольким путям читайте:

https://support.oracle.com/CSP/main/article?cmd=show&type=NOT&doctype=HOWTO&id=822481.1.

Windows Клиент Direct NFS требует специальный конфигурационный файл для организации соответствия

(маппинга) экспортов NFS сервера на локальные точки монтирования. Его расположение по

умолчанию: %ORACLE_HOME%\dbs\oranfstab.

Файлы базы данных, доступные через клиент Direct NFS client в случае Windows должны также

быть смонтированы с помощью других средств, например через CIFS. Это обеспечит доступность

этих файлов для ввода-вывода также через kernel I/O interface.

Пример ниже показывает конфигурационный файл oranfstab который маппит три тома NFS с

сервера NFSServer, и которые доступны по четырем различным путям.


Пример: oranfstab в Windows

server: NFSServer

path: NFSPath1

path: NFSPath2

path: NFSPath3

path: NFSPath4

export: /vol/oradata1 mount: D:\ORACLE\ORADATA1

export: /vol/oradata2 mount: D:\ORACLE\ORADATA2

export: /vol/oralog mount: D:\ORACLE\ORALOG1

uid: xxxxx

gid: yyyyy

Конфигурационный файл oranfstab в Windows содержит некоторые дополнительные опции для

обеспечения безопасности в NFS. Параметры ‘uid’ и ‘gid’ могут быть добавлены в конец каждой

серверной конфигурации для соответствия с UNIX user ID и gid, соответствующего UNIX group ID,

используемых клиентом Direct NFS.

Конфигурация Direct NFS для Real Application Clusters

В Oracle Database 11g, только файлы, относящиеся к самому Oracle, такие как файлы данных,

online redo logs, файлы archive log, и временные файлы могут быть использованы через Oracle

DNFS client. Файлы Oracle Clusterware (CRS) недоступны через Direct NFS и требуют нативного

монтирования по NFS с правильными опциями. Смотрите главу о FCP SAN Initiators для Linux для

правильных опций монтирования томов CRS. Для опций хранилища смотрите главу 4.7.

Подробнее смотрите document ID 762374.1 на my Oracle Support.

Сайзинг Direct NFS

Клиент Oracle Direct NFS client стабильно показывает лучшую производительность, чем нативный

клиент NFS операционной системы, тем самым сокращается разрыв между NFS и FCP на ряде

характеров рабочих нагрузок. Рекомендуется принимать при сайзинге приложений

производительность Oracle Direct NFS Client на 10% - 20% больше, по сравнению с Native Kernel

NFS Client.

Хранилище для файлов Oracle Clusterware

Файлы Oracle Cluster Registry и файлы voting не могут храниться на хранилище, смонтированном

через DNFS. Для опций хранения OCR и файлов voting, смотрите главу 4.7.

Рекомендованные патчи для Direct NFS Client

Следующие патчи Oracle необходимы к применению, в зависимости от использованной версии

Oracle Database:

• 11.2.0.1: Большинство багфиксов доступно в патче 8981354.

• 11.2.0.2: Большинство багфиксов доступно в патче 9977452.

4 Настройка Oracle Database

4.1 DISK_ASYNCH_IO Параметр DISK_ASYNCH_IO управляет включением асинхронного ввода-вывода для файлов

данных, control и log-файлов (то есть такого процесса ввода-вывода, когда несколько параллельно

https://support.oracle.com/

идущих процессов ввода-вывода сервера могут исполняться «перекрываясь»). Если платформа

поддерживает асинхронный ввод-вывод на диск, Oracle рекомендует вам оставить этот параметр

установленным в значении по умолчанию,TRUE. Однако, если асинхронный ввод-вывод

нестабилен, вы можете установить этот параметр в FALSE и запретить использование такого

режима. Если платформа не поддерживает асинхронный ввод-вывод, то значение этого

параметра не имеет эффекта.

Асинхронный ввод-вывод позволяет процессам выполняться вместе со следующей за ними

операцией, без необходимости ожидания завершения предшествующей операции записи, что

улучшает системную производительность и минимизирует задержки. Если параметр

DISK_ASYNCH_IO установлен в TRUE, тогда для того, чтобы получить преимущества в

производительности, также должны быть использованы DB_WRITER_PROCESSES или

DBWR_IO_SLAVES, как это описано ниже. Принцип вычисления значения таков:

DB_WRITER_PROCESSES = 2 * number of CPU cores.

Выбор между множественными процессами DBWR и использованием I/O Slaves

Если один процесс DBWR не успевает обрабатывать необходимую нагрузку, то использование

нескольких процессов DBWR выгодно с точки зрения производительности, особенно когда база

данных работает на многопроцессорном сервере. Однако перед конфигурированием

множественных процессов DBWR проверьте, что асинхронный ввод-вывод возможен и правильно

сконфигурирован на системе. Если система поддерживает асинхронный ввод-вывод, но он не

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

система не поддерживает асинхронный ввод-вывод, или когда он включен, но процесс DBWR

является узким местом, тогда сконфигурируйте использование множественных процессов DBWR.

Внимание: Если асинхронный ввод-вывод не доступен для данной платформы, то он может

быть запрещен в настройках Oracle установкой инициализационного значения

DISK_ASYNCH_IO в FALSE.

Использование множественных процессов DBWR позволяет параллелизовать обработку и запись

буферов. Несколько DBWR могут обеспечить большую пропускную способность, чем один DBWR,

при одинаковом числе I/O slaves. По этой причине, множественные DBWR предпочтительнее, чем

использование I/O slaves. I/O slaves должны использоваться только в случае, если невозможно

использовать множественные процессы DBWR.

4.2 DB_FILE_MULTIBLOCK_READ_COUNT Этот параметр определяет максимальное число блоков базы данных, считываемых за одну

операцию ввода-вывода во время full table scan. Число считываемых байт базы данных

высчитывается умножением DB_BLOCK_SIZE * DB_FILE_MULTIBLOCK_READ_COUNT. Установка этого

параметра может уменьшить число вызовов ввода-вывода, требуемых для full table scan, что

улучшает производительность. Увеличение значения этого параметра может улучшить

производительность базы данных, которая выполняет множество full table scan, но снизить

производительность OLTP-базы, в которой full table scan делается сравнительно редко.

Установка значения этого параметра кратной величине параметра NFS READ/WRITE,

определяемого в опциях монтирования, может ограничить эффект фрагментации, происходящей

в подсистеме ввода-вывода. Учтите, что этот параметр определен в «блоках базы данных» (DB

Blocks), а настройки NFS в «байтах». Как пример, задание параметра

DB_FILE_MULTIBLOCK_READ_COUNT равным 4, умноженное на DB_BLOCK_SIZE равное 8kB, будет

означать размер буфера чтения в 32kB.

Начиная с Oracle Database 10g R2 и новее, значение по умолчанию для этого параметра это

значение, соответствующее максимальному размеру блока ввода-вывода, которое может быть

эффективно выполнено. Эта величина зависит от платформы, и составляет 1MB для большинства

платформ. Так как этот параметр выражается в блоках, он соответствует величине, равной

эффективному максимальному размеру ввода-вывода, деленному на стандартный размер блока.

Отметьте, что если число сессий экстремально высоко, значение multiblock read count снижается

для предотвращения переполнения буфера кэша слишком большим числом table scan.

Максимальное значение равно максимальной величине операции ввода-вывода OS, выраженной

в блоках Oracle ((max I/O size)/DB_BLOCK_SIZE). Если величина этого параметра установлена в

значение, превышающее максимум, то Oracle использует максимальное из доступных значений.

В некоторых ситуациях DB_FILE_MULTIBLOCK_READ_COUNT не оказывает никакого влияния на

результат. В недавно проведенных тестированиях DB_FILE_MULTIBLOCK_READ_COUNT показывал

меньшую производительность на full table scan, чем использование параллелизма с помощью

обработки параллельных запросов в Oracle.

В некоторых случаях, увеличение значения DB_FILE_MULTIBLOCK_READ_COUNT может улучшить

производительность операций scan. Типичное рекомендованное значение равно 16, 32, или 64.

Может потребоваться провести тестирование конкретной реализации системы, чтобы определить

оптимальную настройку DB_FILE_MULTIBLOCK_READ_COUNT. Для подробностей об этом параметре

смотрите документы [14] и [15] в разделе справочных материалов.

4.3 DB_BLOCK_SIZE DB_BLOCK_SIZE определяет (в байтах) размер блока Oracle Database. Типичное значение равно

4096 или 8192 байта. Значение этого параметра должно быть кратно размеру физического блока

устройства хранения. Значение по умолчанию для Oracle Database 11g равно 8192 байта. Диапазон

значений может быть от 2048 до 32768 байт, но некоторые OS сужают доступный диапазон

значений выбора.

Значение DB_BLOCK_SIZE задействуется в момент создания базы данных, и определяет размер ее

блоков. Это значение должно оставаться неизменным после создания базы.

Для RAC, этот параметр должен быть установлен для каждого инстанса, и множественные

инстансы должны иметь идентичное его значение. Этот параметр влияет на максимальное

значение параметра хранилища FREELISTS для таблиц и индексов RAC. Oracle использует один

блок базы для каждой группы freelist. Decision support system (DSS) и базы Data Warehouse обычно

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

Для наилучшей производительности базы данных, DB_BLOCK_SIZE должен быть кратен величине

OS block size. Например, если в Solaris block size равен 4096:

DB_BLOCK_SIZE = 4096 * n

Величины, определенные в опциях NFS rsize и wsize при монтировании файловой система,

также должны быть кратны этому значению. Ни при каких обстоятельствах они не должны быть

меньше. Например, если в Oracle DB_BLOCK_SIZE установлен в 16kB, то в NFS параметры rsize и

wsize должны быть равны 32kB или 64kB, но не 8kB или 4kB.

4.4 DBWR_IO_SLAVES и DB_WRITER_PROCESSES DB_WRITER_PROCESSES важен для систем, активно изменяющих данные в базе. Он определяет

начальное значение числа процессов записей в базу для инстанса. Если используется

DBWR_IO_SLAVES, позволен только один процесс database writer, вне зависимости от установок

DB_WRITER_PROCESSES. Множественные DBWR и DBWR I/O slaves не могут сосуществовать.

Рекомендуется использовать установку либо того , либо другого параметра для компенсации

падения производительности при отключении DISK_ASYNCH_IO. Статья на Metalink 97291.1

показывает, как это использовать.

Ключевое правило – всегда включать использование DISK_ASYNCH_IO, если это поддерживается в

OS. Далее проверьте, поддерживается ли это для NFS или только для блочного доступа (FC/iSCSI).

Если это поддерживается для NFS, тогда рассмотрите вариант включения асинхронного ввода-

вывода на уровне Oracle и на уровне OS, и измерьте прирост производительности. Если

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

асинхронный ввод-вывод для NFS не поддерживается, или производительность неприемлема,

тогда рассмотрите варианты включения множественных DBWR и DBWR I/O slaves, как описано

далее.

Множественные DBWR и DBWR I/O Slaves не могут работать вместе. Рекомендуется выбрать или

тот или другой вариант, для компенсации потери производительности при отключении

DISK_ASYNCH_IO. Рекомендуется использовать DBWR_IO_SLAVES на однопроцессорной системе, а

DB_WRITER_PROCESSES на многопроцессорном сервере.

I/O slaves могут быть использованы для эмуляции асинхронного ввода-вывода на платформе, не

поддерживающий нативный асинхронный режим, или реализующий его неэффективно. Однако

I/O slaves могут также быть полезными и когда асинхронный ввод-вывод работает.

DBWR_IO_SLAVES предназначен для сценария использования, когда невозможно использование

множественных DB_WRITER_PROCESSES (например, когда у вашего сервера баз данных только один

CPU). I/O slaves также применимы, когда недоступно использование асинхронного ввода-вывода,

так как множественные I/O slaves эмулируют неблокирующие, асинхронные запросы, освобождая

DBWR для дальнейшей идентификации блоков в кэше, требующих записи.

Режим асинхронного ввода-вывода на уровне OS, если он возможен, наиболее предпочтителен.

DBWR I/O slaves создаются немедленно, вслед за тем, как база данных открывается для первого

же обращения ввода-вывода.

Процесс DBWR продолжает выполнять все относящиеся к задачам DBWR работы, помимо

собственно ввода-вывода. I/O slaves выполняют только ввод-вывод по требованию DBWR. Запись

пакета заданий параллелится между I/O slaves.

Множественные процессы DBWR не могут использоваться вместе с I/O slaves. Конфигурирование

использования I/O slaves позволит стартовать только одному процессу DBWR.

Конфигурирование нескольких процессов DBWR позволяет получить выигрыш

производительности, когда один процесс DBWR не справляется с нагрузкой.

В общем случае, множественные процессы DBWR позволяют достичь большей

производительности, чем один процесс DBWR с аналогичным количеством I/O slaves.

Использовать I/O slaves следует только в случае, если невозможно использовать множественные

процессы DBWR.

Best Practice

NetApp рекомендует использовать DBWR_IO_SLAVES на однопроцессорных, а

DB_WRITER_PROCESSES на многопроцессорных системах.

4.5 Flashback и Flash recovery area

Flashback

Oracle Flashback записывает операции изменения блоков. Его основная задача использования –

исправление пользовательских ошибок и неверных данных. Он действует как вид «непрерывной

резервной копии» (continuous backup). Лог flashback моет быть воспроизведен повторно, для

восстановления базы данных на определенный момент времени. Пользователи могут считать это

своеобразной кнопкой «перемотка назад» для базы данных. Воспроизведение flashback log

приведет к восстановлению только измененных блоков. По умолчанию, flashback logs хранятся в

области под названием flash recovery area.

Flash recovery area

Область flash recovery area это пространство хранения, которое вы можете использовать для

хранения на нем файлов, относящихся к процессу восстановления, например control file и копий

online redo log, archive log, flashback logs, и резервных копий RMAN. Это опциональная директория,

управляемая Oracle Database, файловая система, или дисковая группа в ASM, которая

централизованно хранит резервные копии ключевых элементов системы. Вы можете настроить

flash recovery area при создании базы данных, с использованием Database Configuration Assistant

или добавить ее позже.

Oracle Database может писать archive logs в область flash recovery area. RMAN может сохранять

туда резервные копии, или восстанавливать данные оттуда в ходе процессов восстановления

системы. Область flash recovery area также работает как дисковый кэш для сохранения на

магнитную ленту.

Компоненты Oracle Database взаимодействуют с flash recovery area, чтобы быть уверенными, что

база данных полностью восстановима при использовании файлов, сохраненных в этой области

хранения. Все файлы, необходимые для восстановления базы данных после аварии, содержатся

на flash recovery area.

На ней находятся:

• Актуальный файл control

• Online redo logs

• Archived redo logs

• Flashback logs

• Control file autobackups

• Копии файлов данных и файла control

• Резервные копии

Oracle Database позволяет вам задать лимиты, для определения того, какой объем пространства

база данных может использовать в flash recovery area. Это не включает в себя любые оверхеды,

неизвестные Oracle Database.

Например, дисковые лимиты не учитывают дополнительные объемы файловой системы, которая

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

Oracle Database и RMAN создают файлы в flash recovery area пока занятое пространство в ней не

достигнет заданного лимита. Когда понадобится место для новых файлов, Oracle Database удалит

файлы из flash recovery area, которые отсутствуют, избыточны или скопированы на стороннее

хранилище. Oracle Database выводит предупреждающее сообщение, когда места останется менее

15%, но продолжит заполнять диск, пока он не заполнится целиком.

Чем больше объем flash recovery area, тем более она полезна. Рекомендуется задать дисковый

лимит, равный сумме базы данных, плюс объему инкрементальных резервных копий, и объему

всех archive logs, которые еще не были скопированы на ленту.

Убедитесь, что размер тома NetApp достаточно велик, чтобы хранить все необходимые файлы,

записываемые в flash recovery area. Постоянно наблюдайте использование его пространства на

томе. Установите лимит для flash recovery менее чем емкость тома NetApp, что поможет уберечься

от возникновения ошибок ENOSPC, и предотвратит исчерпание места на томе.

4.6 Oracle Cluster File System 2 (OCFS2)

Обзор OCFS2

OCFS2 это файловая система с открытым кодом, разработанная Oracle, и доступная для

платформы Linux. Это файловая система, построенная на экстентах («экстент» (extent) это

адресуемый непрерывный фрагмент пространства хранения переменной длины), используемая

для хранения файлов данных Oracle и Oracle RAC. В отличие от своей предыдущей версии (OCFS),

OCFS2 это файловая система общего применения, которая может быть использована для хранения

совместно используемого Oracle home, делая управление Oracle RAC еще проще.

С точки зрения интерфейса к файлам, который она предоставляет приложениям, OCFS2

обеспечивает баланс производительности и управляемости, предлагая функциональность,

среднюю между функциональностью raw-диска и типичной файловой системы. Сохраняя высокую

производительность raw-устройств, OCFS2 обеспечивает высокоуровневые, более удобные для

управления интерфейсные средства. В связи с этим OCFS2 можно рассматривать как подобный

файловой системе интерфейс к raw-устройствам. Одновременно, кластерные возможности OCFS

выходят далеко за рамки функциональности типичной файловой системы.

Файлы на OCFS2 могут совместно использоваться несколькими узлами в сети, так что доступ к

файлам сохраняется для всех узлов кластера, что необходимо для работы конфигурации RAC.

Например, совместный доступ к файлам позволяет восстановление данных, в случае дискового

сбоя, так как все файлы данных (например, archive log) доступны со всех узлов, включенных в RAC.

Кроме кластерных возможностей, OCFS2 обеспечивает множество удобных возможностей

управления, например изменения размеров файлов и партиций, и поставляется с набором

инструментов для управления файлами на OCFS2.

Конфигурация OCFS2

Поставка OCFS2 включает в себя два набора пакетов, модуль ядра и инструменты. Модуль ядра

доступен для скачивания с http://oss.oracle.com/projects/ocfs2/files, а инструменты с

http://oss.oracle.com/projects/ocfs2-tools/files.

Версия OCFS2 1.2.3 и выше поставляется для Enterprise Linux 4, тогда как OCFS2 1.2.6 поставляется

для Enterprise Linux 5. OCFS2 не поставляется Red Hat. Пользователи Red Hat Enterprise Linux 4 и 5

должны скачать и установить соответствующие модули и инструментарий.

OCFS2 1.2.5 поставляется с SLES10 SP1. OCFS2 1.2.3 поставляется с SLES9 SP3 kernel 2.6.5-7.283 и

SLES10.

Конфигурационный файл OCFS2, /etc/ocfs2/cluster.conf. В нем определяются все узлы,

участвующие в кластере. Этот файл должен быть одинаков на всех узлах кластера. Если новые

узлы кластера вы можете добавлять динамически, то любые другие изменения, например имя

или IP-адрес, требуют для применения перезапуска кластера.

Инструменты OCFS2 включают в себя GUI-утилиту, ocfs2console, для настройки и копирования

cluster.conf на все узлы кластера. Эту настройку надо сделать на одном узле кластера. После

этого пользователи увидят такой же /etc/ocfs2/cluster.conf на всех узлах кластера.

Сервисы O2CB

OCFS2 поставляется с собственным кластерным стеком, O2CB. Этот стек включает в себя:

• NM: Node manager, отслеживающий все изменения, на всех узлах в файле cluster.conf

• HB: Heartbeat service, уведомляет кластер, когда узлы кластера подключаются или

отключаются от него

• TCP: Обеспечивает коммуникацию между узлами

• DLM: Distributed lock manager, отслеживает локирования, их владельцев и статусы

• CONFIGFS: Конфигурационная файловая система юзерспейса, монтируемая в /config

• DLMFS: Интерфейс юзерспейса для kernel space DLM

Все кластерные сервисы находятся в системном сервисе O2CB. Операции с OCFS2, такие как

форматирование, монтирование, и так далее, требуют запущенного кластерного сервиса O2CB на

узле, на котором выполняются эти действия.

Монтирование партиций OCFS2

Создание партиций рекомендуется, даже если вы планируете использовать под OCFS2 диск

целиком. Помимо того, что диск с партициями сложнее ошибочно использовать, уничтожив

нужную информацию, некоторые функции, такие как «монтирование по метке» (mount-by-label)

работают только с томами, созданными на партиции. Воспользуйтесь fdisk или parted, или

подобной утилитой для операции создания партиций.

Перед монтированием любых дисков как партиции OCFS2, требуется сформатировать диск/LUN с

помощью mkfs.ocfs2 или ocfs2console GUI-утилиты.

При форматировании вам потребуется знать два размера:

• cluster size: Размер задается в диапазоне от 4K до 1M. Для тома хранения данных или

больших файлов, подходит размер от 128K или более.

http://oss.oracle.com/projects/ocfs2/files

http://oss.oracle.com/projects/ocfs2-tools/files

• block size: Размер поддерживается от 512 байт до 4K. Так как OCFS2 не размещает

статическое пространство узла при форматировании, то размер блока, равный 4K

рекомендуется для большинства размеров дисков. Хотя размер поддерживается вплоть

до 512 байт, использовать такой маленький блок не рекомендуется в любом случае.

Величины cluster size, и blocks size будут неизменяемы после форматирования.

Тома OCFS2, содержащие файлы voting disk file (CRS), cluster registry (OCR), файлы данных, redo

logs, archive logs, и control files должны быть смонтированы с опциями datavolume и nointr.

Опция datavolume обеспечивает то, что Oracle открывает эти файлы с флагом o_direct. Опция

nointr обеспечивает отключение прерываний ввода-вывода по сигналам.

# mount -o datavolume,nointr -t ocfs2 /dev/sda1 /u01/db

4.7 Хранение файлов Oracle Oracle имеет ряд ограничений на то, какой тип хранилища может хранить те или иные файлы

инсталляции Oracle Database 11g (Oracle Home и CRS Home), а также файлы Clusterware. Oracle

Clusterware требует двух файлов с возможностью записи, доступных всем узлам RAC. Эти файлы

называются Oracle Cluster Registry (OCR) file и voting file. Глава описывает приемлемые способы

хранения файлов Oracle, OCR и voting file.

Таблица 4) Способы хранения файлов Oracle.

Опция хранения Поддерживаемые типы файлов

OCR и Voting disk ПО Oracle

ASM Да (11gR2) Нет

OCFS2 Да Да

Red Hat GFS Да Да

Локальное хранилище Нет Да

Общий диск (блочный) Да Нет

Клиент NFS

Native NFS Да Да

Direct NFS Нет Да

Внимание: DNFS не поддерживается для файлов CRS (ORC file, voting file) в версии Oracle Database

11g . Для базы данных, использующей клиент Direct NFS, файлы OCR и voting files

должны лежать на томе, доступ к которому осуществляется с помощью других

методов, например нативного клиента NFS соответствующей OS (kernel NFS).

5 Варианты использования

5.1 Защита данных

Резервное копирование и восстановление

Для подробного рассмотрения темы резервного копирования, восстановления и построения

катастрофоустойчивой архитектуры, смотрите документы [8], [9], и [10] в Справочных материалах,

в конце данной работы.

Как создать резервную копию на системе хранения NetApp

Данные, которые хранятся на системе хранения NetApp, могут иметь резервную копию на онлайн-

хранилище, на near-line, или на магнитной ленте (offline). Протокол, используемый для доступа к

данным, когда производится резервное копирование, должен быть принять во внимание. Когда

для доступа к данным используются NFS и CIFS, можно применить средства Snapshot и SnapMirror,

которые всегда дадут нам консистентную копию файловой системы. Они должны также

координироваться с состоянием Oracle Database, чтобы обеспечить консистентность уровня базы

данных.

При использовании Fibre Channel или iSCSI, средства Snapshot и SnapMirror всегда должны

координироваться с сервером. Файловая система на сервере должна быть блокирована и все

данные сброшены на хранилище NetApp до того, как устройство будет выполнять команду на

создание снэпшота.

Данные могут копироваться как внутри того же хранилища NetApp, так и на другую систему

хранения NetApp, на устройство NearStore®, на магнитную ленту или стороннюю систему

хранения. Устройство на магнитной ленте может быть подключено непосредственно к системе

хранения, или же включено в сеть Ethernet или Fibre Channel, и система хранения может

производить копирование на ленточное устройство по этой сети.

Возможные методы создания резервной копии на NetApp:

• Использовать SnapManager® for Oracle для создания онлайн- и оффлайн-копий

• Использовать автоматизированное создание снэпшотов для создания онлайн-копий

• Использовать скрипты на сервере, с подключением к системе хранения NetApp по ssh или rsh,

для создания снэпшотов вызовом на ней соответствующей команды

• Использовать SnapMirror для репликации данных на другое хранилище NetApp или

устройство типа NearStore

• Использовать команды на уровне OS сервера для копирования данных или создания

резервной копии

• Использовать команды протокола NDMP для резервного копирования данных на систему

хранения NetApp или устройство NearStore

• Использовать NDMP для резервного копирования данных на устройство на магнитной ленте

• Использовать сторонние средства резервного копирования для создания копии данных с

NetApp или NearStore на магнитную ленту или сторонние хранилища

Создание online-копии с помощью снэпшотов

Технология NetApp Snapshot позволяет предельно эффективно использовать хранилище, сохраняя

на нем только изменения на блочном уровне между каждой созданной снэпшот-копией. Так как

процесс создания снэпшота практически мгновенен, создание резервной копии происходит

быстро и просто. Создание снэпшотов может быть организовано по расписанию, они могут

создаваться командой в скрипте, работающем а сервере, или они могут быть созданы с помощью

средств SnapDrive® или SnapManager.

Data ONTAP включает в себя планировщик для автоматизированного создания снэпшотов.

Используйте автоматически создаваемые копии для резервного копирования таких данных, как,

например, домашние папки пользователей.

Базы данных, и другие данные приложений следует копировать в резервную копию в момент,

когда приложение находится в режиме создания такой резервной копии его данных. В случае

Oracle Databases это означает переведение базы данных в hot backup mode перед взятием

непосредственно снэпшота. У NetApp имеется несколько руководств, детально рассматривающих

процессы создания резервной копии баз Oracle Database.

Для дополнительной информации о требованиях защиты данных, смотрите документ [11].

Best Practice

Используйте снэпшоты для создания «горячих» и «холодных» резервных копий Oracle Databases.

Создание и хранение резервных копий данных не отражается на производительности системы

хранения NetApp. Рекомендуется выключить автоматическое создание снэпшотов по расписанию

и координировать их создание с состоянием Oracle Database.

Для подробного рассмотрения темы интеграции снэпшотов с процессами резервного

копирования баз Oracle Database, смотрите документы [3] и [7].

Восстановление отдельного файла из снэпшота

Отдельный файл или директория могут быть восстановлены из снэпшота с использованием

обычных команд копирования OS, например UNIX «cp», или перетаскиванием из папки в папку в

Microsoft® Windows. Данные также могут быть восстановлены с использованием команды

snaprestore для одного файла (single-file SnapRestore). Используйте метод, который работает

быстрее и удобнее в вашем случае.

Восстановление данных с использованием SnapRestore

SnapRestore быстро восстанавливает состояние файловой системы целиком, до состояния

сохраненного в снэпшоте. SnapRestore можно использовать для восстановления тома целиком, со

всеми данными на нем, или для восстановления индивидуальных файлов с него.

Когда вы используете SnapRestore для восстановления тома данных, данные на томе должны

принадлежать одному приложению. В противном случае, восстановление данных может

нежелательно повлиять и на другие приложения, данные которых окажутся на

восстанавливаемом томе.

Опция восстановления отдельного файла с использованием SnapRestore позволяет выбирать для

восстановления индивидуальные файлы, без восстановления всех остальных данных на томе.

Обратите внимание, что файл, который восстанавливается с использованием SnapRestore, не

может существовать где либо в данной активной файловой системе. Если он существует, то Data

ONTAP вместо single-file SnapRestore выполнит операцию копирования. Это может привести к

тому, что операция single-file SnapRestore займет гораздо больше времени, чем ожидается

(обычно эта команда выполняется за доли секунды) Кроме этого она может потребовать

достаточное количество свободного места на активной файловой системе.

Best Practice

Используйте SnapRestore для мгновенного восстановления Oracle Database любого объема.

SnapRestore может восстановить целиком том на его состояние в прошлом, или восстановить с

него отдельный файл. Преимуществом использования SnapRestore на уровне тома является

восстановление тома целиком за минуты, что снижает простой и недоступность при

восстановлении Oracle Database. При использовании SnapRestore на уровне тома, рекомендуется

хранить файлы логов Oracle, файлы archive log, и копии control files на отдельных томах, отдельно

от основного тома данных, и использовать SnapRestore только для томов, содержащих файлы

данных Oracle.

Подробнее об использовании SnapRestore для восстановления Oracle Database, смотрите

документы [3] и [7].

Консолидирование резервных копий с помощью SnapMirror

SnapMirror реплицирует данные с одного тома или qtree на одну или более удаленных систем

NetApp. Он непрерывно обновляет реплицированную копию, поддерживая ее актуальной и

доступной.

SnapMirror особенно полезный инструмент для сокращения окна резервного копирования на

основной, первичной системе.

SnapMirror может быть использован для непрерывной репликации данных с первичной системы

хранения на выделенную вторичную near-line систему. Операции резервного копирования

переносятся на систему, где процесс копирование содержимого на магнитную ленту может

происходить неограниченно долго, без помех для основной задачи системы. Так как операции

резервного копирования теперь не занимают первичную систему, то проблема размеров «окна

резервного копирования» больше не является проблемой.

Создание удаленного катастрофоустойчивого сайта (DR-site) с помощью SnapMirror

SnapMirror непрерывно реплицирует указанный набор данных для того, чтобы поддерживать

удаленную копию актуальной и доступной. SnapMirror это хороший инструмент для создания

катастрофоустойчивого удаленного сайта. Тома между основным и удаленным сайтом могут

реплицироваться асинхронно или синхронно. Сервера с приложениями должны также быть

реплицированы на удаленном сайте.

В случае, когда работа перенесена на DR-сайт, приложения переключаются на сервера удаленного

сайта, и весь трафик приложений направляется через него, пока основной сайт не будет

восстановлен. Когда работоспособность основного сайта восстановлена, то SnapMirror может быть

использован для эффективной передачи данных обратно, с DR-сайта на основной сайт, обновляя

его до актуального состояния. После возвращения основного сайта к нормальной работе, можно

продолжить обновлять данные на DR-сайте, без необходимости заново производить повторную

полную передачу так называемого baseline-копирования.

Для подробностей об использовании SnapMirror для задач построения DR-решения под Oracle,

смотрите документ [12].

NDMP и Native Tape Backup and Recovery

Network Data Management Protocol, или NDMP, это открытый стандарт для централизованного

управления процессами передачи данных. Архитектура NDMP позволяет производителям ПО

резервного копирования управлять внутренними функциями резервного копирования в системах

хранения NetApp, или файловых серверов, обеспечивая общий единый интерфейс между

приложением резервного копирования и файловым сервером.

NDMP разделяет потоки управления данными и собственно сами данные, позволяя отделить

поток данных резервной копии, или восстановления из нее, от процессов управления ее

созданием и восстановлением.

Это дает большую гибкость в конфигурировании системы, используемой для защиты данных на

хранилище NetApp. Так как с использованием NDMP потоки данных и метаданных разделены, они

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

топологию NDMP-совместимых устройств. Доступные топологии NDMP обсуждаются в документе

[13].

Если оператор не определил существующий снэпшот при выполнении операции резервного

копирования (как обычного, так и NDMP), то Data ONTAP создаст такой перед началом операции.

Этот снэпшот будет удален, когда операция резервного копирования будет выполнена. Если

доступ к данным осуществляется через блочные протоколы, например FCP, то снэпшот должен

создаваться в момент, когда данные на дисках консистентны. Как уже говорилось ранее, идеально

это делается с помощью локирования приложения или перевода его в hot backup mode перед

созданием снэпшота.

После создания резервной копии, обычная работа приложения может быть возобновлена, а

резервное копирование на магнитную ленту содержимого снэпшота может продолжаться любое

необходимое для этого процесса время.

При подключении устройства хранения к Fibre Channel SAN для проведения резервного

копирования на ленту, прежде всего нужно убедиться, что NetApp поддерживает используемое

оборудование и ПО. Полный список поддерживаемых конфигураций имеется на сайте поддержки

NetApp. При подключении устройств хранения на магнитной ленте и библиотек к системам

хранения NetApp через коммутаторы Fibre Channel, следует помнить, что в этом варианте не

поддерживаются подключения с избыточными линками в SAN. Кроме этого, на стороне NetApp

следует использовать для подключения устройств на магнитной ленте выделенный под эту задачу

HBA. Этот адаптер может быть включен в отдельный коммутатор Fibre Channel, содержащий

только устройства NetApp, NearStore и поддерживаемые устройства записи на магнитную ленту

или библиотеки. Сервер резервного копирования должен сообщаться с библиотекой с помощью

NDMP или управлять роботом библиотеки, подключенным непосредственно к серверу резервного

копирования.

Основные партнеры NetApp по разработке Data Management Application (DMA) это IBM (Tivoli

Storage Manager) и Symantec (NetBackup™).

Сценарий 1 (Роли NDMP при резервном копировании данных с системы хранения NetApp на

устройство записи на магнитной ленте)

NDMP используется приложением DMA для резервного копирования данных с системы хранения

NetApp на магнитную ленту.

NetApp поддерживает несколько топологий для резервного копирования и восстановления

данных. Это локальное подключение (local), удаленное (remote), и так называемое «3-way».

Эти топологии отличаются способом подключения устройства записи на магнитной ленте к

системе хранения NetApp.

• Локальное: Устройство записи на магнитной ленте подключено непосредственно к

системе хранения NetApp, с которой необходимо провести резервное копирование

данных (Система хранения NetApp -> устройство записи на магнитной ленте).

• 3-Way: Устройство записи на магнитную ленту подключено не непосредственно к той

системе хранения, с которой производится резервное копирование, а к другой системе

NetApp по сети (Система хранения NetApp -> Система хранения NetApp -> устройство

записи на магнитной ленте).

• Удаленное: Устройство записи на магнитную ленту подключено к серверу DMA, и данные

с системы хранения NetApp сохраняются на ленту через сервер (Система хранения NetApp

-> сервер резервного копирования).

DMA инициирует резервное копирование, используя протокол NDMP, и передает запрос на

сервер данных NDMP на системе хранения NetApp, который использует BSD dump для

выполнения учета файлов и передачи их содержимого на ленту. Чем больше размер и меньше

количество файлов, тем быстрее идет резервное копирование. Так происходит потому, что Data

ONTAP передает обновления состояния истории файлов на DMA для каждого обработанного и

записанного в резервную копию файла. Учет подлежащих резервному копированию файлов и

обновление истории занимает значительное время в общем объеме затрат времени на резервное

копирование.

В настоящий момент, Oracle Secure Backup v10.1.0.3 сертифицирован для использования с Data

ONTAP 7.1.1.1 и 7.2.1 с NDMP v4.

Использование устройств на магнитной ленте с NetApp

Системы хранения NetApp и устройства NearStore поддерживают резервное копирование на

локально подключенные, а также подключенные по Fibre Channel или Gigabit Ethernet SAN

устройства записи на магнитную ленту. Поддерживаются большинство ныне существующих

устройств записи на магнитную ленту, но также существует простой метод добавления новых

подобных устройств для их производителей. Вдобавок полностью поддерживается протокол rmt,

позволяя запись и восстановление для любой поддерживающей его системы. Образы резервных

копий пишутся в стандартном формате BSD dump stream, позволяя использовать как полный

backup, так и девять уровней дифференциального backup.

Поддержка сторонних средств резервного копирования

NetApp взаимодействует с несколькими сторонними производителями для поддержки решений с

использованием NDMP для резервного копирования данных, хранящихся на системах хранения

NetApp. Для подробного списка смотрите Interoperability Matrix, размещенную на сайте NetApp

Support.

Наилучшие практики и рекомендации резервного копирования и восстановления

Эта глава сводит воедино технологии защиты данных NetApp, и продукты, описанные ранее, в

общую схему наилучших практик для выполнения Oracle hot backups при резервном копировании,

восстановлении и архивировании, с использованием системы хранения NetApp с

высокопроизводительными дисками SAS и Fibre Channel, и хранилища класса near-line (NearStore

это система хранения, использующая сравнительно недорогие и емкие диски SATA). Такая

комбинация из основного хранилища для рабочей, production database, и дискового хранилища

класса near-line для резервного копирования активного набора данных, улучшает

производительность и снижет стоимость операций. Периодическое перемещение данных с

основного хранилища на near-line увеличивает свободное пространство и улучшает

производительность, одновременно снижая затраты.

http://now.netapp.com/matrix/



Внимание: Если вы не планируете использовать NetApp NearStore в вашей схеме резервного

копирования, то проконсультируйтесь с документом [6] для подробностей о

резервном копировании и восстановлении Oracle на устройствах хранения NetApp с

использованием снэпшотов. Остальная часть данного раздела написана исходя из

того, что вы используете устройства и технологии NetApp для выполнения задач

резервного копирования и восстановления.

SnapManager for Oracle

SnapManager автоматизирует и упрощает сложные, ручные, и занимающие значительное время

процедуры резервного копирования, восстановления и клонирования Oracle Databases.

SnapManager for Oracle использует такие технологии NetApp, как Snapshot, SnapRestore, и

FlexClone, интегрируя их со средствами Oracle Database. SnapManager также интегрирован с

собственными технологиями Oracle (такими, например, как RAC, RMAN, и ASM) и поддерживает

протоколы FC, iSCSI, и NFS. Он позволяет компаниям масштабировать их инфраструктуру хранения,

и удовлетворять строгим требованиям SLA, улучшая качество работы и администрирования баз

данных во всей компании.

В версии 3.1, SnapManager for Oracle поддерживает средства Oracle Database 11g R2 (RAC, RMAN, и

ASM) протоколы FC, iSCSI, NFS, а также протокол Direct NFS. Для наиболее полного и актуального

состояния дел с поддержкой, смотрите Interoperability Matrix.

Best Practice

Для рекомендаций и наилучших практик использования SnapManager for Oracle, смотрите:

www.netapp.com/us/library/technical-reports/tr-3761.html.

SMO Backup

SnapManager for Oracle использует технологию NetApp Snapshot для создания быстрых и

эффективно использующих пространство на дисках резервных копий. Снэпшоты – это мгновенная

«виртуальная копия» базы данных, которая создается практическим мгновенно. Такие резервные

копии могут быть учтены в Oracle RMAN, чтобы можно было использовать средства RMAN для

восстановления и возобновления работы базы данных с гранулярностью, равным дисковому

блоку.

Резервные копии, созданные с использованием данной технологии, эффективно расходуют

дисковое пространство, так как они используют для хранения только тот объем, который является

дифференциальной разницей, между снэпшотом и активной файловой системой. Для

администратора базы данных это значит, что он может чаще создавать резервные копии,

сокращая время восстановления (mean time to recovery, MTTR).

Другая ключевая особенность SnapManager for Oracle заключается в возможности

верифицировать целостность резервной копии после ее создания, используя стандартные для

Oracle операции верификации копии. DBA может также отложить или перенести на удобное

время процесс верификации резервной копии, если это необходимо.

SnapManager for Oracle работает как для standalone-конфигурации Oracle Databases, так и для RAC.

Поддерживается ASM. Конфигурация с использованием ASM позволяет соединить выгоды

виртуализации хранилища, предлагаемого ASM, с эффективными средствами резервного

копирования в SnapManager. Для конфигурации с использованием RAC, администратор базы

данных может создать резервную копию, запустив SnapManager for Oracle с любого узла RAC.

http://now.netapp.com/matrix/


Восстановление данных и возобновление работы с использованием SMO

SnapManager for Oracle восстанавливает базу данных в состояние, соответствующее моменту

взятия с нее снэпшота. Так как процесс восстановления данных (restore) не перемещает данные,

время восстановления данных занимает всего несколько секунд, независимо от размера базы

данных. Время восстановления в этом случае значительно меньше, чем при традиционном

способе восстановления из обычной копии. Так как резервная копия в снэпшотах может делаться

гораздо чаще, также значительно уменьшается объем логов, которые следует применить на

восстановленную из резервной копии базу для возобновления ее работы (recovery), что ведет к

значительному сокращению длительности MTTR (Mean Time To Recovery, времени до

восстановления работоспособности) для базы данных.

SnapManager также интегрирован с Oracle RMAN. Таким образом, администраторы базы данных

могут использовать RMAN для восстановления данных (restore) и возобновления работы (recover)

базы данных, с гранулярностью, равной отдельному дисковому блоку. Эта интеграция

обеспечивает одновременные преимущества, как по скорости, так и по эффективности со стороны

снэпшотов NetApp, с достоинствами тонкого управления процессом восстановления со стороны

Oracle RMAN.

SnapManager for Oracle обеспечивает эти возможности и для базы, размещенной на ASM, работая

над разработкой данного решения вместе с Oracle. Эти возможности позволяют быстро и

эффективно восстанавливать базы на ASM. В варианте с использованием ASM, дисковая группа

ASM может быть совместно использована несколькими базами данных. В результате вы не

можете просто вернуть данные из снэпшота на дисковую группу, так как это повлияет на все базы,

использующие ее. Традиционное решение восстановления идет через хост-сервер, и может

потребовать, чтобы все блоки, составляющие базу данных, были перемещены на хост-систему и

затем возвращены обратно на систему хранения. Уникальность решения, предлагаемого в

SnapManager from Oracle, состоит в устранении этого оверхеда.

SnapManager обеспечивает возможность восстановить только необходимые данные на дисковой

группе ASM, без использования перемещения данных через хост, как это используется в

большинстве традиционных сценариев.

SnapManager обеспечивает восстановление данных и возобновления работы базы данных как для

автономной базы Oracle Databases, так и в конфигурации RAC. Узел RAC, на котором

восстанавливаются данные с помощью SnapManager, может быть иным узлом, чем тот, на

котором эти данные сохранялись в резервную копию.

SMO Cloning

Уникальная возможность SnapManager for Oracle это возможность автоматизировать

клонирование баз Oracle Databases. Используя технологию NetApp FlexClone, SnapManager создает

клоны данных с возможностью в них записи, из снэпшотов, созданных в ходе резервного

копирования. Клоны баз данных создаются быстро, и занимают места на диске при этом только в

объеме записанных в них измененных блоков, по сравнению с источником клона. Так как клон

основан на снэпшоте, изменения в клоне никак не влияют на данные в базе-источнике, с которого

был сделан клон. В результате, каждому разработчику или специалисту контроля качества (QA)

может быть выделена его собственная копия базы данных. Инженеры-разработчики и

специалисты отдела контроля качества могут выполнять изменения в их собственных

индивидуальных копиях баз, и даже если они их, в результате своей работы, испортят, или даже

уничтожат, это не повлияет на работу их коллег и работу собственно рабочей базы, исходной для

создания клонов.

SnapManager обеспечивает возможности клонирования для всех возможных конфигураций Oracle

Database. Это включает в себя базы standalone и RAC. Обе эти конфигурации могут использовать

или не использовать ASM для управления хранилищем базы.

5.2 Жизненный цикл данных: Архивация и долговременное хранение

Создание клонов данных для задач тестирования и разработки

Разработка коммерческих приложений или внутренняя разработка, всегда ставят большую задачу

быстрого создания среды, которая позволила бы группам разработчиков и контроля качества (QA)

приступить к работе. Некоторые из основных проблем перечислены здесь:

• Улучшить возможности репликации данных

• Улучшить производительность труда разработчиков

• Обеспечить следование планам по выводу продукта на рынок

• Снизить потребности в новом хранилище, или расширении емкости имеющегося

• Автоматизировать создание среды разработчика и QA

При значительном числе разработчиков, базы для тестирования и подготовки к «выкатке»

(staging) непрерывно растут. Необходимость быть уверенным в том, что каждая из таких систем

правильно установлена и соответствующим образом настроена, и это становится заметной

проблемой. У разработчиков также часто нет возможности сохранять состояния конфигураций

перед изменениями, чтобы иметь возможность возвращаться к ним при необходимости. Если

разработчику требуется обновление его рабочей среды, то требуется процедура копирования

данных, которая может занимать значительное время и задерживает процессы разработки.

NetApp предлагает использовать концепцию так называемых aggregates и томов типа flexible

volumes (FlexVol) и flexible clones (FlexClone), представленных в Data ONTAP 7G. Они позволяют

использовать thin provisioning и произвольное изменение размеров томов «на лету». FlexVol и

FlexClone находятся поверх структуры aggregate, которая состоит из большого числа физических

дисков, сгруппированных в RAID, с использованием собственной реализации RAID с двойной

четностью, RAID-DP. RAID-DP это эффективное решение защиты данных от выхода из строя дисков

или их сбоя. Оно может защитить целостность и доступность данных, даже при выходе из строя

двух дисков в одной группе разом. Тома FlexClone делаются с использованием технологии NetApp

Snapshot, что позволяет создавать их практически мгновенно.

Разработчики могут использовать NetApp FlexClone для создания рабочих копий модифицируемых

баз данных Oracle Database 11g. Эти клонированные копии практически не будут занимать

дополнительного места. Технология NetApp Snapshot позволяет разработчикам и тестировщикам

создавать мгновенные копии данных и восстанавливаться из них при необходимости. Простота

создания среды для разработки и тестирования, в особенности с использованием средств

FlexClone, неизмеримо превосходит традиционный способ с копированием или использованием

RMAN. Использование технологий FlexClone освобождает время разработчиков, улучшает их

производительность. С использованием традиционных методов, разработчики вынуждены

ожидать окончания полной процедуры восстановления данных часами, а в некоторых случаях и

днями, прежде чем используемая ими система окажется готовой к работе. Но, в случае

использования NetApp FlexClone, можно создать клон системы за минуты, так как FlexClone не

производит физического копирования данных, и процесс может быть выполнен фактически

моментально.

Создание снэпшотов и томов FlexClone

Эта глава описывает то, как создавать снэпшот тома, создавать том FlexClone, и начать

использовать клон базы Oracle Database 11g на отдельном хосте.

Перед тем как создать снэпшот любого тома с базой Oracle Database 11g, первым делом

переведите базу в состояние hot backup. Также выполните сброс дисковых буферов, например

командой sync на хосте под Linux, чтобы убедиться, что все содержимое дисковых кэшей

перенесено на диски.

В нашей установке мы будем использовать три тома: oradata, oralogs, и ora10g. Так как мы

будем создавать только клоны базы данных, мы будем создавать снэпшоты только файлов

данных, файлов control, и файлов online redo log, размещенных на томах oradata и oralogs.

Разрешите доступ по rsh и/или ssh между хост-сервером и системой хранения NetApp.

1. Для создания снэпшота с тома, выполните следующие команды:

rsh <storage-name> “snap create <volume-name> <snap-name>;”

rsh Storage “snap create oradata oradata_snap1;”

rsh Storage “snap create oralogs oralogs_snap1;”

Вы можете убедиться в том, что снэпшот успешно создан, следующей командой:

rsh Storage “snap list oradata” Volume oradata

working...

%/used %/total date name

---------- ---------- ------------ ------------

0% ( 0%) 0% ( 0%) Jul 16 17:10 oradata_snap1

rsh Storage “snap list oralogs”

Volume oralogs

working...

%/used %/total date name

---------- ---------- ------------ ------------

0% ( 0%) 0% ( 0%) Jul 16 17:12 oralogs_snap1

2. После создания снэпшота, переведите базу из hot backup в нормальный режим.

Перед созданием тома FlexClone, проверьте размер aggregate, на котором размещен

«родительский» для клона том:

rsh Storage “ df –Ag aggr1;”

Aggregate total used avail capacity

aggr1 109GB 44GB 65GB 41%

aggr1/.snapshot 5GB 0GB 5GB 0%

3. Для создания тома FlexClone, используйте команды:

rsh <storage-name> “ vol clone create <clone-volume-name> -s none –b <parent- vol-

name> <parent-snap-name>

rsh Storage “ vol clone create oradata_clone –s none –b oradata oradata_snap1;”

rsh Storage “ vol clone create oralogs_clone –s none –b oralogs oralogs_snap1;”

Во время исполнения команды vol clone, Data ONTAP выводит уведомление «Reverting volume

vol-name to a previous snapshot». Для не знакомых с ONTAP: это стандартное сообщение системы,

когда из снэпшота восстанавливается состояние тома целиком. Так как тома FlexClone используют

технологию NetApp Snapshot для создания мгновенного образа исходного, «родительского» тома

FlexVol, используется тот же механизм. Том, о котором говорится в системном сообщении,

приведенном выше, это создаваемый том FlexClone. Хотя слово «revert» в сообщении

предполагает возврат на некую «предшествующую версию», на самом деле никакого «возврата»

не происходит, так как том оказывается только что созданным.

4. Проверьте статус тома FlexClone с помощью команды:

rsh Storage “vol status oradata_clone;”

rsh Storage “vol status oralogs_clone;”

5. Проверьте место на aggregate, после создания клона:

rsh Storage “ df –Ag aggr1;”

Aggregate Total used avail capacity

aggr1 109GB 44GB 65GB 41%

aggr1/.snapshot 5GB 0GB 5GB 0%

Заметьте, что объем пространства, использованного на aggregate, не увеличился. Это так потому,

что резервирование пространства параметром space reservations по умолчанию для томов

FlexClone выключена.

Созданный том-клон имеет ту же структуру директориев, что и «родительский» том.

Убедитесь, что подключаемый хост подключен к той же системе хранения NetApp, и выполнил все

действия, предшествующие инсталляции на этом хосте клона базы Oracle Database 11g.

Смонтируйте том FlexClone по NFS. Убедитесь, что локальная точка монтирования та же, что и у

хоста, монтировавшего оригинальный том базы Oracle Database 11g.

Скопируйте файл init<sid>.ora и создайте директорию dump, в соответствующей папке, такой

же, как и у первичной базы RAC. Если мы будем создавать не-RAC клон базы из базы в RAC,

требуется создать новый control file. Также требуется удалить параметры, относящиеся к

кластерной базе из файла init<sid>.ora.

После запуска инстанса-клона в состоянии nomount, создайте новый control file, восстановите базу

данных и откройте ее.

Использование Oracle Real Application Testing с NetApp FlexClone

Обзор Oracle Real Application Testing

Перед тем, как будут сделаны изменения в системе, например аппаратные или программные

обновления, обычно выполняется интенсивное тестирование для валидации всех

запланированных изменений. Однако, несмотря на тестирование, новая система часто

испытывает неожиданные эффекты при выводе ее в рабочий процесс, так как тестирование не

всегда выполняется с использованием реальной нагрузки. Невозможность эмулировать

реалистичную нагрузку в ходе тестирования является одной из наибольших проблем при

валидации изменений в системе. Oracle Database 11g теперь имеет новое средство,

называющееся Database Replay, которое позволяет обеспечить реалистичное тестирование при

изменении в системе, воссоздавая рабочую нагрузку реальной системы на тестируемой

конфигурации. Используя Database Replay, вы можете записать рабочую нагрузку на реальной

рабочей системе, а затем воспроизвести ее на тестируемой, в точности воспроизведя все детали,

тайминги запросов, степень параллельности и характеристики транзакций оригинальной нагрузки.

Это позволяет пользователю подробно оценить влияние изменений, включая возможные

нежелательные эффекты, новые проблемные места или спланировать варианты обхода.

Обширные средства аналитики и отчетов помогают идентифицировать любые потенциальные

проблемы, такие как возникающие новые ошибки или изменения в производительности.

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

рабочей нагрузки или создания сценария, что ведет к значительному сокращению времени и

затрат на проведение тестирования. Кроме этого, когда Database Replay используется с NetApp

FlexClone, реалистичное тестирование сложных приложений, которое раньше, с использованием

имитатора нагрузки, занимало месяцы, теперь может быть выполнено за несколько дней. Это

позволяет провести быстрое тестирование изменений и реализовать их с высоким уровнем

безопасности и низким риском для рабочей системы.

Database Replay выполняет запись операций обращений от внешних клиентов на уровне базы

данных, и имеет незначительное влияние на производительность. Вы можете использовать

Database Replay для тестирования любых значительных изменений системы, включая:

• Обновление базы данных или операционной системы

• Конфигурационные изменения, такие как перевод автономной базы в Oracle RAC

• Изменения в системе хранения, сетевой конфигурации и интерконнектах

• Изменения OS или аппаратной части системы

Методы Oracle Real Application Testing

Процессы Database Replay

Ниже приведены основные шаги для выполнения Database Replay:

• Запись операций рабочей нагрузки

• Предварительная обработка

• Воспроизведение операций рабочей нагрузки

Запись операций рабочей нагрузки

Первый шаг это запись операций рабочей нагрузки для базы. Запись производится для всех

запросов, которые делают внешние клиенты к базам Oracle Database. Когда включена запись, все

клиентские запросы, направляемые к Oracle Database, отслеживаются и записываются в двоичный

файл. Этот файл называется capture file, и он размещается на файловой системе. Один или

несколько файлов capture могу быть перенесены на другую систему для дальнейшей работы, так

как являются платформонезависимыми. Кроме этого вы можете определить время начала записи

и ее длительность, а также указать размещение файлов capture.

Предварительная обработка

Когда рабочие операции базы были записаны, информация, собранная в capture files должна быть

обработана. Процесс обработки превращает записи в файлы с информацией для повторного

воспроизведения, со всеми необходимыми для воспроизведения метаданными. Эта операция

должна быть проделана с записанными данными, прежде чем они смогут быть воспроизведены.

После того, как записанные данные обработаны, они могут многократно воспроизводиться на

системе с той же версией Oracle Database. Обычно capture files копируются на другую систему для

необходимой предварительной обработки. Так как процесс обработки занимает

продолжительное время и загружает систему, рекомендуется, чтобы эта часть процесса была

выполнена на выделенной, например тестовой системе, где эта нагрузка будет впоследствии

воспроизведена.

Воспроизведение операций рабочей нагрузки

После того, как записанные запросы были обработаны, они могут быть воспроизведены на

тестовой системе. Во время этапа воспроизведения записи, Oracle Database выполняет

записанные ранее действия с сохранением временных интервалов, параллельности выполнения и

зависимостей транзакций на рабочей системе. Database Replay использует клиентскую программу,

под названием replay client для воссоздания всех клиентских запросов, записанных на первом

этапе.

В зависимости от записанной нагрузки, вам может потребоваться один или более

воспроизводящих клиентов, для правильного воспроизведения записи.

Необходимые условия для записи процесса рабочей нагрузки базы данных

Перед запуском процесса записи, вы должны иметь стратегию восстановления базы данных из

резервной копии на тестовой системе. Перед тем, как записанные операции начнут

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

состоянию системы, на которой была сделана запись. Для выполнения этого рекомендуется

использовать NetApp FlexClone.

1. Переведите базу данных в hot backup mode.

2. Создайте снэпшоты нужных томов.

3. Создайте том FlexClone из этого снэпшота.

4. Смонтируйте том FlexClone на тестовой системе.

5. Восстановите актуальность базы на томе FlexClone на тестовой системе.

Эти действия позволят вам воссоздать на тестовой системе базу в состоянии, соответствующем

состоянию базы на момент начала записи. Для того, как сделать снэпшот с базы, и последующий

клон его по технологии FlexClone, смотрите выше главы о создании снэпшотов и FlexClone.

Запись операций рабочей нагрузки с использованием API

A) Задайте директорию для записываемых файлов

Определите расположение и создайте объект директории в рабочей базе данных, куда будет

сохраняться записываемый трафик рабочей нагрузки. Перед запуском записи рабочей нагрузки

убедитесь, что директория пустая и имеет достаточно места для записи. Если в процессе записи

рабочей нагрузки на диске закончится место, то запись ее остановится. В случае использования

Oracle RAC, рассмотрите возможность использования совместно используемой файловой

системы. Альтернативно можно установить путь к директории записи отдельно на каждом

физическом инстансе, однако необходимо собрать все созданные в каждой из этих директорий

capture files вместе, перед запуском процесса первичной подготовительной обработки их.

SQL> create or replace directory CAPTURE_DIR as ‘/oradata/capture’;

B) Запустите запись

Важно использовать ясно определенную точку начала записи с тем, чтобы система, которая будет

воспроизводить записанную нагрузку, могла быть восстановлена в соответствующее состояние,

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

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

пользовательских сессий. Если активные пользовательские сессии выполняют какие-либо

транзакции, то эти транзакции не будут воспроизведены правильно при последующем

проигрывании записи нагрузки. Только транзакции, которые целиком начались и закончились в

период записи нагрузки, могут быть корректно воспроизведены.

Для начала процесса записи используйте процедуру START_CAPTURE:

BEGIN

DBMS_WORKLOAD_CAPTURE.START_CAPTURE (name => ’capture_1’, dir => ’CAPTURE_DIR’,

duration => 600);

END;

/

В данном примере рабочая нагрузка с именем capture_1 будет записана в течение 600 секунд и

сохранена в объекте директории базы данных под названием CAPTURE_DIR.

Процедура START_CAPTURE в приведенном примере использует следующие параметры:

• Необходимый параметр name определяет имя для записываемой рабочей нагрузки.

• Необходимый параметр dir определяет объект директории, в которой будет

записываться рабочая нагрузка.

• Опциональный параметр duration задает число секунд, в течение которых будет

собираться и записываться нагрузка. Если этот параметр не указан, то запись будет

производиться, пока не будет вызвана процедура FINISH_CAPTURE.

C) Остановите процесс записи

Для окончания процесса записи используйте процедуру FINISH_CAPTURE:

BEGIN

DBMS_WORKLOAD_CAPTURE.FINISH_CAPTURE (); END;

/

В данном примере, процедура FINISH_CAPTURE завершает процесс записи рабочей нагрузки и

возвращает базу данных в нормальное состояние.

D) Экспортируйте AWR Data для записанных данных

Экспорт AWR data позволяет провести детальный анализ рабочей нагрузки. Эти данные также

требуются, если планируется запустить AWR compare period report на паре рабочих нагрузок,

записанных или воспроизводящихся.

Для экспорта AWR data, используйте процедуру EXPORT_AWR:

BEGIN

DBMS_WORKLOAD_CAPTURE.EXPORT_AWR (capture_id => 2); END;

/

В данном примере, экспортируется снэпшот AWR, соответствующий записанным данным с capture

ID равным 2.

Обработка записанной рабочей нагрузки

После того, как рабочая нагрузка записана и установлена система, на которой будут проводиться

тесты, записанные данные необходимо обработать. Обработка преобразует записанную рабочую

нагрузку в файлы, пригодные для последующего воспроизведения, и создает все необходимые

метаданные. Это должно быть сделано для каждой записанной рабочей нагрузки, перед тем, как

она сможет быть воспроизведена на тестовой системе.

Для обработки записанной нагрузки вы должны, в первую очередь, переместить все файлы с

записанной рабочей нагрузкой из директории, в которой они записывались, на рабочей системе,

на систему, где будет проводиться их обработка. Обработка это достаточно нагружающий систему

процесс, и должен выполняться на системе, которая:

• Отделена от продакшн-системы

• Работает на той же версии Oracle Database, что и та система, что будет воспроизводить

нагрузку

Для Oracle RAC, для обработки выберите один инстанс базы данных на воспроизводящей системе.

Этот инстанс должен иметь доступ к файлам записанных данных, которые требуют обработки, и

могут быть сохранены на локальной или совместно используемой файловой системе. Если

директории для записываемых файлов располагаются локально в физических директориях

каждого инстанса, перед началом их обработки все файлы с записью рабочей нагрузки должны

быть собраны в одной директории.

Для обработки записанной рабочей нагрузки используйте процедуру PROCESS_CAPTURE:

BEGIN

DBMS_WORKLOAD_REPLAY.PROCESS_CAPTURE (capture_dir => ’CAPTURE_DIR’); END;

/

В этом примере будет обработана записанная рабочая нагрузка, сохраненная в директории

capture_dir. Процедура PROCESS_CAPTURE использует параметр capture_dir, в котором

определяется директория, содержащая данные для обработки.

Воспроизведение записанной рабочей нагрузки

Эта глава описывает то, как воспроизвести записанные с базой данных действия на тестируемой

системе. После того, как записанная рабочая нагрузка обработана, она может быть

воспроизведена на системе с той же версией Oracle Database, что и система, на которой была

сделана запись.

Эта глава содержит следующие темы:

• Установка тестируемой системы

• Шаги по воспроизведению записанной рабочей нагрузки

• Воспроизведение с использованием API

• Наблюдение за процессом воспроизведения нагрузки с помощью Views

A) Настройте тестовую систему

Обычно система, на которой воспроизводится записанная и обработанная рабочая нагрузка,

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

ранее и воспроизводимую рабочую нагрузку, следует ее подготовить так, как описано ниже:

• Восстановите состояние базы данных:

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

приложения должно быть логически эквивалентно состоянию данных на системе-источнике

записи, на момент начала записи. Это минимизирует расхождения в данных в ходе

воспроизведения. Оптимальным методом восстановления базы данных является

использование NetApp FlexClone, как это уже описывалось в [2] и [6]. После того, как база со

всеми необходимым для приложения содержимым будет создана на тестовой системе,

выполните те изменения, например обновление OS или оборудования, результаты которого

вы хотите проверить в ходе тестирования.

• Сбросьте системное время:

Рекомендуется изменить перед началом воспроизведения время на системе, которая

воспроизводит записанную нагрузку, на примерно соответствующее времени начала записи

на исходной системе. В противном случае, если воспроизводится запросы чувствительные ко

времени своего исполнения, можно получить неверное состояние данных.

B) Настройте клиентов воспроизведения

Программа replay client это многопоточное приложение (исполняемый файл называется wrc, и

расположен в директории $ORACLE_HOME/bin) где каждый отдельный поток (thread) исполняет

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

подключения всех клиентов. В этот момент вам нужно настроить и запустить клиентов

воспроизведения, которые затем подключатся к тестируемой системе, и начнут отсылать на нее

запросы, в соответствии с записанными ранее операциями.

Перед тем, как запустить клиентов воспроизведения, убедитесь в следующем:

• Клиенты воспроизведения установлены на хосты, на которых они будут работать

• Клиенты имеют доступ к директории с файлами воспроизведения

• Директория воспроизведения содержит обработанные файлы с записью данных рабочей

нагрузки

• Пользователи воспроизведения имеют правильный user ID, пароль и привилегии

(пользователь воспроизведения должен иметь роль DBA, но не SYS user)

Когда все необходимые предварительные требование выполнены, вы можете установить,

настроить и запустить клиенты воспроизведения wrc. Программа wrc использует следующий

командный синтаксис:

wrc [user/password[@server]] MODE=[value] [keyword=[value]]

Параметры user и password задают имя пользователя и пароль подключения к хосту, на котором

установлена программа wrc. Параметр server определяет имя/адрес сервера, на котором

установлена программа wrc. Параметр mode определяет режим, в котором запускается wrc, по

умолчанию это воспроизведение (replay).

Запуск воспроизводящих клиентов

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

и запустить их на нужных хостах с помощью программы wrc в проигрывающем режиме.

После запуска каждый клиент воспроизведения инициирует одну или более сессий с базой

данных, осуществляя воспроизведение записанной рабочей активности. В режиме

воспроизведения программа wrc принимает следующие параметры:

• userid и password задают user ID и пароль для пользователя, от имени которого

происходит воспроизведение. Если не определено, то по умолчанию используется system

user.

• server определяет строку соединения, используемую для подключения к

воспроизводящей системе. Если не определено, то по умолчанию значение строки пустое.

• replaydir определяет директорию, которая содержит обработанные файлы с записью

рабочей нагрузки, которые вы планируете воспроизвести. Если не определено, то по

умолчанию используется текущая директория.

Приведенный пример показывает, как запустить wrc в режиме воспроизведения:

%> wrc system/oracle@test mode=replay replaydir=./replay

В приведенном примере программа wrc запускает воспроизводящего клиента, выполняющего

«проигрывание» записи рабочей нагрузки, записанной в поддиректории с именем replay,

находящейся в текущей директории. После того, как все клиенты воспроизведения подключатся,

база данных автоматически распределяет потоки воспроизведения записанной нагрузки по всем

доступным для этого клиентам воспроизведения. На этом воспроизведение начинается. После

того, как воспроизведение завершено, все клиенты воспроизведения отключаются автоматически.

C) Запустите воспроизведение записанных данных с использованием API

Эта глава описывает то, как запустить воспроизведение записанной рабочей нагрузки с

использованием DBMS_WORKLOAD_REPLAY.

Воспроизведение записанной рабочей нагрузки с использованием DBMS_WORKLOAD_REPLAY это

процесс, который состоит из нескольких шагов:

• Инициализация воспроизводимых данных

• Переподключение соединений

• Установка опций воспроизведения

• Запуск процесса воспроизведения

• Остановка процесса воспроизведения

• Экспорт данных AWR для воспроизведения

Инициализация данных воспроизведения

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

данные воспроизведения должны быть проинициализированы. Инициализация загружает

необходимые метаданные в таблицы, необходимые для успешного воспроизведения записанной

рабочей нагрузки.

Для инициализации данных воспроизведения используйте процедуру INITIALIZE_REPLAY:

BEGIN

DBMS_WORKLOAD_REPLAY.INITIALIZE_REPLAY (replay_name => ’replay_1’, replay_dir =>

’REPLAY_DIR’);

END;

/

В приведенном примере, процедура INITIALIZE_REPLAY загружает обработанные данные

воспроизведения из директории REPLAY_DIR в базу данных. Процедура INITIALIZE_REPLAY в этом

примере использует следующее параметры:

• Необходимый параметр replay_name определяет имя для процесса воспроизведения,

используемое для извлечения соответствующих настроек и отделения от предшествующих

воспроизведений.

• Необходимый параметр replay_dir определяет директорию, где содержатся записанные

данные, которые будут воспроизводиться.

Переподключение соединений

После инициализации состояния воспроизводимых данных, строки подключения,

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

пользовательские сессии могли подключаться к соответствующим базам данных и соединяться

так, как это было записано при процессе записи. Для просмотра порядка подключения

воспользуйтесь видом DBA_WORKLOAD_CONNECTION_MAP.

Для переназначения соединений используйте процедуру REMAP_CONNECTION:

BEGIN

DBMS_WORKLOAD_REPLAY.REMAP_CONNECTION (connection_id => 101, replay_connection =>

’test:3434/bweb21’);

END;

/

В приведенном примере, соединение, соответствующее connection ID 101, будет использовать

новую строку соединения, определенную в параметре replay_connection. Процедура

REMAP_CONNECTION в данном примере, использует следующие параметры:

• Необходимый параметр connection_id генерируется, когда инициализируются данные для

воспроизведения, и соответствует соединению из записанного потока.

• Опциональный параметр replay_connection определяет новую строку соединения, которая

будет использована во время воспроизведения потока.

Установка опций воспроизведения

После того, как данные воспроизведения инициализированы, и соединения правильным образом

переназначены, подготовьте базу данных к воспроизведению на нее записанной нагрузки.

Для подготовки процесса воспроизведения записанной рабочей нагрузки на целевой системе,

используйте процедуру PREPARE_REPLAY:

BEGIN

DBMS_WORKLOAD_REPLAY.PREPARE_REPLAY (synchronization => TRUE); END;

/

В приведенном примере, процедура PREPARE_REPLAY подготавливает процесс воспроизведения,

который был ранее инициализирован. Порядок операций COMMIT в записанных операциях

сохраняется. Процедура PREPARE_REPLAY использует следующие параметры:

• Необходимый параметр synchronization требуется, если при воспроизведении

используется синхронизация действий. Если это параметр установлен в TRUE, то порядок

операций COMMIT в записанной последовательности операций сохраняется при

воспроизведении, и все операции воспроизведения выполняются только после всех

связанных и взаимозависимых операций COMMIT. Значение по умолчанию равно TRUE.

Запуск воспроизведения записанных данных

Для запуска воспроизведения, используйте процедуру START_REPLAY:

BEGIN DBMS_WORKLOAD_REPLAY.START_REPLAY (); END;

/

Остановка воспроизведения

Для остановки воспроизведения, используйте процедуру CANCEL_REPLAY:

BEGIN DBMS_WORKLOAD_REPLAY.CANCEL_REPLAY (); END;

/

Экспорт AWR Data для воспроизведения

Экспорт данных AWR позволяет детальный анализ рабочей нагрузки. Эти данные также

необходимы, если вы планируете запускать AWR compare period report на паре сравниваемых

записей рабочих нагрузок.

Для экспорта AWR data, используйте процедуру EXPORT_AWR:

BEGIN

DBMS_WORKLOAD_REPLAY.EXPORT_AWR (replay_id => 1); END;

/

В данном примере экспортируется снэпшот AWR, соответствующий воспроизводимой нагрузке с

именем replay ID равным 1.

Мониторинг воспроизведенной нагрузки с помощью Views

Эта глава рассматривает способы наблюдения за воспроизводимой нагрузкой. Вам будут

необходимы привилегии DBA для доступа к данным views.

• View DBA_WORKLOAD_CAPTURES показывает список всех записанных рабочих нагрузок для

текущей базы данных.

• View DBA_WORKLOAD_FILTERS показывает все фильтры, как для записей рабочих нагрузок, так

и для их воспроизведений, определенных для текущей базы данных.

• View DBA_WORKLOAD_REPLAYS показывает список всех воспроизводимых нагрузок, которые

могут быть проиграны для текущей базы данных.

• View DBA_WORKLOAD_REPLAY_DIVERGENCE позволяет вам наблюдать за расхождением

(divergence) воспроизведения рабочей нагрузки.

Безопасность Oracle Database 11g

Сильная парольная защита

Эта возможность модифицирует верификатор, или хэш, используемый для хранения паролей

Oracle. Она позволяет усилить защиту для хранимых паролей базы данных, основанную на

стандартных алгоритмах, обеспечивает улучшенную безопасность для использующих пароли

аутентификаций, позволяя пароли со смешанными регистрами символов. Для обеспечения

безопасности, в Oracle Database 11g добавлен новый инициализационный параметр.

SEC_CASE_SENSITIVE_LOGON controls the case sensitivity in passwords.

TRUE включает чувствительность к регистру символов. FALSE отключает ее.

Привилегия SYSASM для ASM

Привилегия SYSASM позволяет отделить учетные данные OS и базы данных от учетных данных

ASM. Используйте привилегии SYSASM вместо SYSDBA для подключения и администрирования

инстанса ASM. Если вы используете привилегии SYSDBA для подключения к инстансу ASM, тогда

Oracle выведет предупреждение в лог сообщений, так как команды, выполняемые с привилегией

SYSDBA в инстансе ASM, вскоре будут считаться устаревшими. Привилегия SYSASM действует для

всех платформ.

Однако аутентификации в операционных системах отличаются между собой:

• На системах UNIX и Linux, аутентификация зависит от членства в группе или привилегии

операционной системы. Другими словами, вы должны быть в группе DBA для подключения

как SYSASM или SYSDBA.

• В системе Windows, Oracle выполняется под local system user или administrator. Вы можете

подключиться как SYSASM, SYSDBA, или SYSOPER, если вы используете учетные данные local

system или administrator.

Вы можете использовать следующие типы подключения:

• CONNECT ... AS SYSASM to an ASM instance

Подключение как SYSASM дает вам полный доступ ко всем доступным дисковым группам ASM

целиком.

SQLPLUS sys/sys_password AS SYSASM

• CONNECT ... AS SYSDBA to an ASM instance

Oracle запишет предупреждение в файл логов, если вы будете использовать операторы CREATE,

ALTER, или DROP DISKGROUP, которые теперь должны исполняться от имени SYSASM.

Шифрование табличного пространства

Tablespace encryption это расширение решения Oracle Advanced Security Transparent Data

Encryption. Используя функцию tablespace encryption, пользователи могут шифровать табличное

пространство, шифруя все данные внутри этого табличного пространства. Когда база данных

обращается к данному табличному пространству, необходимый блок данных прозрачно

расшифровывается и передается приложению. Прозрачное шифрование табличного пространства

(Transparent Data Encryption tablespace encryption) обеспечивает альтернативу для прозрачного

шифрования колонок табличного пространства (Transparent Data Encryption column encryption),

обеспечивая шифрование всего табличного пространства целиком. Это устраняет необходимость

анализа гранулярности приложения, чтобы определить то, какие колонки следует шифровать, что

особенно важно для приложений с большими объемами сложных баз данных, содержащих

информацию типа personally identifiable information (PII). Пользователи, имеющие сравнительно

небольшие объемы подлежащей шифрованию информации, могут продолжать пользоваться

вариантом Transparent Data Encryption column encryption.

Для использования шифрования табличного пространства, вам необходимо использовать Oracle

Database 11g. Если вы обновились с предыдущего релиза, уровень совместимости базы должен

быть установлен на 11.0.0 или новее.

Для включения шифрования табличного пространства:

1. Установите tablespace master encryption key.

2. Откройте Oracle wallet.

3. Создайте зашифрованное табличное пространство.

Установка Tablespace Master Encryption Key

Установка tablespace master encryption key это одноразовое действие. При этом создается мастер-

ключ шифрования для процесса шифрования табличного пространства. Этот ключ хранится во

внешнем модуле, под названием Oracle wallet, и используется для зашифровывания ключей

шифрования табличного пространства.

Шифрование табличного пространства использует тот же модуль wallet, что используется при

column-based transparent data encryption для хранения его master encryption key. Проверьте, что

параметр ENCRYPTION_WALLET_LOCATION (или WALLET_LOCATION) в файле sqlnet.ora указывает на

правильное его расположение. Например, запись в файл sqlnet.ora может выглядеть так:

ENCRYPTION_WALLET_LOCATION = (SOURCE =

(METHO = FILE)

(METHOD_DATA =

(DIRECTORY = /orahome/product/11g/db/wallet)))

Когда кто-то создает мастер-ключ прозрачного шифрования, создается и мастер-ключ

шифрования табличного пространства.

Для установки мастер-ключа, используйте следующую команду:

SQL> ALTER SYSTEM SET ENCRYPTION KEY IDENTIFIED BY password

Где:

Password это необходимый параметр, содержащий пароль для модуля wallet, значение по

умолчанию отсутствует. Пароль чувствителен к регистру символов. Заключите сроку пароля при

вводе в символы кавычек (" ").

Когда кто-то выполняет команду ALTER SYSTEM SET ENCRYPTION KEY, пересоздается мастер-ключ

прозрачного шифрования, если такой уже имелся, и создается новый мастер-ключ для

шифрования табличного пространства. Если tablespace master encryption key уже существует, то

новый ключ не создается.

Открытие Oracle Wallet

Перед тем, как создать зашифрованное табличное пространство, необходимо открыть Oracle

wallet, содержащий tablespace master encryption key. Oracle wallet также должен быть открыт

перед доступом к данным на зашифрованном табличном пространстве.

SQL> STARTUP MOUNT;

SQL> ALTER SYSTEM SET ENCRYPTION KEY IDENTIFIED BY password;

SQL> ALTER DATABASE OPEN;

Создание шифрованного табличного пространства

Команда CREATE TABLESPACE позволяет создать вам зашифрованное табличное пространство.

При этом выбирается алгоритм шифрования и длина ключа. Ключевое слово ENCRYPT в

storage_clause задает шифрование табличного пространства. Например:

CREATE TABLESPACE securespace

DATAFILE '/home/user/oradata/secure01.dbf' SIZE 150M

ENCRYPTION USING '3DES168'

DEFAULT STORAGE (ENCRYPT);

Алгоритм выбирается одним из следующих значений:

3DES16 AES128 AES192 AES256

Длина ключа включена в имя выбираемого алгоритма. Если алгоритм не определен, то

используется алгоритм по умолчанию – AES128.

Посмотреть текущий статус зашифрованности табличного пространства можно с помощью data

dictionary views. Вы можете выполнить следующие запросы для проверки состояния

зашифрованности табличного пространства:

DBA_TABLESPACES: Колонка ENCRYPTED показывает, какие табличные пространства зашифрованы.

USER_TABLESPACES: Колонка ENCRYPTED показывает, какие табличные пространства зашифрованы.

5.3 Высокая доступность

Отказоустойчивая конфигурация

Oracle Data Guard и Snapshot Standby Database

Oracle Data Guard обеспечивает высокую доступность, защиту данных и катастрофоустойчивость

критичных для компании данных.

Data Guard обеспечивает исчерпывающий набор сервисов для создания, обслуживания,

управления и мониторинга одной или нескольких автономных (standby) баз, что позволяет

обеспечить рабочей базе данных устойчивость от катастрофических отказов и повреждений

данных. Data Guard обслуживает эти standby-базы, как копии рабочей базы. Далее, если рабочая

база становится недоступна, по причине планового или непланового сбоя, Data Guard может

переключить одну из standby-баз в режим рабочей базы, минимизируя простой и недоступность,

вызванные отказом. Data Guard моет быть использован с традиционным процессом резервного

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

защиты данных и их доступности. Существуют три типа Data Guard в Oracle Database 11g:

Physical Standby Database

Эта база обеспечивает физически-идентичную копию рабочей базы, с находящимися на дисках

данными, идентичными основной, рабочей базе на блочном уровне. Содержимое database

schema, включая индексы, идентично. База типа physical standby database сохраняет синхронность

с рабочей базой, используя Redo Apply, при котором извлекаются redo data с основной базы, и

применяются на содержимое базы physical standby database.

В Oracle Database 11g база данных типа physical standby database может получать и применять

данные redo log одновременно с возможностью доступа к ней на чтение (read-only). База данных

типа physical standby database может использоваться параллельно для защиты данных и создания

отчетов.

Описанные ниже шаги показывают, как сконфигурировать базу данных типа physical standby

database с использованием системы хранения NetApp и некоторых ее возможностей.

Шаг 1: Переведите рабочую базу после создания в состояние FORCE LOGGING с помощью

следующей операции SQL от имени sys user:

SQL> ALTER DATABASE FORCE LOGGING;

Шаг 2: Создайте файл инициализационных параметров, используя серверный файл параметров

базы данных:

SQL> create pfile from spfile.

Внимание: По умолчанию вы создадите pfile в директории $ORACLE_HOME/dbs.

Шаг 3: Добавьте в файл инициализационных параметров следующее содержимое.

DB_UNIQUE_NAME=orcl LOG_ARCHIVE_CONFIG='DG_CONFIG=(orcl,orcl1)'

LOG_ARCHIVE_DEST_1='LOCATION=/oradata/arch VALID_FOR=(ALL_LOGFILES,ALL_ROLES)

DB_UNIQUE_NAME=orcl'

LOG_ARCHIVE_DEST_2='SERVICE=orcl1 ASYNC VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE)

DB_UNIQUE_NAME=orcl1' LOG_ARCHIVE_DEST_STATE_1=ENABLE LOG_ARCHIVE_DEST_STATE_2=DEFER

REMOTE_LOGIN_PASSWORDFILE=EXCLUSIVE LOG_ARCHIVE_FORMAT=%t_%s_%r.arc

LOG_ARCHIVE_MAX_PROCESSES=10

Внимание: orcl и orcl1 это имена баз рабочей и standby, соответственно.

Шаг 4: Создайте файл паролей, как приведено ниже, как на стороне рабочей базы, так и standby.

На стороне рабочей базы:

$ orapwd file=orapworcl password=oracle ignorecase=Y entries=15

На стороне Standby Node

$ orapwd file=orapworcl1 password=oracle ignorecase=Y entries=15

Шаг 5: Создайте listener и файлы tnsnames на рабочей и на standby-стороне.

Внимание: Убедитесь, что tnsping правильно работает на обоих узлах.

Шаг 6: Включите archive log на основной, рабочей базе данных.

Шаг 7: Остановите основную базу, и создайте Snapshot-копию тома (использованного для

хранения файлов данных, файлов control, redo log, и archive log). Создайте том FlexClone на

системе хранения и смонтируйте его на стороне standby следующим образом, запустив данные

команды на стороне основной, рабочей базы:

$ rsh 10.73.69.110 snap create oradata backup

$ rsh 10.73.69.110 vol clone create oradata_clone -b oradata backup –s none

$ rsh 10.73.69.110 exportfs -p rw,anon=0 /vol/oradata_clone

$ rsh 10.73.69.110 exportfs –a

Внимание: 10.73.69.110 это IP-адрес системы хранения NetApp, используемой в примере;

oradata, oradata_clone это тома, используемые для хранения основной базы данных, и ее standby-

клона, соответственно.

Шаг 8: Запустите основную базу в mount mode с использованием файла инициализационных

параметров, и сделайте резервную копию файла control, затем откройте базу данных следующей

командой.

SQL> startup mount;

SQL> ALTER DATABASE CREATE STANDBY CONTROLFILE AS '/tmp/orcl1.ctl';

SQL> Alter database open;

Шаг 9: Скопируйте файл инициализационных параметров основной базы в $ORACLE_HOME/dbs на

стороне standby-базы, и измените его как показано ниже:

DB_UNIQUE_NAME=orcl1

LOG_ARCHIVE_CONFIG='DG_CONFIG=(orcl,orcl1)'

LOG_ARCHIVE_DEST_1='LOCATION=/oradata/arch1

VALID_FOR=(ALL_LOGFILES,ALL_ROLES) DB_UNIQUE_NAME=orcl1'

LOG_ARCHIVE_DEST_2='SERVICE=orcl ASYNC

VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=orcl'

LOG_ARCHIVE_DEST_STATE_1=ENABLE

LOG_ARCHIVE_DEST_STATE_2=DEFER REMOTE_LOGIN_PASSWORDFILE=EXCLUSIVE

LOG_ARCHIVE_FORMAT=%t_%s_%r.arc

LOG_ARCHIVE_MAX_PROCESSES=10

Переименуйте файл параметров в initorcl1.ora, вместо initorcl.ora.

Шаг 10: Смонтируйте том oradata_clone с соответствующими опциям монтирования на стороне

standby. Скопируйте файл control с узла основной базы на узел standby.

Переименуйте скопированный файл control для правильного расположения (как определено в

файле инициализационных параметров) базы standby. Создайте директорию arch1 в директории

oradata базы standby. Затем выполните монтирование на стороне standby.

SQL> startup mount;

Шаг 11: Создайте файл standby redo log для базы standby с помощью следующей команды.

SQL> alter database add standby logfile '/oradata/orcl/sredo1.log' size 50M;



Шаг 12: Создайте файл параметров сервера, используя файл инициализационных параметров на

обеих сторонах, как основного, так и standby-узла:

SQL> create spfile from pfile;

Шаг 13: В базе standby выполните следующие команды для запуска Redo Apply:

SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE DISCONNECT

FROM SESSION;

Шаг 14: Проверьте, что база physical standby database работает правильно.

1. В базе standby выполните запрос к V$ARCHIVED_LOG view для идентификации

существования файлов в archived redo log.

Например:

SQL > SELECT SEQUENCE#, FIRST_TIME, NEXT_TIME FROM V$ARCHIVED_LOG ORDER BY SEQUENCE#

SEQUENCE# FIRST_TIME NEXT_TIME

---------- ------------------ ------------------

8 11-JUL-07 17:50:45 11-JUL-07 17:50:53

9 11-JUL-07 17:50:53 11-JUL-07 17:50:58

10 11-JUL-07 17:50:58 11-JUL-07 17:51:03

3 rows selected.

2. Инициируйте переключение логов (log switch) для архивирования текущего файла online

redo log у рабочей базы данных

SQL> ALTER SYSTEM SWITCH LOGFILE;

3. Проверьте, что новые данные redo были сархивированы в базу standby database.

SQL> SELECT SEQUENCE#, FIRST_TIME, NEXT_TIME FROM V$ARCHIVED_LOG ORDER BY SEQUENCE#;

SEQUENCE# FIRST_TIME NEXT_TIME

---------- ------------------ ------------------

8 11-JUL-07 17:50:45 11-JUL-07 17:50:53

9 11-JUL-07 17:50:53 11-JUL-07 17:50:58

10 11-JUL-07 17:50:58 11-JUL-07 17:51:03

11 11-JUL-07 17:51:03 11-JUL-07 18:34:11

4 rows selected.

4. Убедитесь, что новые файлы archived redo log применены на базу standby database.

SQL > SELECT SEQUENCE#,APPLIED FROM V$ARCHIVED_LOG ORDER BY SEQUENCE#;

SEQUENCE# APP

--------- ---

8 YES

9 YES

10 YES

11 YES

4 rows selected.

Конвертирование базы Physical Standby Database в Snapshot Standby Database

Остановите процесс Redo Apply на physical standby database как указано ниже:

SQL > ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;

SQL > ALTER DATABASE CONVERT TO SNAPSHOT STANDBY;

Logical Standby Database

База типа logical standby database сохраняет синхронность состояния с основной базой при

помощи SQL

Преобразования данных из redo получаются с основной базы в виде команд SQL, и затем

полученные команды на языке SQL выполняются на standby-базе данных. Вариант logical standby

database может быть использован для различных иных бизнес-применений, кроме как для задач

построения катастрофоустойчивого решения. Он позволяет пользователям иметь доступ к

standby-базе для выполнения запросов и генерации отчетов. Кроме того, используя logical standby

database, вы можете обновлять ПО Oracle Database и применять патчи, без возникновения

простоя. Таким образом, logical standby database может использоваться параллельно для задач

защиты данных, создания отчетов, и обновления базы.

Описанные ниже шаги описывают то, как сконфигурировать logical standby database с

использованием системы хранения NetApp.

Шаг 1: Подготовьте physical standby database как описано выше.

Шаг 2: Остановите Redo Apply на physical standby database:

SQL > ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;

Шаг 3: Выполните следующие команды на основной базе:

SQL > alter system set LOG_ARCHIVE_DEST_1='LOCATION=/oradata/arch

VALID_FOR=(ONLINE_LOGFILES,ALL_ROLES) DB_UNIQUE_NAME=orcl' scope=both;

SQL > alter system set LOG_ARCHIVE_DEST_3='LOCATION=/oradata/arch2

VALID_FOR=(STANDBY_LOGFILES,STANDBY_ROLE) DB_UNIQUE_NAME=orcl' scope=both;

SQL > alter system set LOG_ARCHIVE_DEST_STATE_3=ENABLE scope=both;

Шаг 4: Постройте словарь (dictionary) в данных redo на основной базе.

SQL > EXECUTE DBMS_LOGSTDBY.BUILD;

Шаг 5: Запустите следующую команду для конвертации в logical standby database на узле standby:

SQL > ALTER DATABASE RECOVER TO LOGICAL STANDBY orcl1;

Шаг 6: Измените инициализационные параметры logical standby на стороне standby как показано:

SQL> shutdown

SQL> startup mount

SQL> alter system set LOG_ARCHIVE_DEST_1='LOCATION=/oradata/arch1/

VALID_FOR=(ONLINE_LOGFILES,ALL_ROLES) DB_UNIQUE_NAME=orcl1' scope=both;

SQL> alter system set LOG_ARCHIVE_DEST_2='SERVICE=chicago ASYNC

VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=orcl' scope=both;

SQL> alter system set LOG_ARCHIVE_DEST_3='LOCATION=/oradata/arch3/

VALID_FOR=(STANDBY_LOGFILES,STANDBY_ROLE) DB_UNIQUE_NAME=orcl1' scope=both;

SQL> alter system set LOG_ARCHIVE_DEST_STATE_1=ENABLE scope=both;



Шаг 7: Запустите следующие команды для открытия logical standby database на стороне standby:

SQL> ALTER DATABASE OPEN RESETLOGS;

Шаг 8: Для применения данных redo к logical standby database, введите следующие команды:

SQL> ALTER DATABASE START LOGICAL STANDBY APPLY IMMEDIATE;

SnapMirror

Существует множество способов увеличить доступность данных в случае сбоев оборудования,

программного обеспечения, или даже недоступности сайта размещения целиком.

Зеркалирование данных предоставляет механизм обеспечения доступности данных и

минимизации времени простоя.

SnapMirror выполняет зеркалирование (репликацию) данных тома на блочном уровне, и

позволяет передавать данные на систему-получатель синхронно или асинхронно, наилучшим

образом соответствуя требованиям доступности, предъявляемой к вашей системе, и обеспечивая

быстрое и гибкое решение для репликации данных между локальными сайтами, по глобальной

сети, или с помощью Fibre Channel (FC). SnapMirror может быть ключевым компонентом

реализации стратегии защиты данных в компании. Если вы столкнулись с воздействием

катастрофических по масштабу событий, бизнес может получить доступ к критически важным

данным с резервного сайта-«зеркальной копии» на системе хранения NetApp, что обеспечит

непрерывную доступность данных.

NetApp SnapMirror может быть оптимальным выбором для решения катастрофоусточивой

системы, использующей Oracle Database. Такая система предоставит надежное, устойчивое к

сбоям и катастрофам хранилище данных, и позволит осуществить непрерывность бизнеса и

доступность его данных.

Установка отношений репликации SnapMirror

Для работы SnapMirror необходимо задать том-источник данных на основном сайте и том-

получатель данных репликации на удаленном сайте. Том-получатель должен быть больше или

равен по размеру тому-источнику.

На контроллере, обслуживающем том-источник, используйте опцию snapmirror.access для

задания имени хоста системы-получателя, которой разрешено копировать данные с системы-

источника.

Пример: options snapmirror.access host=<destination storage system>

Том-получатель данных должен находиться в состоянии restricted , это позволяет SnapMirror

получить к нему доступ. Команда vol restrict переводит том в это состояние.

Пример: vol restrict <vol_name>

Внимание: Команда snapmirror status показывает состояние операций SnapMirror для

заданных томов.

Snapmirror.conf

Файл snapmirror.conf это основной конфигурационный файл для всех режимов и операций

SnapMirror. Он расположен в /etc/snapmirror.conf и определяет пары репликаций от источника

к получателю (source/destination), расписание работы и опции управления SnapMirror. Файл

располагается на системе-получателе репликации.

Внимание: Существует ограничение в 1024 записей в файле /etc/snapmirror.conf для каждой

индивидуальной системы хранения. На HA-кластере хранения, данный лимит распространяется на

кластерную пару. SnapMirror обеспечивает три типа репликации:

• Синхронный

• Полусинхронный

• Асинхронный

Для настройки репликации и пар реплицируемых ресурсов используется файл

/etc/snapmirror.conf , в котором задаются режимы работы и расписание выполнения

асинхронной репликации, например:

Для конфигурирования Synchronous SnapMirror между двумя томами:

Отредактируйте файл /etc/snapmirror.conf и запишите в него:

<src_storage>:<src_vol> <dest_storage>:<dest_vol> - sync

В примере выше том <Source_Vol> на <Source_Storage> должен реплицироваться в <Dest_Vol>

на <Dest_Storage> синхронно.

Для конфигурирования асинхронного SnapMirror по расписанию:

Отредактируйте файл /etc/snapmirror.conf запишите в него:

<src_storage>:<vol_name> <dest_storage>:<vol_name> - <Minute> <Hour> <week of the

month> <day of the week>

Например: <src_storage>:<vol_name> <dest_storage>:<vol_name> - 0-59/30 * * *

Пример выше устанавливает репликацию тома <vol_name> на <src_storage> на <vol_name> на

<dest storage> каждые 30 минут, каждого часа, каждую неделю месяца и каждый день недели.

Внимание: Для томов, которые синхронно реплицируются с помощью SnapMirror, требуется

иметь размер реплицируемого тома не менее чем 10GB.

Для того, чтобы сконфигурировать полусинхронный режим (semi-synchronous) в SnapMirror

между двумя томами:

Полусинхронный режим обеспечивает синхронизацию, при которой источник и получатель

репликации синхронизированы более точно, чем при использовании асинхронного режима, но

оказывают меньшее влияние на производительность работы приложений, чем синхронный

режим. Конфигурация полусинхронного режима идентична конфигурации для синхронного

режима, но с добавлением опции, указывающей на то, какой интервал непереданных операций

максимально допустим между источником и получателем (непереданных на систему-получатель),

прежде чем система-источник начнет задерживать операции записи от клиентов.

Внимание: Если величина отставания установлена на значение менее 10 секунд, SnapMirror

автоматически переключится в синхронный режим (synchronous mode). Для использования полу-

синхронного режима (semi-synchronous mode), рекомендуется использовать интервал задержки в

10 секунд и более.

Отредактируйте файл /etc/snapmirror.conf и напишите в него:

<src_storage>:<vol_name> <dest_storage>:<vol_name> - semi-sync outstansding=<seconds>

/ <milliseconds> / <# of Ops>

Например: <src_storage>:<vol_name> <dest_storage>:<vol_name> - semi-sync outstansding=10s

Пример выше определяет имя тома <vol_name> на исходной системе хранения <src_storage> ,

который должен реплицироваться в том с именем <vol_name> на системе хранения

<dest_storage> , полу-синхронно, с отставанием не более чем на 10 секунд.

Понимание эффекта влияния работы SnapMirror на Oracle

Вопросы производительности в целом являются сложной областью, состоящей из множества

аспектов. Эта тема, сама по себе, безусловно, выходит за рамки данного документа, но имеет

смысл отдельно обсудить эффект использования SnapMirror для данных системы хранения, и как

он влияет на общую производительность решения.

Любой метод синхронной репликации, вне зависимости от используемой технологии, будет

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

этой причине очень важным будет понять то, каковы требования бизнеса к производительности

приложения и защите данных, и позволить компании сделать обоснованный выбор между

различными вариантами стратегии защиты данных.

Влияние на загрузку CPU

Когда система хранения, с работающим SnapMirror в синхронном или асинхронном режиме,

получает запрос на запись от клиента, системе хранения надо выполнить все обычные для этого

операции по записи, плюс дополнительные операции по передаче данных с помощью SnapMirror

на удаленную систему, и это естественно добавляет значительную нагрузку на CPU контроллера

для каждой операции записи. Также, обычно, любые операции записи или чтения, выполняемые

клиентом системы хранения по сети, отражаются на уровне загрузки CPU. В общем случае вам

следует ожидать удвоения загрузки CPU на контроллере системы хранения для той же нагрузки,

при использовании SnapMirror.

Вопросы пропускной способности сети

Все данные, которые записаны на систему-источник данных, должны быть реплицированы на

систему-получатель; полоса пропускания системы-источника на запись не может превысить

полосу пропускания сети между системами источником и получателем, при использовании

SnapMirror в синхронном или асинхронном режиме*. Важно принять во внимание параметры

сетевой полосы пропускания между системами. По грубой оценке, 250GB данных будут

передаваться 7,5 часов по каналу 10-BaseT full duplex†, и около 1,5 часов по каналу Gigabit Ethernet.

Влияние на параметр Write Latency в Oracle при использовании SnapMirror

Для каждой операции записи, выполненной на стороне-источнике репликации, вдобавок к

обычной процедуре, которая происходит при локальной записи без SnapMirror, синхронный и

асинхронный режим должен произвести следующее:

Система-источник должна инкапсулировать и передать операцию на удаленную систему-

получатель репликации. Система-получатель должна принять операцию, записать в журнал, и

послать уведомление о получении на систему-источник.

Система-источник данных должна принимать и обрабатывать подтверждения процессов

репликации от системы получателя.

Этот процесс увеличивает задержки для каждой операции записи, выполняемой клиентом на

системе-источнике данных.

Общая величина задержек может варьироваться в зависимости от характера выполняемых

операций, модели системы хранения, и других нагрузок на системе-источнике или системе-

получателе репликации.

Зависимость параметра Write Latency в Oracle от дистанции репликации

Дополнительно к задержкам, которые обсуждались выше, расстояние по сети между источником

и получателем репликации, также играет свою роль. Для сети Fibre Channel, соединение между

источником и получателем лимитировано скоростью света в кабеле. Всегда рекомендуется

* В общем случае это неверное утверждение. Это так только для синхронной репликации, при которой

передается любая операция записи. В случае асинхронной или полусинхронной репликации объем передачи может быть меньше, порой значительно, так как передаются не операции записей, а фактические изменения целевой файловой системы группами записей, за определенный интервал времени, и bandwidth между системами не влияет непосредственно на bandwidth системы на запись. (прим. перев.) † У автора опечатка, по-видимому, имелся в виду 100-BaseT. (прим. перев.)

измерять реальную задержку в сети, вместо того, чтобы полагаться на теоретический расчет;

типичная величина скорости света в оптоволокне дает примерно 1.05ms задержки на 100 миль

расстояния. Например, если источник и получатель репликации разнесены на 100 миль, то

суммарную задержку для сигнала, прошедшего туда и обратно, следует ожидать в районе 2.1ms,

что добавляется к каждой операции записи, выполняемой клиентом на системе-источнике

репликации, так как процесс записи при синхронной репликации ожидает подтверждения от

системы-получателя репликации на другой стороне линии.

Прочие факторы работы SnapMirror, увеличивающие задержки для Oracle

Прочие источники увеличения задержек при работе по сети это сетевые устройства,

пропускающие трафик, например роутеры, коммутаторы, и так далее. Каждое такое устройство

добавляет задержку, принимая сигнал с одного интерфейса, обрабатывая внутри, и передавая его

с другого интерфейса. Величина добавляемых задержек в целом невелика, но она растет с

увеличением таких устройств на пути сигнала в сети.

Выбор правильной модели репликации

При наличии нескольких доступных режимов репликации, имеющихся у SnapMirror и их

различных характеристиках производительности, становится важным выбрать правильный режим

репликации для вашей системы.

Таблица 5) режимы репликации SnapMirror.

Режим репликации

Величина лага

Требования к ширине канала

Влияние на операции записи

Влияние на задержки записи

Асинхронная Зависит от выбранного расписания

Наименьшие требования

Минимальное влияние


Полусинхронная, с отставанием более 10 секунд

В среднем 10 секунд

Требует производительность канала близкую к желаемой производительности записи на систему хранения

Значительное влияние на объемы операции записи на системе-источнике, но меньше чем у синхронной


Полусинхронная, с отставанием менее 10 секунд

От 0 до 10 секунд

Требует производительность канала равную желаемой производительности записи на систему хранения плюс оверхед

Значительное влияние на объемы операции записи на системе-источнике

Зависит от выбранной конфигурации

Синхронная отсутствует Требует производительность канала равную желаемой производительности записи на систему хранения плюс оверхед

Значительное влияние на объемы операции записи на системе-источнике

Значительное влияние на задержки записи на системе-источнике

MetroCluster

MetroCluster™ это решение распределенного Fibre Channel кластера хранения, которое

обеспечивает высокую доступность для хранимых данных, и близкую к нулю величину RPO при

восстановлении приложений после катастрофического отказа. MetroCluster использует SyncMirror

для зеркалирования данных между сайтами. MetroCluster это идеальное решение для системы

кампусного или внутригородского типа.

CFO (Clustered Failover)

Контроллеры системы хранения могут быть использованы парами active-active что обеспечивает

высокую доступность и дополнительную защиту. Эта конфигурация известна как clustered failover

(CFO) или HA-кластер. В такой паре каждый контроллер обслуживает свою нагрузку,

одновременно наблюдая за состоянием своего партнера. Если один из контроллеров в паре

выходит из строя, оставшийся переключает на себя его задачи и обслуживаемые им диски. Эта

передача обслуживания данных происходит автоматически и прозрачно для пользователей и

приложений.

HA-кластер NetApp (CFO cluster) может быть использован совместно с Oracle RAC для создания

производительных и высокодоступных систем работы с базами данных Oracle Database 11g.

Распределение нагрузки для наилучшей производительности

HA-кластер NetApp CFO состоит из двух узлов. HA-кластер не осуществляет автоматическую

балансировку нагрузки между своими узлами, так что файлы базы данных должны быть

распределены между узлами администратором вручную, для обеспечения равномерной загрузки

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

может быть достигнут максимум ее производительности.

Файлы базы данных на узле 1 Файлы базы данных на узле 2

Файлы данных (половина их, поделенная между узлами по общей нагрузке)

Файлы данных (половина их, поделенная между узлами по общей нагрузке)

Временные файлы (половина их, поделенная между узлами по общей нагрузке)

Временные файлы (половина их, поделенная между узлами по общей нагрузке)

Индексные файлы (половина их, поделенная между узлами по общей нагрузке)

Индексные файлы (половина их, поделенная между узлами по общей нагрузке)

Redo Logs

Archive Logs

Такая схема позволит использовать ресурсы обоих контроллеров системы хранения и обеспечить

максимальную производительность.

Разделы Oracle home и Oracle CRS home обычно не несут существенной нагрузки по вводу-выводу,

чтобы их было необходимо распределять между узлами HA-кластера.

Узлы HA-кластера должны иметь следующие настройки:

CF.GIVEBACK.AUTO.ENABLE OFF

CF.GIVEBACK.CHECK.PARTNER ON

CF.TAKEOVER.DETECTION.SECONDS 15

CF.TAKEOVER.ON_FAILURE ON

CF.TAKEOVER.ON_NETWORK_INTERFACE_FAILURE ON

CF.TAKEOVER.ON_PANIC ON

CF.TAKEOVER.ON_SHORT_UPTIME ON

Обновление Data ONTAP и NDU

Непрерывающее работу обновление (Nondisruptive upgrade, NDU) для Data ONTAP может быть

выполнено для системы, использующей Oracle Database 11g, с помощью указаний в этой главе.

Общий процесс обновления

Существует два основных метода обновления версии Data ONTAP, это процесс, требующий

остановки работы (disruptive upgrade) и непрерывающий работу (nondisruptive upgrade, NDU).

• Disruptive upgrade: Это процесс обновления Data ONTAP, в который входит

запланированная остановка работы системы хранения. Процесс включает в себя остановку

работы всех баз Oracle Databases и приложений, использующих систему хранения,

обновление версии Data ONTAP, и затем возобновление работы баз данных и

приложений.

• NDU: Это процесс обновления Data ONTAP, при котором Oracle Databases и приложения

продолжают работать и сохраняют доступ к системе хранения и ее данным. Такой режим

требует использования active-active NetApp CFO cluster.

Существуют также два варианта режима обновления, это обновления «мажорной» и «минорной»

версии.

• «Мажорное» обновление: Это обновление с одной «мажорной» версии релиза Data

ONTAP на другую «мажорную» (например, с 7.3.x до 8.0.x).

• «Минорное» обновление: Это обновление на подверсии внутри одной «мажорной»

версии (например, с 8.0.1 на 8.0.2).

В любом случае, disruptive upgrade гораздо проще, чем NDU. Если возможно остановить работу

баз данных и приложений на запланированный перерыв работы, мы рекомендуем сделать это,

затем провести обновление Data ONTAP во время этой остановки. Если такой вариант

невозможен, то тогда выполняйте NDU.

Nondisruptive Upgrade (NDU)

Процесс nondisruptive upgrade (NDU) обновляет Data ONTAP на контроллерах, включенных в HA-

пару в составе системы хранения NetApp, по очереди, не прерывая при этом ее работы в целом по

обслуживанию данных и вводу-выводу от хостов или клиентов. В ходе NDU новая версия Data

ONTAP заливается на загрузочный раздел на каждом из контроллеров HA-пары; проводится

кластерный takeover, то есть перехват функций одного контроллера другим; контроллер

выполняет перезагрузку; затем выполняется обратный процесс передачи, giveback, и затем

takeover в обратном направлении, для перезагрузки второго контроллера пары; и, наконец,

giveback для возврата в работу второго контроллера, после чего оба контроллера работают уже на

новой версии Data ONTAP. Каждый процесс takeover/giveback занимает определенное время, и

производительность ввода-вывода несколько снизится на этот период, так как один контроллер

будет обслуживать нагрузку, лежавшую ранее на двух контроллерах пары. Процедуры NDU

отличаются в зависимости от версии Data ONTAP, протокола доступа к данным, и используемого

ПО организации multipathing.

Так как каждый контроллер в конфигурации active-active cluster имеет доступ как к своим

дисковым полкам, так и к дисковым полкам партнера, любой из контроллеров может

обслуживать все тома и LUN-ы системы, даже если контроллер-партнер перестает работать.

Процесс nondisruptive upgrade делится на 4 части:

1. Копирование и установка новой версии Data ONTAP на оба контроллера системы

хранения, сбор всей необходимой информации, и выполнение необходимых изменений

конфигурации на хостах.

2. Перенос всех операций ввода-вывода на один узел пары, и запуск новой версии Data

ONTAP на другом контроллере пары.

3. Перенос всех операций ввода-вывода на узел пары с новой версией Data ONTAP, и запуск

новой версии Data ONTAP на другом контроллере пары.

4. Возврат операций ввода-вывода на оба контроллера.

Выполнение NDU для SAN сложнее, чем для NAS, и на процесс влияет также использованное на

хосте решение multipathing. Прежде всего, это так потому, что SAN не предусматривает идею, что

таргет может перемешаться с одного устройства на другое, то есть не предусматривает

маршрутизацию доступа. Когда система хранения NetApp подключена через Fibre Channel к хосту,

она должна быть, для обеспечения надежности, подключена через несколько HBA и с помощью

нескольких кабелей, а ситуация с несколькими путями к одному LUN решается с помощью средств

multipathing.

Дальнейшее усложнение ситуации возникает оттого, что каждая OS на хостах использует свой

собственный программный механизм multipathing.

Предварительные шаги

• Получите текущую версию документации.

• Получите руководство по обновлению для выбранной версии Data ONTAP (upgrade guide)

Обратите внимание, что процесс NDU может отличаться в зависимости от версии Data

ONTAP. Вы можете получить руководство по адресу:

http://now.netapp.com/NOW/knowledge/docs/ontap/ontap_index.shtml.

• Получите документ Data ONTAP release notes для намеченной версии Data ONTAP.

Документ Release Notes также доступен с сайта NetApp Support.

Проверьте Bugs Online

Проведите поиск по сервису Bugs Online для проверки известных проблем при инсталляции и

обновлении. Убедитесь, что провели поиск по номеру версии Data ONTAP, на которую вы

обновляетесь, и по OS хост-серверов, подключенных по iSCSI и FCP. Сервис Bugs Online находится

на сайте NetApp Support.

Проверьте, что обновление поддерживается. Проверьте, что обновляемая система удовлетворяет

основным требованиям к nondisruptive upgrade в руководстве Data ONTAP upgrade guide. Это

руководство содержит также ряд дополнительных требований и ограничений.

Убедитесь, что ваша конфигурация поддерживается в соответствующей матрице совместимости

для исходной, и для устанавливаемой версии Data ONTAP, проверьте для этого:

• Версию OS и ее патчей/сервиспаков на хосте

• Модель Fibre Channel HBA и версию ее firmware

• Модель и версию firmware для коммутатора Fibre Channel

• Версию iSCSI initiator

• Multipath I/O (MPIO) software

Смотрите Compatibility and Configuration Guide for NetApp FCP and iSCSI Products.

http://now.netapp.com/NOW/knowledge/docs/ontap/ontap_index.shtml

Возможна ситуация, когда для части хостов возможен процесс nondisruptive upgrade, а для части -

нет. Вы по-прежнему можете выполнить nondisruptive upgrade для системы, даже если некоторые

хосты такой режим не поддерживают; для таких, неподдерживаемых хостов, конечно, процесс

будет сопряжен с прерыванием доступа.

NDU on NAS

Для подробностей о проведении NDU для NAS-систем , смотрите Data ONTAP upgrade guide и TR-

3450: Active/Active Controller Configuration Overview and Best Practice Guidelines.

NDU on SAN

Процедура NDU различна для разных версий Data ONTAP, версий OS на хосте, и примененных

решений организации multipathing.

Наиболее свежая информация о порядке выполнения NDU для SAN находится на сайте NetApp

Support.

NetApp Professional Services также выполняет NDU в среде SAN у клиентов. Для связи со службой

Professional Services, смотрите ссылку:

http://now.netapp.com/NOW/knowledge/docs/san/overviews/ndu.htm.

Данные документы также помогут в рассмотрении темы NDU для SAN:


www.netapp.com/library/tr/3450.pdf.

5.4 Виртуализация

Концепции виртуализации

Виртуализация, это введение уровня абстракции, который «отвязывает» физическое

оборудование от операционной системы, и позволяет более гибко и более полно использовать

ресурсы. Распространение виртуализации в IT сегодня широкое и всеобъемлющее. Виртуализация

позволяет запустить несколько виртуальных машин, каждая со своей OS и задачей, работающих

на одной физической серверной системе.

Преимущества виртуализации

Вы можете установить несколько OS на одной физической машине. Это экономит время

инсталляции. Когда OS установлена, вы можете скопировать ее и использовать файлы дискового

образа в своих инсталляциях виртуализованных OS или инстансах. Преимущества данной

технологии в переходе к «виртуальной инфраструктуре» и оперированию «пулом ресурсов»,

агрегированными ресурсами серверов, систем хранения и сетевых компонентов,

представленными в виде единого пула вычислительного ресурса и емкости хранения.

Недостатки виртуализации

Запуск нескольких OS на одной физической машине может потребовать увеличение потребности в

памяти и ресурсах процессора. Виртуализованная среда не может быть мигрирована на другую

физическую машину с другой архитектурой CPU, например с X86 на ARM или SPARC. Поддержка в

Oracle виртуализованных сред ограничена.

http://now.netapp.com/NOW/knowledge/docs/san/overviews/ndu.htm


http://www.netapp.com/library/tr/3450.pdf

Некоторые из продуктов серверной виртуализации:

• VMware®

• Hyper-V™

• XEN

• KVM

Xen

Xen это гипервизор виртуальных машин с открытым кодом. Xen может поддерживать работу

нескольких виртуальных машин, каждой со своей собственной OS, в одной физической системе.

Xen выпущен под лицензией GNU general public license.

Информация о Xen доступна на сайте XenSource: www.xensource.com.

Xen использует паравиртуализационный метод виртуализации. Паравиртуализация, это

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

Oracle Database 11g не сертифицирована для использования в production на Xen; однако вы

можете использовать виртуализацию в Xen для задач тестирования и разработки.

VMware

Сайт Oracle Metalink указывает на ограниченную поддержку Oracle, работающего в среде VMware.

Проконсультируйтесь с Metalink note 249212.1. В данной статье Oracle указывает: «Oracle не

сертифицировал какой-либо из продуктов VMware для виртуализации. Oracle Support

оказывает поддержку для продуктов Oracle, которые запущены в среде VMware следующим

образом: Oracle оказывает поддержку по тем ситуациям, которые возникают в нативной

среде соответствующей OS, или могу быть повторены и продемонстрированы, что они не

являются особенностью, вызванной работой в среде VMware». Смотрите соответствующую

статью Metalink для полного текста.

VMware может быть ограниченно применим в среде production; однако он может быть очень

популярным решением для сред тестирования и разработки. VMware это хорошо работающая с

NetApp среда, позволяющая быстрое развертывание и клонирование с помощью NetApp FlexVol и

FlexClone.

Для подробностей обратитесь к документам NetApp по использованию систем хранения NetApp с

решениями VMware‡:

• NetApp and VMware VI3 Storage Best Practices: www.netapp.com/library/tr/3428.pdf

• NetApp and VMware ESX Server 3.0 Building a Virtual Infrastructure from Server to Storage:

www.netapp.com/library/tr/3515.pdf

‡ Данный список устарел. Наиболее новые документы на данную тему: TR-3749 и TR-4068.

http://www.xensource.com/



6 Приложения§

6.1 Операционные системы

Linux

Linux: Рекомендованные версии

Различные версии OS Linux базируются на определенной версии ядра. Хотя на рынке присутствуют

различные дистрибутивы Linux, стоит сосредоточить внимание на используемом в них ядре и его

версиях для того, чтобы понимать ситуацию с функциональными возможностями и

совместимостью.

Рекомендации по ядру

Рекомендации по ядру Linux для Oracle Database 11g Release 2:

• Для Red Hat Enterprise Linux 4.0: версия 2.6.9 и новее

• Для Oracle Enterprise Linux 5: версия 2.6.18 и новее

Для того чтобы определить версию используемого ядра, воспользуйтесь командой:

# uname -r

Пример вывода по этой команде на Red Hat:

Enterprise Linux 4.0 system:

2.6.9-34.EL

В этом примере вы видите версию ядра (2.6.9) и «патчлевел» (errata level, 34.EL). Если версия ядра

не соответствует требованиям, определенным ранее в документе к ядру Linux, то свяжитесь с

производителем дистрибутива для его обновления и установки патчей.

Linux: Рекомендованные версии

NetApp протестировал многие версии OS Linux, и рекомендует основанные на ядре 2.6.9**.

Рекомендованные дистрибутивы это Red Hat Enterprise Linux Advanced Server 4.0 и 5.0, а также

Oracle Enterprise Linux 4.0 и 5.0.

Linux: Требования по пакетам

Установка Oracle Database требует следующих установленных в OS пакетов. Для полного списка

пакетов, просмотрите главу Software Requirements в документации на Oracle 11g.

Enterprise Linux 5.0 or Red Hat Enterprise Linux 5.0

Необходимы следующие packages (или их более новые версии): binutils-2.17.50.0.6 compat-libstdc++-33-3.2.3 elfutils-libelf-0.125 elfutils-libelf-devel-0.125 elfutils-libelf-devel-static-0.125 gcc-4.1.2 gcc-c++-4.1.2 glibc-2.5-24

§ Текст включенный в Приложения в основном взят из значительно устаревшего TR-3369, используйте

рекомендации, встречающиеся в Приложении с крайней осторожностью, и только там, где они не противоречат основному тексту документа (прим. перев.) **

Данная рекомендация также устарела и будет пересмотрена в следующей версии данного документа.

glibc-common-2.5 glibc-devel-2.5 glibc-headers-2.5 kernel-headers-2.6.18 ksh-20060214 libaio-0.3.106 libaio-devel-0.3.106 libgcc-4.1.2 libgomp-4.1.2 libstdc++-4.1.2 libstdc++-devel-4.1.2 make-3.81 numactl-devel-0.9.8.i386 sysstat-7.0.2

Linux: Настройки OS

Параметры ядра и величины лимитов для shell, приведенные в данной главе, приведены как

рекомендованные значения.

В системе, используемой под продакшн-задачи, Oracle рекомендует вам настроить эти значения

для оптимизации производительности системы. Проконсультируйтесь с документацией на OS для

подробностей о настройке параметров ядра.

Убедитесь, что параметры ядра, показанные в таблице ниже, установлены в значения, больше или

равные рекомендованным. Процедура, описанная далее, покажет, как проверить и установить

нужные значения.

Таблица 6) Параметры ядра Linux.

Параметр Величина Файл semmsl semmns semopm semmni

250 32000 100 128

/proc/sys/kernel/sem

shmall 2097152 /proc/sys/kernel/shmall

shmmax Половина от размера физической памяти (в байтах). Смотрите подробнее в: My Oracle Support Note 567506.1.

/proc/sys/kernel/shmmax

shmmni 4096 /proc/sys/kernel/shmmni

file-max 6815744 /proc/sys/fs/file-max

ip_local_port_range Minimum: 9000 Maximum: 65500

/proc/sys/net/ipv4/ip_local_port_range

rmem_default 262144 /proc/sys/net/core/rmem_default

rmem_max 4194304 /proc/sys/net/core/rmem_max

wmem_default 262144 /proc/sys/net/core/wmem_default

wmem_max 1048576 /proc/sys/net/core/wmem_max

Внимание: Если текущее значение величины параметра выше, чем указано в таблице, не

изменяйте это значение.

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

1. Ввести команду, показанную в следующей таблице, чтобы просмотреть текущее значение

параметра ядра.

Внимание: Запишите текущие значения и определите, какие из них вы должны изменить.

Параметр Команда

semmsl, semmns, semopm, semmni

# /sbin/sysctl -a | grep sem Эта команда показывает величину параметров семафоров.

shmall, shmmax, shmmni

# /sbin/sysctl -a | grep shm Эта команда показывает подробности о размерах shared memory segment.

file-max # /sbin/sysctl -a | grep file-max Эта команда показывает максимальное число файловых хэндлов.

ip_local_port_range # /sbin/sysctl -a | grep ip_local_port_range Эта команда показывает диапазон номеров портов.

rmem_default # /sbin/sysctl -a | grep rmem_default

rmem_max # /sbin/sysctl -a | grep rmem_max

wmem_default # /sbin/sysctl -a | grep wmem_default

wmem_max # /sbin/sysctl -a | grep wmem_max

2. Если величина какого-то из параметров ядра отличается от рекомендованных значений,

выполните следующую процедуру:

a. Используя любой текстовый редактор, создайте файл /etc/sysctl.conf, и добавьте, или

отредактируйте в нем строки, похожие на следующие:

fs.file-max = 6815744

kernel.shmall = 2097152

kernel.shmmax = 2147483648

kernel.shmmni = 4096

kernel.sem = 250 32000 100 128

net.ipv4.ip_local_port_range = 9000 65500

net.core.rmem_default = 262144

net.core.rmem_max = 4194304

net.core.wmem_default = 262144

net.core.wmem_max = 1048576

Внимание: Включите в него строки только тех параметров, которые вы хотите изменить. Для

«семафорных» параметров (kernel.sem), вы должны определить четыре значения. Однако, если

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

большее значение.

Если вы определите параметры через записи в файле /etc/sysctl.conf , тогда они сохранятся

после перезагрузки системы.

b. Введите следующую команду, для изменения текущих значений параметров ядра:

# /sbin/sysctl-p

c. Просмотрите вывод команды, чтобы убедиться, что все значения верны. Если вы обнаружили

неверные значения, то отредактируйте файл /etc/sysctl.conf , затем введите эту команду

снова.

Установка лимитов Shell для пользователя Oracle

Для улучшения производительности Oracle на Linux, вам следует увеличить следующие лимиты

для пользователя Oracle:

Лимиты Shell Объект в limits.conf Жесткий лимит

Максимальное число открытых файловых дескрипторов

nofile 65536

Максимальное число процессов, доступных одному пользователю

nproc 16384

Для увеличения лимитов:

Добавьте следующие строки в файл /etc/security/limits.conf:

oracle Soft nproc 2047 oracle Hard nproc 16384 oracle Soft nofile 1024 oracle Hard nofile 65536 oracle Soft stack 10240

Сетевые настройки в Linux: Full Duplex и Autonegotiation

Большинство сетевых карт используют режим автоопределения (autonegotiation) для наилучших

настроек режимов карты и порта коммутатора, в который она включена. Однако иногда

несовместимости могут привести к неправильному автоопределению режимов, и установке порта

карты в режим half duplex или на пониженной скорости, а также вызывать непрерывные

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

линка Ethernet сделаны правильно, прежде чем искать боле сложные причины. Остерегайтесь

жесткого задания параметров как способа решения проблем автоопределения, так как это может

только маскировать более глубоко лежащую причину. Производители карт и коммутаторов могут

помочь в решении этих проблем.

Сетевые настройки в Linux: Сетевые адаптеры Gigabit Ethernet ††

Если серверы Linux используют высокопроизводительную сеть (гигабитную или быстрее),

обеспечьте им достаточные ресурсы CPU и полосы доступа к памяти для обработки прерываний и

достаточного потока данных. Клиент NFS и драйвер сетевой карты уменьшают объем ресурсов,

доступных приложению, поэтому убедитесь, что объемы ресурсов выделены адекватно.

Большинство гигабитных карт поддерживают 64-bit PCI или лучше, что обеспечивает хорошую

производительность.

Любая база данных, использующая систему хранения NetApp должна использовать Gigabit

Ethernet на стороне как системы хранения, так и сервера базы данных, для достижения

наилучшей производительности.

NetApp установил, что следующие сетевые адаптеры Gigabit Ethernet хорошо работают в Linux:

• SysKonnect. Сетевые адаптеры серии SysKonnect SK-98XX хорошо работают в Linux и

поддерживают одно- и двух-портовые, оптические и медные интерфейсы. Стабильный драйвер

включен в ядра ветки 2.4.

††

Информация о доступных и поддерживаемых сетевых адаптерах устарела и будет пересмотрена.

• Broadcom. Многие карты и коммутаторы используют этот чипсет, включая решения 3Com, это

обеспечивает хорошую переносимость. Драйвер для данного чипсета включен в ядро начиная с

версии 2.4.19, и включен в дистрибутив Red Hat с ядрами 2.4.

• AceNIC Tigon II. Некоторые карты, например NetGear GA620T, используют этот чипсет, но более

они не производятся. Дрйвера для данного чипсета включены в ядро.

• Intel® EEPro/1000. Возможно наилучшие и наиболее быстрые карты Gigabit Ethernet для

серверов на платформе Intel, но драйвера для этих карт включены только в наиболее новые

версии ядер (2.4.20 и новее) и могут быть нестабильными. Версии драйверов для более ранних

версий ядер могут быть получены на сайте Intel. Сообщается, что кадр jumbo frame MTU для карт

Intel составляет только 8998 байт, а не стандартные 9000 байт.

Сетевые настройки в Linux: Jumbo Frames with GbE

Все карты, описанные выше, поддерживают опцию jumbo frames для Gigabit Ethernet.

Использование jumbo frames может повысить производительность системы, использующей Linux

NFS clients и системы хранения NetApp в немаршрутизируемой сети. Удостоверьтесь, что

проверили в документации на каждый используемый коммутатор его возможности по работе с

jumbo frames. Существует несколько известных проблем в драйверах Linux при использовании

максимального размера фрейма (9000 байт). Если вы столкнулись с неожиданными

замедлениями при использовании jumbo frames, то попробуйте уменьшить размер MTU до 8960

байт.

Протокол Linux NFS: Опции монтирования

Установка правильных опций монтирования NFS может значительно влиять на

производительности и надежность ввода-вывода. Рекомендованные NetApp опции был

протестированы и совместно утверждены как NetApp, так и Oracle.

Для наиболее свежих данных по опциям монтирования NFS и сопутствующей информации, см.:


iSCSI Initiators для Linux

Best Practice

NetApp рекомендует использовать NetApp iSCSI host attach kit for Linux для использования с

платформами RHEL, OEL, и SUSE под Oracle Databases.

FCP SAN Initiators для Linux

Best Practice

NetApp рекомендует использовать NetApp FCP Host attach kit 3.0 или новее. NetApp рекомендует

использовать для Oracle Database на Linux инфраструктуру Fibre Channel SAN, когда такая

инфрастуктура уже развернута и в нее вложены средства. NetApp также рекомендует рассмотреть

использование Fibre Channel SAN с Linux, когда установившаяся производительность баз Oracle по

пропускной способности превышает 1GB в секунду.

Solaris Operating System

Solaris: Рекомендуемые версии

В таблице перечислены минимальные версии OS Solaris для использования с Oracle Database 11g

R2.


Таблица 7) Рекомендации по версиям

OS Версия Рекомендуется?

Solaris 8 и ранее Нет

Solaris 9 Update 5 и ранее Нет

Solaris 9 Update 6 и новее Нет

Solaris 10 Update 6 и новее Да

Best Practice

NetApp рекомендует использовать Solaris 10 Update 6 и новее для Oracle Database 11g R2.

Solaris: Параметры ядра

Для параметров ядра и подробной информации о Solaris OS, смотрите:

• http://download.oracle.com/docs/cd/E11882_01/install.112/e17163/toc.htm

• www.oracle.com/pls/db112/to_pdf?pathname=install.112/e10848.pdf

• www.oracle.com/pls/db112/portal.portal_db?selected=11&frame=#solaris_installation_guides

Solaris: Packages

Следующие packages (или их более новые версии) необходимы для Oracle Database 11g R2:

SUNWarc

SUNWbtool

SUNWhea

SUNWlibC

SUNWlibm

SUNWlibms

SUNWsprot

SUNWtoo

SUNWi1of

SUNWi1cs(ISO8859-1)

SUNWi15cs(ISO8859-15)

SUNWxwfnt

Вам может также потребоваться дополнительный package со шрифтами для Java®, что зависит от

используемой вами локали. Смотрите http://java.sun.com/j2se/1.4.2/font-requirements.html.

Solaris: Patches

Патчи для Solaris часто обновляются, так что любой список с конкретными версиями быстро

устареет. Указанный список патчей является минимально необходимым; более поздние ревизии

могут содержать дополнительные исправления, но могут вызывать и неожиданные проблемы.

Best Practice

NetApp рекомендует устанавливать наиболее свежие ревизии соответствующих патчей. Однако,

если становятся известны какие-либо проблемы с новыми ревизиями, следует установить

ревизию патча, указанную в таблице, чтобы убедиться, что проблема вызвана именно более

свежим релизом патча.

Эти рекомендации дополняют, но не заменяют рекомендации по устанавливаемым патчам

Solaris, приведенные в Oracle installation или release notes.

http://download.oracle.com/docs/cd/E11882_01/install.112/e17163/toc.htm

http://www.oracle.com/pls/db112/to_pdf?pathname=install.112/e10848.pdf

http://www.oracle.com/pls/db112/portal.portal_db?selected=11&frame=#solaris_installation_guides

http://java.sun.com/j2se/1.4.2/font-requirements.html

В таблице приведен список необходимых патчей для Oracle Database 11g Release 2.

Тип инсталляции или продукт Требования

Любая инсталляция Следующие системные packages (или их более поздние версии) должны быть установлены: 120753-06: SunOS 5.10: Microtasking libraries (libmtsk) patch 139574-03: SunOS 5.10 141444-09 141414-02

PL/SQL native compilation, Pro*C/C++, Pro*FORTRAN, Oracle Call Interface, Oracle C++ Call Interface, Oracle XML Developer’s Kit (XDK)

Патчи для Solaris 10: 119963-14: SunOS 5.10: Shared library patch for C++ 124861-15: SunOS 5.10 Compiler Common patch for Sun C C++ (optional)

Database Smart Flash Cache (только Enterprise Edition)

Эти патчи нужны если вы используете Flash Cache: 125555-03 140796-01 140899-01 141016-01 139555-08 141414-10 141736-05

Solaris: Требования к компилятору

Требования к компилятору Solaris для Oracle Database 11g Release 2.

Продукт Требования

PL/SQL native compilation, Pro*C/C++, Oracle Call Interface, Oracle C++ Call Interface, Oracle XML Developer’s Kit (XDK)

Oracle Solaris Studio 12 (C and C++ 5.9)

Сетевые настройки в Solaris: Сетевые адаптеры Gigabit Ethernet

Sun предлагает карты Gigabit Ethernet как для PCI, так и для SBUS. Карты на PCI имеют более

высокую производительность чем версии на SBUS.

NetApp рекомендует использовать карты PCI‡‡, когда это возможно.

Все базы данных, использующие систему хранения NetApp, должны использовать Gigabit

Ethernet§§ на обоих концах соединения, как на системе хранения, так и на сервере, для

достижения оптимальной производительности.

SysKonnect это независимый производитель NIC, поставляющий карты Gigabit Ethernet. Версия

карт на PCI обеспечивает наивысшую производительность.

Необходимо убедиться в том, что сервера Sun с картами Gigabit Ethernet работают в режиме full

flow control (некоторые требуют независимой установки режимов для «send» и «receive»).

‡‡

Безусловно, имеется ввиду PCIe (прим.перев.) §§

…или более быстрые, например 10 Gigabit Ethernet (прим.перев.)

На сервере Sun установка flow control может быть произведена добавлением следующих строк в

инициализационный скрипт (такой как, например, /etc/rc2.d/S99*) или изменением этих

значений, если они уже существуют:

ndd –set /dev/ge instance 0

ndd –set /dev/ge ge_adv_pauseRX 1

ndd –set /dev/ge ge_adv_pauseTX 1

ndd –set /dev/ge ge_intr_mode 1

ndd –set /dev/ge ge_put_cfg 0

Внимание: Значение instance может отличаться от 0, если на системе более одного интерфейса

Gigabit Ethernet.

Продублируйте установки для каждого instance, который подключен к NetApp. Для серверов,

использующих /etc/system, добавьте следующие строки:

set ge:ge_adv_pauseRX=1

set ge:ge_adv_pauseTX=1

set ge:ge_intr_mode=1

set ge_ge_put_cfg=0

Отметьте, что помещение этих настроек в /etc/system влияет на все Gigabit-интерфейсы сервера.

Коммутаторы, и другие подключаемые устройства, также должны быть соответствующим образом

сконфигурированы.

Сетевые настройки в Solaris: Jumbo Frames и GbE

SysKonnect поставляет карты типа SK-98xx, поддерживающие jumbo frames. Для включения jumbo

frames, выполните следующие шаги:

1. Отредактируйте /kernel/drv/skge.conf и раскомментируйте строку:

JumboFrames_Inst0="On";

2. Отредактируйте /etc/rcS.d/S50skge и добавьте строку:

ifconfig skge0 mtu 9000

3. Перезагрузите систему.

Best Practice

Если вы используете jumbo frames с картами SysKonnect NIC, используйте коммутаторы, которые

поддерживают jumbo frames и включите поддержку jumbo frames на сетевом интерфейсе системы

хранения NetApp.

Сетевые настройки в Solaris: Улучшение сетевой производительности

Настройка приведенных ниже параметров может дать выигрыш в производительности сети.

Большинство из этих настроек отображается с помощью команды Solaris ndd, и устанавливается

при использовании ndd или редактировании файла /etc/system.

/dev/udp udp_recv_hiwat: Определяет максимальную величину приемного буфера UDP. Это

количество места в буферах, выделенное под принимаемые данные UDP. Значение по умолчанию

8192 (8kB). Должно быть установлено в 65535 (64kB).

/dev/udp udp_xmit_hiwat: Определяет максимальную величину буфера передачи UDP. Это

количество места в буферах, выделенное под передаваемые данные UDP. Значение по

умолчанию 8192 (8kB). Должно быть установлено в 65535 (64kB).

/dev/tcp tcp_recv_hiwat: Определяет максимальную величину приемного буфера TCP. Это

количество места в буферах, выделенное под принимаемые данные TCP. Значение по умолчанию


/dev/tcp tcp_xmit_hiwat: Определяет максимальную величину буфера передачи TCP. Это

количество места в буферах, выделенное под передаваемые данные TCP. Значение по умолчанию


/dev/ge adv_pauseTX 1: Задает принудительный контроль потока (flow control) на передачу для

адаптера Gigabit Etherne. Установление контроля потока на передающей стороне означает, что

передающий управляет объемом передаваемых данных; Значение по умолчанию в Solaris – «0»,

пока оно не будет включено в результате процесса autonegotiation между сетевыми портами.

Best Practice

NetApp настоятельно рекомендует установить параметр transmit flow control в 1 (включено).

Установка этого значения в 1 поможет устранить возникновение отброшенных пакетов и их

повторные передачи, поскольку эта установка включает для порта контроль передачи. Если NIC

переполняется данными, она передает посылающему порту сигнал паузы. Иногда, в целях

диагностики, может быть полезным установить этот параметр в 0 для того, чтобы определить, что

посылающий данные(NetApp) переполняет клиента.

/dev/ge adv_pauseRX 1: Принудительно устанавливает контроль потока (flow control) приема для

адаптера Gigabit Ethernet. Установление контроля потока на приемной стороне означает, что

получатель управляет объемом получаемых данных. Установка «1» это значение по умолчанию

для Solaris.

/dev/ge adv_1000fdx_cap 1: Задает принудительный full duplex для адаптера Gigabit Ethernet. Full

duplex позволяет данным передаваться и приниматься одновременно. Это нужно установить

одинаков как на стороне сервера Solaris, так и на системе хранения NetApp. Ошибки в

определении режима duplex приводят к сетевым ошибкам и ошибкам базы данных.

sq_max_size: Устанавливает максимальное количество сообщений (messages), допустимых для

каждой очереди IP (IP queue) (STREAMS synchronized queue). Увеличение этого параметра

улучшает сетевую производительность. Безопасная величина для этого параметра 25 для каждых

64MB физической памяти на системе Solaris, вплоть до максимального значения в 100. Параметр

следует оптимизировать, начав с 25 и увеличивая на 10, пока сетевая производительность не

достигнет пика.

Nstrpush: Определяет максимальное количество модулей, которые могут быть отправлены в

поток, и должен быть установлен в 9.

Ncsize: Определяет размер DNLC (directory name lookup cache). DNLC хранит информацию о файлах

на томе NFS. Непопадание в кэш может вызвать дисковую операцию ввода-вывода чтения

директории.

Чтение этой информации из кэша может значительно улучшить производительность NFS; getattr,

setattr, и lookup обычно составляют более 50% всех вызовов NFS. Если запрошенная

информация не нашлась в кэше, то запускается дисковая операция, что в результате негативно

сказывается на общей производительности. Единственное ограничение размера кэша DNLC это

доступная ядру память. Каждый элемент DNLC занимает примерно 50 байт дополнительной

памяти ядра.

Best Practice

NetApp рекомендует установить значение ncsize равное 8000.

nfs:nfs3_max_threads: Максимальное число потоков (threads), которые может использовать

клиент NFS V3.

Рекомендованное значение 24.

nfs:nfs3_nra: Размер упреждающего чтения (read-ahead count) для клиента NFS V3.


nfs:nfs_max_threads: Максимальное число потоков (threads), которые может использовать клиент

NFS V2.


nfs:nfs_nra: Размер упреждающего чтения (read-ahead count) для клиента NFS V2.


Solaris IP Multipathing (IPMP)

Solaris IPMP это терминология, используемая в документации Solaris для обозначения средств

отказоусточивости и балансировки нагрузки сетевых карт и интерфейсов. Это увеличивает общую

пропускную способность системы, путем балансировки нагрузки по нескольким интерфейсам.

О поддержке IPMP смотрите:

• http://now.netapp.com/NOW/knowledge/docs/san/fcp_iscsi_config/iscsi_support_matrix.shtml

• http://now.netapp.com/matrix/mtx/login.do

Протокол NFS в Solaris: Опции монтирования

Установка правильных опций монтирования NFS может оказывать значительное влияние на

производительность и надежность подсистемы ввода-вывода. Ниже приводятся некоторые

рекомендации, которые помогут выбрать правильные опции.

Для наиболее свежих рекомендаций по опциям монтирования в NFS, смотрите:


Опции монтирования определены в /etc/vfstab и применяются автоматически, при загрузке OS.

Для задания опций монтирования:

1. Отредактируйте /etc/vfstab.

2. Для каждого NFS mount, участвующего в высокоскоростной инфраструктуре, убедитесь,

что опции монтирования соответствуют рекомендованным.

Внимание: Эти значения являются значениями по умолчанию для NFS в Solaris 10 и 9. Явно

определять их не требуется, но весьма желательно для лучшей ясности конфигурации.

Hard. Опция «soft» не должна никогда использоваться для баз данных. Это может вызвать

неполную запись данных, и проблемы с файлами базы данных. Опция «hard» определяет, что

запросы ввода-вывода будут посланы повторно, в случае, если они были неудачны при первой

попытке. Это принуждает приложение производить операцию ввода-вывода через NFS, пока

затребованный файл не окажется доступным. Это особенно важно в случае использования

отказоустойчивых и избыточных сетей и серверов (например, в случае кластера NetApp).

Bg. Определяет, что операция монтирования должна выполняться в фоновом режиме, если

система хранения NetApp недоступна, что позволяет загрузке Solaris продолжаться в этом случае.

Так как процесс загрузки системы может быть выполнен даже при недоступности всех

необходимых файловых систем, позаботьтесь о том, чтобы нужные файловые системы были

смонтированы и присутствовали до начала запуска Oracle Database.

Intr. Эта опция позволяет операциям ожидать прерывания NFS. Если эта опция не используется, и

соединение NFS смонтированное с опцией «hard» оборвано и не восстановлено, то единственный

способ восстановить работу для Solaris в таком случае это перезагрузка сервера.

rsize/wsize. Определяет размер запроса NFS для чтения/записи. Величины этих параметров

должны соответствовать значению nfs.udp.xfersize и nfs.tcp.xfersize на системе хранения

NetApp. Величина 32768 (32kB) рекомендуется для максимальной производительности базы

данных при использовании NetApp и Solaris. По меньшей мере размер NFS read/write size должен

быть равен или больше, чем размер блока (block size) Oracle.

Vers. Устанавливает используемую версию NFS. Version 3 обеспечивает оптимальную

производительность баз данных под Solaris.

Proto. Указывает Solaris использовать TCP или UDP для соединения. В прошлом UDP обеспечивал

лучшую производительность, но в настоящее время его использование ограничено только очень

http://now.netapp.com/NOW/knowledge/docs/san/fcp_iscsi_config/iscsi_support_matrix.shtml

http://now.netapp.com/matrix/mtx/login.do


надежными соединениями. TCP имеет несколько больший overhead, но обрабатывает ошибки и

лучше управляет потоком. Если требуется максимальная производительность, и сетевые

соединения между сервером Solaris и системой хранения NetApp короткие, надежные и работают

на одной скорости (включая порты коммутатора Ethernet), то может использоваться и UDP***. Но в

общем случае использование TCP безопаснее.

Forcedirectio. Это опция, появившаяся в Solaris 8. Она позволяет приложению обходить кэш ядра

Solaris, что оптимально для Oracle. Эта опция должна использоваться для томов, содерержащих

файлы данных. Она не должна использоваться для томов, содержащих исполняемые файлы.

Использование этой опции с томом, содержащим исполняемые файлы Oracle, будет

препятствовать запуску всех исполняемых файлов, хранящихся на томе. Если программа, которая

обычно нормально запускается, не хочет стартовать, или немедленно падает в «core dump»,

проверьте, не находится ли она на томе, смонтированном с опцией «forcedirectio».

Использование Direct I/O дает существенные преимущества. Операции Direct I/O обходят кэщ

файловой системы Solaris. Когда блок данных читается с диска, он считывается непосредственно в

кэш-буферы Oracle, и не попадает в кэш файловой системы.

Без использования Direct I/O, блок данных считывается в кэш файловой системы и, затем, в кэш

Oracle, двойное буферирование данных тратит пространство памяти и циклы CPU. Oracle не

пользуется кэшем файловой системы.

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

NetApp обнаружил, что без включенного Direct I/O для файловой системы NFS, большое число

страниц файловой системы вытесняются в swap. Это добавляет системный оверхед на

переключение контекстов и увеличивает загрузку CPU. С использованием Direct I/O снижается

загрузка CPU и нагрузка на swap. В зависимости от типа нагрузки, степень влияния Direct I/O на

общую производительность варьируется, и в некоторых случаях вызывает повышение

производительности более 20%.

Direct I/O может использоваться для файловых систем NFS, на которых размещены файлы Oracle

Database, но не исполняемые файлы Oracle (ORACLE_HOME, ORA_CRS_HOME) или когда

выполняются обычные операции ввода-вывода, например dd. Обычные операции файлового

ввода-вывода лучше работают с использованием кэширования на уровне файловой системы.

Один том может быть смонтирован более одного раза, с разными опциями, так что можно по

некоторым таким монтированиям иметь преимущества использования от forcedirectio , в то

время как по другим – нет, однако это может вызывать потенциальную путаницу, и такой вариант

следует использовать с осторожностью.

***

Данная рекомендация противоречит основному тексту документа и не должна приниматься во внимание. В настоящий момент работа NFS по UDP не поддерживается в NetApp ни по каким каналам.

Best Practice

NetApp рекомендует использовать «forcedirectio» на отдельных томах, на которых характер

паттерна ввода-вывода не требует кэширования на клиенте NFS. В общем случае это данные,

паттерн доступа к которым преимущественно произвольный (random) а также файлы online redo

log и archive log. Опция «forcedirectio» не должна использоваться для томов, содержащих

исполняемые файлы, такие, как директория ORACLE_HOME. Использование опции «forcedirectio»

на томах, содержащих исполняемые файлы, вызовет их неверную работу.

Multiple Mountpoints

Чтобы достичь максимальной производительности транзакционная база типа OLTP может

использовать возможности множественного монтирования базы данных и распределения

нагрузки по этим точкам монтирования.

Чтобы это настроить, создайте дополнительную точку монтирования на ту же файловую систему

на системе хранения NetApp. После чего переименуйте файлы базы данных (при помощи

команды ALTER DATABASE RENAME FILE) или создайте симлинк со старой точки монтирования на

новую.

iSCSI Initiators for Solaris

Самая свежая информация о поддержке iSCSI initiator находится тут:

http://now.netapp.com/NOW/knowledge/docs/san/fcp_iscsi_config/iscsi_support_matrix.shtml.

Fibre Channel SAN for Solaris

NetApp поставляет первую в отрасли систему универсального доступа, позволяющую обслуживать

данные как NAS или SAN. NetApp предлагает решения Fibre Channel SAN для всех платформ,

включая Solaris, Windows, Linux, HP/UX, и AIX. Решение NetApp Fibre Channel SAN предлагает тот

же фреймворк управления, и богатую функциональность, что отличает наши NAS системы.

Пользователь может выбрать NAS или FC SAN для использования в Solaris, в зависимости от

нагрузки и имеющегося оборудования. Для конфигурации FC SAN, настоятельно рекомендуется

использовать специальный комплект NetApp SAN host attach kit for Solaris. Данный комплект

поставляется с Fibre Channel HBA, драйверами, firmware, утилитами и документацией. Для

инсталляции и конфигурации консультируйтесь с документацией, поставляемой с комплектом.

NetApp проверил и одобрил решение FC SAN с Solaris под Oracle. Консультируйтесь с

руководством Oracle integration guide и NetApp FC SAN in a Solaris environment ([6]) для

подробностей. Для выполнения резервного копирования и восстановления Oracle Database в SAN,

см [7]†††.

Наиболее свежая информация по поддерживаемым FCP attach kits:

http://now.netapp.com/NOW/knowledge/docs/san/fcp_iscsi_config/fcp_support.shtml.

†††

Ссылка ошибочна в оригинале документа

http://now.netapp.com/NOW/knowledge/docs/san/fcp_iscsi_config/iscsi_support_matrix.shtml

http://now.netapp.com/NOW/knowledge/docs/san/fcp_iscsi_config/fcp_support.shtml

IBM AIX

Для установки Oracle Database на IBM-AIX, смотрите документы:

• IBM AIX with Oracle Database using NetApp Storage in NAS environments

• IBM AIX with Oracle Database using NetApp Storage in SAN environments

HP-UX

Для установки Oracle Database на HP-UX, смотрите документы:

• HP-UX with Oracle Database using NetApp Storage in NAS environments

• HP-UX with Oracle Database using NetApp Storage in SAN environments

6.2 ASM Начиная с Oracle Database 10g RDBMS предлагает новый механизм хранения данных, под

названием Automatic Storage Management (ASM), который представляет собой интегрированную

кластерную файловую систему со средствами управления томами.

ASM дополняет Oracle Database 10g RDBMS средствами управления томами и дисками, устраняя

необходимость в использовании сторонних инструментов такого рода, и снижает сложность

администрирования архитектуры. ASM обеспечивает простоту управления томами, которые могут

состоять из блочных (SAN) или файловых устройств (NFS). Эти устройства являются нижележащими

системами хранения для Oracle RDBMS.

Новые возможности, появившиеся в ASM в Oracle Database 11g:

1. Новая роль SYSASM для администрирования Automatic Storage Management

2. Атрибуты совместимости дисковых групп

3. ASM fast rebalance

4. ASM fast mirror resync

5. Новые команды ASMCMD и ASMCA для упрощения конфигурирования хранилища

6. ASM preferred mirror read

7. Экстенты ASM переменного размера, улучшения масштабируемости и

производительности

8. Возможность постепенной миграции для Automatic Storage Management

ASM с использованием iSCSI/FCP

ASM обеспечивает функции менеджера томов и файлов базы данных, встроенного в ядро Oracle

Database. Используя эти возможности, ASM позволяет отказаться для выполнения этих задач от

сторонних продуктов для управления системой и томами при выполнении задач управления

хранилищем базы данных, таких как создание и размещение баз данных и управления

использованием дискового пространства.

Oracle ASM на NetApp SAN дает пользователю альтернативные возможности управления томами

для сервера Oracle, используя знакомые операции SQL create/alter/drop, упрощая работу DBA.

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

выводу.

Система хранения NetApp автоматически балансирует нагрузку по вводу-выводу по всем дискам,

входящим в aggregate. Все LUN-ы и файлы, помещенные в том WAFL равномерно распределены

по дискам, на которых размещен том. ASM обеспечивает балансировку нагрузки также между

http://media.netapp.com/documents/tr-3542.pdf




всеми LUN-ами и файлами дисковой группы ASM, распределяя по ним нагрузку путем

равномерного разнесения данных по компонентам дисковой группы на фрагменты (stripe),

размером 1MB.

При совместном использовании, балансировка NetApp позволяет множеству LUN или файлов

совместно использовать одни и те же диски, снижая число LUN-ов на дисковую группу ASM для

улучшения управляемости.

ASM далее позволяет балансировать нагрузку между несколькими томами NetApp, или даже

несколькими системами хранения. Структуры WAFL оптимизированы для работы с записью

мелких блоков в произвольном порядке. WAFL обеспечивает равномерную нагрузку для всех

дисков, входящих в дисковую группу тома. Это обеспечивает оптимальную производительность

записи-чтения для высоконагруженных баз данных.

Следующие рекомендации применимы вне зависимости от того, какая из двух моделей выбрана:

• Используйте файловую систему на хосте или по NFS для хранения бинарных файлов Oracle и

иных, не подходящих для хранения на ASM файлов. В Oracle 10g RAC может быть

использована NFS, для упрощения схемы с совместно используемым Oracle home.

• Используйте любой из пригодных протоколов универсальной системы хранения NetApp (Fibre

Channel, iSCSI SAN, или NFS NAS) для доступа к хранилищу, содержащему дисковые группы

ASM.

• Объедините физические диски системы хранения NetApp в небольшое число больших томов

FlexVol, для минимизации административного оверхеда.

• Убедитесь, что LUN-ы или файлы каждой дисковой группы сбалансированы в терминах

пропускной способности на емкость, то есть доступная пропускная способность, доступная

дисковой группе с каждого LUN или файла, пропорциональна размеру этого LUN (или файла).

То есть, все LUN/файлы в дисковой группе ASM должны обеспечивать примерно равные

показатели производительности операций ввода-вывода на гигабайт. Этого проще всего

добиться, используя физические диски идентичной производительности и размера,

объединенные в тома WAFL.

• Создайте несколько (например, четыре) LUN-а или файла на каждую дисковую группу ASM, на

каждом томе FlexVol.

Использование множества LUN/файлов может повысить параллелизм ввода-вывода для дисковой

группы, повышая любой лимит для LUN со стороны драйвера на хосте (а также OS и/или драйвера

multipath). Даже если это и не является необходимым в настоящий момент для вашей системы,

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

добавлены в дисковую группу.

ASM с использованием NFS

Хотя использование ASM поверх SAN-системы хранения и более популярный вариант,

пользователи также могу использовать ASM поверх NFS-хранилища. Слой ASM работает

независимо от клиента NFS, поэтому надежность и безопасность клиента NFS не страдает. ASM по

NFS может быть интересным вариантом, особенно в сегменте SMB, когда TCO развертывания и

администрирования SAN может быть неприемлемо велика. Администраторы системы хранения

могут следовать стандартным методикам развертывания и администрирования системы хранения

для структурированных или неструктурированных данных. NFS широко распространен, и поэтому

Oracle DBA может легко администрировать и удовлетворять требованиям базы данных к

хранилищу NAS. Использование NFS не требует специальных знаний персонала, которые обычно

необходимы в случае администрирования среды SAN. Пользователь, который уже имеет

действующую инфраструктуру NAS, может легко развернуть на ней систему Oracle Database 10g

Real Application Clusters (RAC) с использованием ASM, без необходимости изменять среду

хранения.

Также есть интересная возможность для пользователей, использующих NFS, и желающих

развернуть Oracle Database 10g/11g Standard Edition (SE). Эта лицензия не имеет опции tablespace

partitioning. Хорошей альтернативой для системы с использованием NFS будет распределение

табличных пространств по нескольким томам или системам хранения с помощью дисковых групп

ASM.

Теме работы ASM на NFS, посвящен документ www.netapp.com/library/tr/3572.pdf.

7 Справочные материалы

1. Data ONTAP 7G: The Ideal Platform for Database Applications:


2. Oracle9i for UNIX: Backup and Recovery Using a NetApp Storage Device:


3. Using the Linux NFS Client with NetApp: Getting the Best from Linux and NetApp:


4. Installation and Setup Guide 1.0 for Fibre Channel Protocol on Linux:

http://now.netapp.com/NOW/knowledge/docs/hba/fcp_linux/fcp_linux10/pdfs/install.pdf

5. Oracle9i for UNIX: Integrating with a NetApp Storage Device in a SAN Environment:


6. Oracle9i for UNIX: Backup and Recovery Using a NetApp Storage Device in a SAN Environment:


7. Data Protection Strategies for NetApp Storage Devices:


8. Data Protection Solutions Overview:


9. Simplify Application Availability and Disaster Recovery:

www.netapp.com/partners/docs/oracleworld.pdf

10. Oracle8i for UNIX: Providing Disaster Recovery with NetApp SnapMirror Technology:


11. ndmpcopy Reference:

http://now.netapp.com/NOW/knowledge/docs/ontap/rel632/html/ontap/dpg/ndmp11.htm#12704

98

12. SnapManager for Oracle:

www.netapp.com/us/library/technical-reports/tr-3761.html

13. Best Practices Guide: SnapManager for Oracle:


14. Linux (RHEL 4) 64 Bit Performance with NFS, iSCSI, FCP Using an Oracle Database on NetApp Storage:






http://now.netapp.com/NOW/knowledge/docs/hba/fcp_linux/fcp_linux10/pdfs/install.pdf





http://www.netapp.com/partners/docs/oracleworld.pdf







15. Oracle 10g Performance: Protocol Comparison on Sun Solaris 10:


16. NOW Database Best Practices Index:

http://now.netapp.com/NOW/knowledge/docs/bpg/db/

17. Oracle Database mount options knowledgebase:


18. Practices Index:


19. Ethernet Storage Best Practices:

www.netapp.com/us/library/technical-reports/tr-3802.html

8 История изменений документа

Дата Изменения Обновил

Октябрь 2007 Исходная версия

Август 2009 Глава 3.6.6 DNFS Sankar Bose

Февраль 2010 Ссылки на AIX Naveen Harsani

Апрель 2010 Опции монтирования Fredrick Grahn

Август 2010 Глава 3.2.3 размер тома Naveen Harsani

Июль 2011 Обновление до 11g R2 Naveen Harsani


http://now.netapp.com/NOW/knowledge/docs/bpg/db/




Documents

Руководство по наилучшим практикам для racle 11 и · PDF fileOracle Database 11g ... также расширяет утилиту конверсии