Новая роль SYSASM для управления экземпляром ASM, переменный размер экстента для уменьшения использования разделяемого пула (shared pool) и возможность экземпляра читать с конкретного диска дисковой группы - вот лишь несколько замечательных новых возможностей, появившихся в базе данных Oracle 11g ASM.
Новая роль SYSASM для управления экземпляром ASM, переменный размер экстента для уменьшения использования разделяемого пула (shared pool) и возможность экземпляра читать с конкретного диска дисковой группы - вот лишь несколько замечательных новых возможностей, появившихся в базе данных Oracle 11g ASM.
Роль SYSASM
Появившееся в Oracle Database 11g автоматическое управление памятью (Automatic Storage Management - ASM) несколько размыло границу между администраторами баз данных (АБД) и системными администраторами в части их функций распределения памяти. Администраторы БД управляют экземплярами ASM, так же как они выполняют обычные свои работы, требующие присоединения в роли SYSDBA. Но по прошествии времени роли стали более четкими, и произошло элементарное разделение труда. В результате некоторые операции ASM вернулись к системным администраторам. В некоторых случаях образовался отдельный класс "администраторов ASM", которые занимались только администрированием ASM, а не базы данных.
Однако появление этого нового класса создает конфликт: чтобы управлять экземпляром ASM необходима роль SYSDBA, а многие администраторы промышленных баз данных, работающие на том же сервере, чувствуют себя некомфортно, разделяя эту роль.
В Oracle Database 11g этот конфликт изжит. Теперь существует новая роль 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 11g 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 10g AU и экстенты являются взаимозаменяемыми; один экстент состоит ровно из одной AU.
Дисковым группам, совместимым с 10g, требуется память в разделяемом пуле для каждого экстента. Для больших баз данных, соответственно, необходимо большое количество памяти. Поэтому, если размер AU составляет 1MB (это значение по умолчанию), то базе данных объемом 1TB потребуется разместить более одного миллиона экстентов в разделяемом пуле.
В Oracle Database 11g размеры экстентов больше не равны размерам AU. Когда файл создается, размер экстентов начинается с 1MB. После того, как файл достигнет определенного порога, размер экстента увеличивается до 4MB, затем до 16MB и, наконец, после некоторого порога размер экстента становится 64MB. Нет необходимости беспокоиться о размерах, экземпляр автоматически назначает соответствующий размер экстента. Поскольку меньшее количество экстентов может разместить большее количество данных, общее количество экстентов в разделяемом пуле существенно снижается, что улучшает производительность в несколько раз.
Переменные размеры экстентов могут вносить некоторую фрагментацию, когда файлы сильно расширяются и сокращаются. Если потребуется дефрагментация, ASM решит эту проблему автоматически.
Изменение размеров AU
Как я уже говорил, размер AU по умолчанию - 1 MB. Для многих баз данных этого достаточно, но рассмотрим большую базу данных, размером более 10 TB. Вероятно, объекты будут больше 1MB, поэтому можно увеличить размер AU, чтобы уменьшить их количество. В базе данных Oracle 10gнужно было установить заниженные параметры, чтобы изменить размер AU. Однако это влияло на все дисковые группы, которые создавались уже после этого, и также требовало перезапуска экземпляра ASM для установки параметра.
В Oracle Database 11g эта задача легко решается установкой атрибута дисковой группы -au_size - во время создания дисковой группы (diskgroup - DG), как показано ниже:
create diskgroup dg6
external redundancy
disk
'/dev/raw/raw13'
attribute 'au_size' = '2M'
AU_SIZE должен иметь одно из следующих значений: 1M, 2M, 4M, 8M, 16M, 32M, 64M (M означает MB). Можно также в качестве значения указать абсолютную величину в байтах:
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 начиная с 10g до текущей версии. Поэтому экземпляр ASM может хранить базы данных 10g Release 1, 10g Release 2, 11g Release 1 (и далее). Пока версия ASM та же или выше, чем версия СУБД, есть возможность создавать базу данных на этом экземпляре ASM. Итак, как взаимодействует ASM с экземпляром СУБД, если они разных версий? Просто: ASM преобразует сообщения, чтобы соответствовать версии СУБД.
По умолчанию экземпляр ASM поддерживает базы данных 10g. Но что произойдеть, если необходимо разместить только СУБД версии 11g в этом экземпляре ASM? Тогда отпадает необходимость преобразования сообщений для поддержки разницы версий. Вот если бы был способ сказать экземпляру ASM, что все поддерживаемые базы данных имеют версию 11g Release 1. Это устранило бы или, по крайней мере, уменьшило преобразование сообщений. В Oracle Database 11g это возможно, благодаря атрибутам дисковой группы 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.
Если необходимо создавать только структуры 11g ASM и СУБД, то нет необходимости иметь элементы 10g. Чтобы установить атрибут 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 11g можно сконфигурировать узел так, чтобы читать из конкретной отказоустойчивой группы. Например, если необходимо в приведенном ранее примере сконфигурировать экземпляр 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 10g можно использовать обходной путь: стереть заголовок диска с помощью команды dd:
$ dd if=/dev/zero of=/dev/raw/raw13 bs=1024 count=4
Эта команда ставит нули в заголовке диска /dev/raw/raw13, стирая всю информацию. После выполнения этой команды стирается вся информация в заголовке диска полностью, включая тот факт, что диск был частью дисковой группы.
В Oracle Database 11g нет необходимости прибегать к такому обходному пути. Все что нужно сделать это выполнить команду drop с опцией force:
SQL> drop diskgroup dg7 force including contents;
Эта команда удаляет дисковую группу, даже если диски не смонтированы. Доступные диски показываются как FORMER; что означает, что они были частью какой-то дисковой группы. (Примечание: необходимо использовать предложение "including contents".)
Создание резервной копии и восстановление метаданных
Многие люди считают ASM базой данных со своей собственной памятью. Это не совсем так - ASM не хранит данные; их хранит база данных. Однако экземпляр ASM хранит метаданные, такие как имена дисковых групп; диски, входящие в них; директории и т.д. Эти метаданные хранятся в заголовках дисков.
Предположим, что все диски разрушены и информация из заголовков исчезла. Что делать? Конечно, вы сделали резервную копию базы данных, используя RMAN, и можете восстановить её. Но её можно будет восстановить только после того, как будут созданы все дисковые группы и директории. Надеюсь, у вас есть записи обо всем этом. (Верно?) Даже если есть, этот процесс требует времени.
Что, если бы у вас была резервная копия? В Oracle Database 11g можно создать резервную копию метаданных экземпляра ASM с помощью командной строки ASM (ASMCMD), используя команду md_backup.
$ asmcmd -p
ASMCMD [+] > md_backup
Создается файл с именем ambr_backup_intermediate_file. Вот фрагмент этого файла с самого начала:
@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/
Дисковая группа имеет директорию с именем TEST. Теперь создадим резервную копию дисковой группы:
ASMCMD [+] > md_backup -g dg7 -b g7.backup
После этого удалим дисковую группу, чтобы смоделировать случайное удаление:
SQL> drop diskgroup dg7;
Diskgroup dropped.
Теперь дисковая группа DG7 исчезла из экземпляра ASM и необходимо восстановить её из резервной копии. Это можно сделать, используя команду md_restore:
$ 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 11g некоторые дополнительные команды в приглашении ASMCMD делают чрезвычайно легким управление экземпляром ASM. Одним из таких примеров является создание резервной копии метаданных, которое рассматривалось ранее. Другой примечательной возможностью является команда для проверки дисков, управляемых экземпляром. Это команда lsdsk.
ASMCMD> lsdsk
Path
/dev/raw/raw10
/dev/raw/raw11
/dev/raw/raw13
... snipped ...
Без всяких флагов команда просто перечисляет все диски, доступные в экземпляре. Существует несколько флагов, которые изменяют выходные данные. Наиболее общим является флаг -k, как показано ниже:
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 ...
Другой флаг -s показывает различную статистику дисков, связанную с вводом/выводом:
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
Для быстрой проверки состояния дисков можно использовать флаг -p:
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
Наконец, флаг -t показывает информацию, связанную с ремонтами (описывается далее в этой статье):
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 извлекала значения из различных V$-представлений в экземпляре ASM. Но метаданные хранятся непосредственно на диске. Если экземпляр недоступен, то должен быть способ извлечь эту информацию с дисков. В базе данных Oracle 11g, команда lsdsk имеет флаг "I" (заглавное "I", а не строчное "L"), который извлекает информацию из заголовков дисков, а не из V$-представлений. Вот пример такого использования флага "I" вместе с флагом -k, извлекающего информацию из заголовков дисков.
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
Чтобы просмотреть диски конкретной дисковой группы, скажем, DG1, можно использовать флаг -d, как показано ниже:
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
При этом показываются только диски, соответствующие шаблону. Наконец, нет необходимости помнить эти опции; команда help покажет все опции:
ASMCMD> help lsdsk
lsdsk [-ksptcgHI] [-d <diskgroup_name>] [pattern]
Команда lsdsk предоставляет более передовые возможности управления памятью в мире ASM.
Монтирование с предложением RESTRICT
Предположим, что вы добавили диск в дисковую группу. ASM немедленно запускает операцию перебалансирования. Эта операция работает в режиме реального времени, поэтому ASM через сложную систему блокировок должен согласовать с экземпляром СУБД изменяемые блоки и блоки, к которым осуществляется доступ,. В базе данных RAC этот процесс осложняется тем, что необходимо управлять не только блокировками внутри базы данных, но и во всех экземплярах одновременно.
Что если вы добавляете диски в дисковую группу, которую никто не использует? Если бы ASM мог как-то знать об этом, он мог бы пренебречь механизмом блокирования и сделать процесс быстрее.
В Oracle Database 11g возможен новый способ монтирования дисковых групп. Дисковая группа может быть смонтирована предложением RESTRICT, как показано ниже:
alter diskgroup dg7 mount restricted;
Когда дисковая группа монтируется таким образом, экземпляр ASM знает об исключительности этой операции на основных дисках и минимизирует механизм блокировки. Это, в свою очередь, позволяет быстрее выполняться дисковым операциям, таким как перебалансирование.
Быстрое восстановление в случае сбоя
Рассмотрим дисковую группу DG2 с двумя отказоустойчивыми группами, каждая из одного диском. Когда повреждена некая область одного из дисков, это не фатально для всей дисковой группы. Поскольку они зеркально отображаются, поврежденные экстенты будут прочитаны с другого уцелевшего диска и операция продолжится. Но что произойдет с поврежденной частью диска?
В Oracle Database 11g поврежденный диск становился автономным (offline), и либо тот же самый диск, либо другой должен быть добавлен в дисковую группу. Когда добавляется новый диск, он должен быть полностью скопирован с уцелевшего диска, чтобы использоваться в качестве зеркала. Но если повреждено только несколько блоков, неэффективно копировать содержимое, скажем, 34GB памяти.
Поэтому в Oracle Database 11g восстанавливается только поврежденная часть диска вместо того, чтобы копировать весь диск. Эта возможность использует новый атрибут дисковой группы 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
Это повреждает один из дисков дисковой группы. Теперь выполним проверку дисковой группы, используя новую команду ALTERDISKGROUP ... 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 11g ASM стала еще более гибкой, мощной и простой в управлении. Теперь вы можете: убедиться, что дисковые группы читаются со всех узлов базы данных RAC; легко удалить диски, даже если они дефектные; быстрее выполнить восстановление; потребовать разместить меньшее число экстентов в разделяемом пуле, чтобы управлять большей памятью и так далее.