Автоматическое управление памятью

Автор: Аруп Нунда, член-директор ORACLE ACE

Новая роль SYSASM для управления экземпляром ASM, переменный размер экстента для уменьшения использования разделяемого пула ( shared pool) и возможность  экземпляра читать с конкретного диска дисковой группы - вот лишь несколько замечательных новых возможностей, появившихся в базе данных Oracle 11 g ASM. Роль SYSASM

Появившееся в Oracle Database 11 g автоматическое управление памятью ( Automatic Storage Management - ASM) несколько размыло границу между администраторами баз данных (АБД) и системными администраторами в части их функций распределения памяти. Администраторы БД управляют экземплярами ASM, так же как они выполняют обычные свои работы, требующие присоединения в роли SYSDBA. Но по прошествии времени роли стали более четкими, и произошло элементарное разделение труда. В результате некоторые операции ASM вернулись  к  системным администраторам. В некоторых случаях образовался отдельный класс "администраторов ASM", которые занимались только администрированием ASM, а не базы данных.

Однако появление этого нового класса создает конфликт: чтобы управлять экземпляром ASM необходима роль SYSDBA, а многие администраторы промышленных баз данных, работающие на том же сервере, чувствуют себя некомфортно, разделяя эту роль.

В Oracle Database 11 g этот конфликт изжит. Теперь существует новая роль SYSASM, предназначенная только для управления экземпляром ASM. Для экземпляра ASM она подобна роли SYSDBA. К экземпляру ASM теперь нужно присоединяться так:

$ sqlplus / as sysasm

SQL*Plus: Release 11.1.0.6.0 - Production on Fri Sep 28 20:37:39 2007

Copyright (c) 1982, 2007, Oracle.  All rights reserved.

Connected to:

Oracle Database 11g Enterprise Edition Release 11.1.0.6.0 - Production

With the Partitioning, Oracle Label Security, OLAP, Data Mining

and Real Application Testing options

SQL>

Обратите внимание на предложение соединения " as sysasm ". В Oracle Database 11 g R1, роль SYSASM дается группе операционной системы, имеющей также привилегию SYSDBA (в большинстве случаев она называется "dba"). Иначе говоря, пользователь, принадлежащий группе dba в Unix, может также присоединиться как SYSASM. (Этот механизм изменится в более поздних версиях; роли sysdba и sysasm будут разделены в группах операционной системы.)
Присоединившись как sys к экземпляру ASM, можно изменить пароль SYS, который изменится в файле паролей:

SQL> alter user sys identified by oracle

  2  /

User altered.

Хотя экземпляр ASM обходится без базы данных, тем не менее, есть возможность создавать пользователей:

SQL> create user asmoper identified by dumboper

  2  /

User created.

Теперь можно дать роль SYSASM пользователю:

SQL> grant sysasm to asmoper;

Grant succeeded.

После этого пользователь asmoper может выполнять все функции управления ASM вместо пользователя SYS. Пользователь может присоединиться с предложением as sysasm, подобно предложению  "as sysdba" в обычной базе данных.

$ sqlplus asmoper/dumboper as sysasm

Эта возможность вынуждает к необходимому разграничению ответственности ASM и DBA.

Переменные размеры экстентов
Наименьшим элементом в памяти ASM является единица размещения (allocation unit - AU), идейно очень похожая на блок базы данных Oracle. При создании сегментов базы данных, таких как таблицы или индексы, наименьшей единицей размещения является не блок, а экстент, содержащий в себе много блоков. Можно изменять размер экстентов сегмента.

В ASM очень похожая идея: когда файлы создаются в дисковой группе ASM, наименьшей адресуемой единицей является экстент, а не AU.  В базе данных Oracle 10 g   AU и экстенты являются взаимозаменяемыми; один экстент состоит ровно из одной AU.

Дисковым группам, совместимым с 10 g, требуется память в разделяемом пуле для каждого экстента. Для больших баз данных, соответственно, необходимо большое количество памяти. Поэтому, если размер AU составляет 1MB (это значение по умолчанию), то базе данных объемом 1TB потребуется разместить более одного миллиона экстентов в разделяемом пуле.

В Oracle Database 11 g размеры экстентов больше не равны размерам AU. Когда файл создается, размер экстентов начинается с 1MB. После того, как файл достигнет определенного порога, размер экстента увеличивается до 4MB, затем до 16MB и, наконец, после некоторого порога размер экстента становится 64MB. Нет необходимости беспокоиться о размерах, экземпляр автоматически назначает соответствующий размер экстента. Поскольку меньшее количество экстентов может разместить большее количество данных, общее количество экстентов в разделяемом пуле существенно снижается, что улучшает производительность в несколько раз.

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

Как я уже говорил, размер AU по умолчанию - 1 MB. Для многих баз данных этого достаточно, но рассмотрим большую базу данных, размером более 10 TB. Вероятно, объекты будут больше 1MB, поэтому можно увеличить размер AU, чтобы уменьшить их количество. В базе данных Oracle 10 g нужно было установить заниженные параметры, чтобы изменить размер AU. Однако это влияло на все дисковые группы, которые создавались уже после этого, и также требовало перезапуска экземпляра ASM для установки параметра.
В Oracle Database 11 g эта задача легко решается установкой атрибута дисковой группы - au_ size - во время создания дисковой группы (diskgroup - DG), как показано ниже:

create diskgroup dg6

external redundancy

disk    

'/dev/raw/raw13'

attribute 'au_size' = '2M'

attribute 'au_size' = ' 2097152'

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

select name, allocation_unit_size

from v$asm_diskgroup

/

NAME    ALLOCATION_UNIT_SIZE

------- --------------------

DG1                  1048576

DG3                  1048576

DG6                  2097152

DG5                  1048576

DG4                  1048576

DG2                  1048576

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

ASM - это платформа хранения для баз данных Oracle начиная с 10 g до текущей версии. Поэтому экземпляр ASM может хранить базы данных 10 g Release 1, 10 g Release 2, 11 g Release 1 (и далее). Пока версия ASM та же или выше, чем версия СУБД, есть возможность создавать базу данных на этом экземпляре ASM. Итак, как взаимодействует ASM с экземпляром СУБД, если они разных версий? Просто: ASM преобразует сообщения, чтобы соответствовать версии СУБД.

По умолчанию экземпляр ASM поддерживает базы данных 10 g . Но что произойдеть, если необходимо разместить только  СУБД версии 11 g в этом экземпляре ASM? Тогда отпадает необходимость преобразования сообщений для поддержки разницы версий. Вот если бы был способ сказать экземпляру ASM, что все поддерживаемые базы данных имеют версию 11 g Release 1. Это устранило бы или, по крайней мере, уменьшило преобразование сообщений. В Oracle Database 11 g это возможно, благодаря атрибутам дисковой группы ASM Compatibility и RDBMS Compatibility.

Во-первых, давайте проверим текущие атрибуты дисковой группы:

SQL> select compatibility, database_compatibility

  2  from  v$asm_diskgroup

  3  where name = 'DG1'

  4  /

COMPATIBILITY          DATABASE_COMPATIBILITY

---------------------- ----------------------

10.1.0.0.0             10.1.0.0.0

Как можно видеть, атрибут ASM Compatibility (показывается как COMPATIBILITY) имеет значение 10.1.0.0.0, что означает, что дисковая группа поддерживает структуру 10.1 ASM.

Следовательно, эта дисковая группа может включать СУБД любой структуры. Другой столбец, DATABASE_COMPATIBILITY, показывает, что совместимость с СУБД установлена в значение 10.1. Это значит, что дисковая группа DG1 может быть использована любой СУБД, начиная с версии  10.1.

Если необходимо создавать только структуры 11 g ASM и СУБД, то нет необходимости иметь элементы 10 g . Чтобы установить атрибут ASM Compatibility этой дисковой группы в значение 11.1, нужно выполнить следующий оператор (в экземпляре ASM):

SQL> alter diskgroup dg1 set attribute 'compatible.asm'='11.1';

COMPATIBILITY          DATABASE_COMPATIBILITY

---------------------- ----------------------

11.1.0.0.0             10.1.0.0.0

ASM Compatibility установлена в значение 11.1; но RDBMS Compatibility все еще имеет значение 10.1. Чтобы изменить его на 11.1, используется следующий оператор:

SQL> alter diskgroup dg1 set attribute 'compatible.rdbms'='11.1';

Обратите внимание на одну важную вещь: совместимость устанавливается для дисковой группы, а не для всего экземпляра ASM. Эта возможность позволяет использовать только один экземпляр ASM, но обслуживать все типы версий баз данных. В зависимости от используемой версии можно установить соответствующий атрибут и  уменьшить взаимодействие между версиями.

В базе данных Oracle RAC (Real Application Cluster) существует множество узлов, использующих вместе экземпляр ASM. Если реализуется обычное зеркалирование в дисковой группе ASM, то доступ к дискам может быть не таким, как ожидается.

Допустим, что существует дисковая (diskgroup) группа DG2, состоящую из двух отказоустойчивых (failgroups) групп DG2_0000 и DG2_0001, каждая из которых размещается на отдельном диске, как показано на рисунке:

Когда что-то записывается в дисковую группу DG2, экстенты записываются круговым способом: первый экстент записывается на диск DG2_0000 с копией на диск DG2_0001, второй - на диск DG2_0001 с копией на диск DG2_0000, третий - опять на DG2_0000 с копией на диск DG2_0001 и так далее. Таким образом, ASM создает копию одного диска на другом.

Но когда экстенты читаются, они всегда читаются с основного диска (в данном случае - DG2_0000); а не с дополнительного (DG2_0001). Дополнительный читается только, если основной недоступен.

Это хорошо работает в большинстве случаев, но иногда такое поведение нежелательно. В Oracle Database 11 g можно сконфигурировать узел так, чтобы читать из конкретной отказоустойчивой группы. Например, если необходимо в приведенном ранее примере сконфигурировать экземпляр 1 так, чтобы читать из failgroup DG2_0000 и экземпляр 2 так, чтобы читать из отказоустойчивой группы DG2_0001, то можно указать предпочтительную группу чтения для этих дисковых групп. Следующая  команда, выполненная в экземпляре 1, сделает предпочтительной отказоустойчивую группу DG2_0000 в дисковой группе DG2 и DG3_0000 - в дисковой группе DG3:

SQL> alter system set asm_preferred_read_failure_groups = 'DG2.DG2_0000','DG3.DG3_0000'

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

SQL> alter system set asm_preferred_read_failure_groups = 'DG2.DG2_0001','DG3.DG3_0001'        

После выполнения этих операторов, когда какая-либо сессия из экземпляра 1 захочет читать из дисковой группы DG2, то будет читаться DG2_0000. Если диск недоступен, то будет читаться другой диск DG2_0001.  Аналогичным образом, когда сессия,  работающая на экземпляре 2, читает данные, то читается диск DG2_0001.

Можно проверить, как используются различные диски дисковых групп, посмотрев новое представление словаря данных V$ASM_DISK_IOSTAT, которое напоминает утилиту IOSTAT, существующую в системе UNIX:

select

        instname,

        dbname,

        group_number,

        failgroup,

        disk_number,

        reads,

        writes

from v$asm_disk_iostat

order by 1,2,3,4,5,6

/

INSTNAM DBNAME   GROUP_NUMBER FAILGROUP  DISK_NUMBER      READS     WRITES

------- -------- ------------ ---------- ----------- ---------- ----------

PRONE31  PRONE3             2 DG2_0000             0       4450        910

PRONE32  PRONE3             2 DG2_0001             1       2256        910

PRONE31  PRONE3             3 DG3_0000             0        300         29

PRONE32  PRONE3             3 DG3_0001             1        560         29

Эти выходные данные показывают, что экземпляры PRONE31 и PRONE32 имеют свои предпочтительные отказоустойчивые группы DG2_0000 и DG2_0001 соответственно. Обратите внимание на столбец WRITES, там одинаковые значения - 910. Это потому, что запись происходит на оба диска. Посмотрите теперь на столбец READS. Он имеет значения 4450 и 2256 для экземпляров PRONE31 и PRONE32 соответственно. Почему? Потому что экземпляр PRONE31 выполнял больше чтений, и эти чтения выполнялись с предпочтительной отказоустойчивой группой DG2_0000. Что касается дисковой группы DG3, экземпляр PRONE32 выполнял больше чтений из предпочтительной отказоустойчивой группы (DG3_0001), поэтому для этого диска показывается большее количество чтений.
Предпочтительные чтения особенно полезны в "stretch" ("протяжённых") кластерах (кластерах с большим географическим расстоянием между узлами). Предпочтительные чтения позволяют выполнять чтения быстрее, благодаря изолированному чтению с конкретных дисков.

Что происходит, когда диск больше не существует (или разрушен и не подлежит восстановлению)? Вы хотите удалить дисковую группу полностью и вновь создать её или добавить диски из одной дисковой группы в другую. Эта дисковая группа еще не смонтирована. Поскольку один из дисков отсутствует, вы не можете даже смонтировать её. Чтобы удалить дисковую группу, её нужно смонтировать, а смонтировать её нельзя, потому что диск отсутствует - настоящая ситуация "catch-22". Что вы будете делать?
В Oracle Database 10 g можно использовать обходной путь: стереть заголовок диска с помощью команды dd:

$ dd if=/dev/zero of=/dev/raw/raw13 bs=1024 count=4

Эта команда ставит нули в заголовке диска /dev/raw/raw13, стирая всю информацию. После выполнения этой команды стирается вся информация в заголовке диска полностью, включая тот факт, что диск был частью дисковой группы.
В Oracle Database 11 g нет необходимости прибегать к  такому обходному пути. Все что нужно сделать это выполнить команду drop с опцией  force:

SQL> drop diskgroup dg7 force including contents;

Эта команда удаляет дисковую группу, даже если диски не смонтированы. Доступные диски показываются как FORMER; что означает, что они были частью какой-то дисковой группы. (Примечание: необходимо использовать предложение " including contents ".)

Многие люди считают ASM базой данных со своей собственной памятью. Это не совсем так - ASM не хранит данные; их хранит база данных. Однако экземпляр ASM хранит метаданные, такие как имена дисковых групп; диски, входящие в них; директории и т.д. Эти метаданные хранятся в заголовках дисков.

Предположим, что все диски разрушены и информация из заголовков исчезла. Что делать? Конечно, вы сделали резервную копию базы данных, используя RMAN, и можете восстановить её. Но её можно будет восстановить только после того, как будут созданы все дисковые группы и директории. Надеюсь, у вас есть записи обо всем этом. (Верно?) Даже если есть, этот процесс требует времени.

Что, если бы у вас была резервная копия? В Oracle Database 11 g можно создать резервную копию метаданных экземпляра ASM с помощью командной строки ASM (ASMCMD), используя команду md_backup.

$ asmcmd -p

ASMCMD [+] > md_backup

@diskgroup_set = (

            {

             'DISKSINFO' => {

                     'DG1_0000'  => {

                              'DG1_0000' => {

                                      'TOTAL_MB' => '103',

                                     'FAILGROUP' => 'DG1_0000',

                                      'NAME' => 'DG1_0000',

                                      'DGNAME' => 'DG1',

                                      'PATH' => '/dev/raw/raw5'

                                     }

                            }

                    },

             'DGINFO' => {

                    'DGTORESTORE'  => 0,

                    'DGCOMPAT'  => '10.1.0.0.0',

                    'DGNAME' =>  'DG1',

                    'DGDBCOMPAT'  => '10.1.0.0.0',

                    'DGTYPE' =>  'EXTERN',

                    'DGAUSZ' =>  '1048576'

                   },

             'ALIASINFO' => {},

             'TEMPLATEINFO' => {

                       '6' => {

                           'DGNAME'  => 'DG1',

                           'STRIPE'  => 'COARSE',

                           'TEMPNAME' => 'ASM_STALE',

                            'REDUNDANCY' => 'UNPROT',

                           'SYSTEM'  => 'Y'

  ... and more ... 

Я не показываю здесь файл целиком, чтобы сэкономить место. В нем записаны все дисковые группы, диски, директории, атрибуты дисков и тому подобное. По умолчанию в этом файле записаны все дисковые группы. Если необходимо создать резервную копию только для  конкретной дисковой группы, можно использовать опцию - g . Дополнительно, можно использовать опцию - b , чтобы создать файл с заданным именем.

ASMCMD [+] > md_backup -g dg1 -b prolin3_asm.backup

Эта команда создает резервную копию метаданных DG1 в файле с именем prolin3_asm.backup вместо имени по умолчанию ambr_backup_intermediate_file. Этот файл должен быть новым, поэтому, если он существует, то перед генерацией его необходимо удалить.
Теперь давайте посмотрим, как работает восстановление. Существует несколько типов восстановления. Простейший способ - это восстановить ранее удаленную дисковую группу вместе с директориями. Сначала создайте директорию в дисковой группе:

ASMCMD [+] > cd DG7

ASMCMD [+DG7] > mkdir TEST

ASMCMD [+DG7] > ls

TEST/

ASMCMD [+] > md_backup -g dg7 -b g7.backup

SQL> drop diskgroup dg7;     

Diskgroup dropped.

$ asmcmd md_restore -b dg7.backup -t full  

Current Diskgroup being restored: DG7

Diskgroup DG7 created!

System template TEMPFILE modified!

System template FLASHBACK modified!

System template ARCHIVELOG modified!

System template BACKUPSET modified!

System template XTRANSPORT modified!

System template DATAGUARDCONFIG modified!

System template CONTROLFILE modified!

System template AUTOBACKUP modified!

System template DUMPSET modified!

System template ONLINELOG modified!

System template PARAMETERFILE modified!

System template ASM_STALE modified!

System template CHANGETRACKING modified!

System template DATAFILE modified!

Directory +DG7/TEST re-created!

Посмотрите на результат; создается дисковая группа, а также шаблоны и директории. Если там были какие-то данные, конечно, они будут потеряны. md_backup - это резервирование не данных, а скорее метаданных экземпляра ASM. Данные, очевидно, резервируются RMAN. После создания дисковой группы вместе с директориями можно восстановить резервную копию RMAN для этой дисковой группы.
Другая опция  - f  позволяет размещать команды в скрипт-файле вместо того, чтобы выполнять их:

ASMCMD [+] > md_restore -b dg7.backup -t full -f cr_dg7.sql

Она создает SQL-скрипт с именем cr_dg7.sql, который создаёт дисковую группу и другие объекты. Его можно вручную запустить в экземпляре ASM. Вот как выглядит этот файл:

create diskgroup DG7 EXTERNAL redundancy  disk '/dev/raw/raw14' name DG7_0000 size 100M ;

alter diskgroup /*ASMCMD AMBR*/DG7 alter template TEMPFILE attributes (UNPROTECTED COARSE);

alter diskgroup /*ASMCMD AMBR*/DG7 alter template FLASHBACK attributes (UNPROTECTED FINE);

alter diskgroup /*ASMCMD AMBR*/DG7 alter template ARCHIVELOG attributes (UNPROTECTED COARSE);

alter diskgroup /*ASMCMD AMBR*/DG7 alter template BACKUPSET attributes (UNPROTECTED COARSE);

alter diskgroup /*ASMCMD AMBR*/DG7 alter template XTRANSPORT attributes (UNPROTECTED COARSE);

alter diskgroup /*ASMCMD AMBR*/DG7 alter template DATAGUARDCONFIG attributes (UNPROTECTED COARSE);

alter diskgroup /*ASMCMD AMBR*/DG7 alter template CONTROLFILE attributes (UNPROTECTED FINE);

alter diskgroup /*ASMCMD AMBR*/DG7 alter template AUTOBACKUP attributes (UNPROTECTED COARSE);

alter diskgroup /*ASMCMD AMBR*/DG7 alter template DUMPSET attributes (UNPROTECTED COARSE);

alter diskgroup /*ASMCMD AMBR*/DG7 alter template ONLINELOG attributes (UNPROTECTED FINE);

alter diskgroup /*ASMCMD AMBR*/DG7 alter template PARAMETERFILE attributes (UNPROTECTED COARSE);

alter diskgroup /*ASMCMD AMBR*/DG7 alter template ASM_STALE attributes (UNPROTECTED COARSE);

alter diskgroup /*ASMCMD AMBR*/DG7 alter template CHANGETRACKING attributes (UNPROTECTED COARSE);

alter diskgroup /*ASMCMD AMBR*/DG7 alter template DATAFILE attributes (UNPROTECTED COARSE);

alter diskgroup /*ASMCMD AMBR */ DG7 add directory '+DG7/TEST';

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

Одним из наиболее часто встречающихся желаний пользователей ASM, привыкших к традиционному управлению томами, является возможность проверки множество вещей, используя командную строку.  Командная строка ASM (утилита ASMCMD) в значительной степени реализует эту возможность. В Oracle Database 11 g некоторые дополнительные команды в приглашении ASMCMD делают чрезвычайно легким управление экземпляром ASM. Одним из таких примеров является создание резервной копии метаданных, которое рассматривалось ранее. Другой примечательной возможностью является команда для проверки дисков, управляемых экземпляром. Это команда lsdsk.

ASMCMD> lsdsk

Path

/dev/raw/raw10

/dev/raw/raw11

/dev/raw/raw13

... snipped ...

ASMCMD> lsdsk -k

Total_MB  Free_MB  OS_MB  Name      Failgroup  Library  Label  UDID  Product  Redund   Path

     103       41    103  DG4_0000  DG4_0000   System                         UNKNOWN  /dev/raw/raw10

     103       41    103  DG5_0000  DG5_0000   System                         UNKNOWN  /dev/raw/raw11

... snipped ...

ASMCMD> lsdsk -s

 Reads   Write  Read_Errs  Write_Errs   Read_time  Write_Time  Bytes_Read  Bytes_Written  Path

207485  207916          0           0  245.820323  159.634398   851251200                 /dev/raw/raw10

207481  207912          0           0  229.996931   144.73954   851234816                 /dev/raw/raw11

ASMCMD> lsdsk -p

Group_Num  Disk_Num      Incarn  Mount_Stat  Header_Stat  Mode_Stat  State   Path

        4         0  3915926174  CACHED      MEMBER       ONLINE     NORMAL  /dev/raw/raw10

        5         0  3915926175  CACHED      MEMBER       ONLINE     NORMAL  /dev/raw/raw11

        6         0  3915926193  CACHED      MEMBER       ONLINE     NORMAL  /dev/raw/raw13

ASMCMD> lsdsk -t

Create_Date  Mount_Date  Repair_Timer  Path

27-SEP-07    28-SEP-07   0             /dev/raw/raw10

27-SEP-07    28-SEP-07   0             /dev/raw/raw11

28-SEP-07    28-SEP-07   0             /dev/raw/raw13

ASMCMD> lsdsk -Ik

Total_MB  Name      Failgroup  Path

     103  DG4_0000  DG4_0000   /dev/raw/raw10

     103  DG5_0000  DG5_0000   /dev/raw/raw11

     102  DG6_0000  DG6_0000   /dev/raw/raw13

ASMCMD> lsdsk -t -d dg1

Create_Date  Mount_Date  Repair_Timer  Path

28-SEP-07    28-SEP-07   0             /dev/raw/raw5

ASMCMD> lsdsk -t /dev/raw/raw1*

Create_Date  Mount_Date  Repair_Timer  Path

27-SEP-07    28-SEP-07   0             /dev/raw/raw10

27-SEP-07    28-SEP-07   0             /dev/raw/raw11

28-SEP-07    28-SEP-07   0             /dev/raw/raw13

28-SEP-07    05-OCT-07   0             /dev/raw/raw14

ASMCMD> help lsdsk

        lsdsk [-ksptcgHI] [-d <diskgroup_name>] [pattern]

Предположим, что вы добавили диск в дисковую группу. ASM немедленно запускает операцию перебалансирования. Эта операция работает в режиме реального времени, поэтому ASM через сложную систему блокировок должен согласовать с экземпляром СУБД  изменяемые блоки и блоки, к которым осуществляется доступ,. В базе данных RAC этот процесс осложняется тем, что необходимо управлять не только блокировками внутри базы данных, но и во всех экземплярах одновременно.

Что если вы добавляете диски в дисковую группу, которую никто не использует? Если бы ASM мог как-то знать об этом, он мог бы пренебречь механизмом блокирования и сделать процесс быстрее.

В Oracle Database 11 g возможен новый способ монтирования дисковых групп. Дисковая группа  может быть смонтирована предложением RESTRICT, как показано ниже:

alter diskgroup dg7 mount restricted;

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

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

В Oracle Database 11 g   поврежденный диск становился автономным (offline), и либо тот же самый диск, либо другой должен быть добавлен в дисковую группу. Когда добавляется новый диск, он должен быть полностью скопирован с уцелевшего диска, чтобы использоваться в качестве зеркала. Но если повреждено только несколько блоков, неэффективно копировать содержимое, скажем, 34GB памяти.

Поэтому в Oracle Database 11 g   восстанавливается только поврежденная часть диска вместо того, чтобы копировать весь диск. Эта возможность использует новый атрибут дисковой группы disk_ repair_ time , который определяет, как долго экземпляр ASM должен терпеть диск с ошибками перед тем, как удалить его из дисковой группы. Вот как можно установить значение 2 часа для этого атрибута дисковой группы DG2:

SQL> alter diskgroup dg2 set attribute 'disk_repair_time'='2H';

Допустим, что DG2 имеет два диска DISK1 и DISK2, и внезапно несколько блоков диска  DISK2 испортились. Поскольку время disk_ repair_ time составляет два часа, экземпляр ASM не удаляет диск немедленно, а ждет. Если обнаружить проблему диска DISK2 и снова сделать его работающим (online), то поврежденные блоки будут скопированы с уцелевшего диска.

Давайте рассмотрим это на примере. Предположим, что дисковая группа DG2 имеет две отказоустойчивые группы. Во-первых, проверим конфигурацию дисковой группы дисков:

ASMCMD [+dg2] > lsdg dg2

State    Type    Rebal  Sector  Block       AU  Total_MB  Free_MB  Req_mir_free_MB  Usable_file_MB  Offline_disks  Name

MOUNTED  NORMAL  N         512   4096  1048576       206       78                0              39              0  DG2/

Можно также использовать команду  du :

ASMCMD [+dg2] > du  

Used_MB      Mirror_used_MB

     11                  22

Команда  du подтверждает, что дисковая группа имеет 22MB, но используется только 11MB. Проверим теперь диски для группы dg2:

ASMCMD [+dg2] > lsdsk -d dg2

Path

/dev/raw/raw6

/dev/raw/raw7

Можно это подтвердить, а также получить имена дисков с помощью запроса:

SQL> select name, path 

  2  from v$asm_disk

  3  where group_number = 2

  4  /

NAME     PATH

-------- -----------------------------

DG2_0000 /dev/raw/raw7

DG2_0001 /dev/raw/raw6

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

$ dd if=/dev/zero of=/dev/raw/raw7 bs=1024 skip=10 count=1

Это повреждает один из дисков дисковой группы. Теперь выполним проверку дисковой группы, используя новую команду ALTER DISKGROUP ... CHECK.

SQL> alter diskgroup dg2 check

Если посмотреть журнал предупреждений (alert log) экземпляра ASM, то среди многих других строк можно заметить следующее:

...

NOTE: starting check of diskgroup DG2

WARNING: cache read a corrupted block gn=2 fn=3 indblk=1 from disk 0

...

NOTE: cache successfully reads gn 2 fn 3 indblk 1 count 15 from one mirror side

kfdp_checkDsk(): 89

...

NOTE: cache initiating offline of disk 0  group 2

WARNING: initiating offline of disk 0.3915926170 (DG2_0000) with mask 0x7e

...

WARNING: Disk (DG2_0000) will be dropped in: (7200) secs on ASM inst: (1)

...

Последняя строка говорит всё. Диск, который мы повредили, будет удален из дисковой группы через 7200 секунд, что соответствует двум часам, которые были заданы раньше в качестве времени ремонта. Пока это время идет, сообщение будет повторяться в журнале предупреждений:

...

WARNING: Disk (DG2_0000) will be dropped in: (5550) secs on ASM inst: (1)

GMON SlaveB: Deferred DG Ops completed.

Sat Oct 06 00:25:52 2007

WARNING: Disk (DG2_0000) will be dropped in: (5366) secs on ASM inst: (1)

GMON SlaveB: Deferred DG Ops completed.

Sat Oct 06 00:28:55 2007

WARNING: Disk (DG2_0000) will be dropped in: (5183) secs on ASM inst: (1)

GMON SlaveB: Deferred DG Ops completed.

Sat Oct 06 00:31:59 2007

WARNING: Disk (DG2_0000) will be dropped in: (5000) secs on ASM inst: (1)

GMON SlaveB: Deferred DG Ops completed.

...

Наконец, обратный отсчет достигнет 0, и диск будет удален, если только вы не решите проблему и  не выполните быстрый ремонт диска. Если известно, что диск не поддаётся ремонту и должен быть удалён быстрее, можно ускорить его удаление, дав команду:

SQL> alter diskgroup dg2 offline disks in failgroup dg2_0000 drop after 1m

Эта команда удаляет отказоустойчивую группу dg2_0000 через 1 минуту, позволяя вам либо физически извлечь диск, либо подключить другой диск к дисковой группе. Чтобы принудительно удалить диск:

SQL> alter diskgroup dg2 drop disks in failgroup dg2_0001 force;

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

SQL> alter diskgroup dg2 online disks in failgroup dg2_0001;

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

Oracle Database 11 g ASM стала еще более гибкой, мощной и простой в управлении. Теперь вы можете: убедиться, что дисковые группы читаются со всех узлов базы данных RAC; легко удалить диски, даже если они дефектные; быстрее выполнить восстановление; потребовать разместить меньшее число экстентов в разделяемом пуле, чтобы управлять большей памятью и так далее.