(495) 925-0049, ITShop интернет-магазин 229-0436, Учебный Центр 925-0049
  Главная страница Карта сайта Контакты
Поиск
Вход
Регистрация
Рассылки сайта
 
 
 
 
 

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

Источник: cyberguru

Новая роль 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, каждая из которых размещается на отдельном диске, как показано на рисунке:

Автоматическое управление памятью в Oracle 11g - Oracle - Базы данных - Программирование, исходники, операционные системы

Когда что-то записывается в дисковую группу 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; легко удалить диски, даже если они дефектные; быстрее выполнить восстановление; потребовать разместить меньшее число экстентов в разделяемом пуле, чтобы управлять большей памятью и так далее.

Ссылки по теме


 Распечатать »
 Правила публикации »
  Написать редактору 
 Рекомендовать » Дата публикации: 09.12.2009 
 

Магазин программного обеспечения   WWW.ITSHOP.RU
Oracle Database Standard Edition 2 Named User Plus License
Oracle Database Personal Edition Named User Plus License
Oracle Database Personal Edition Named User Plus Software Update License & Support
Oracle Database Standard Edition 2 Processor License
Allround Automation PL/SQL Developer Single user license
 
Другие предложения...
 
Курсы обучения   WWW.ITSHOP.RU
 
Другие предложения...
 
Магазин сертификационных экзаменов   WWW.ITSHOP.RU
 
Другие предложения...
 
3D Принтеры | 3D Печать   WWW.ITSHOP.RU
 
Другие предложения...
 
Новости по теме
 
Рассылки Subscribe.ru
Информационные технологии: CASE, RAD, ERP, OLAP
Безопасность компьютерных сетей и защита информации
Новости ITShop.ru - ПО, книги, документация, курсы обучения
Программирование на Microsoft Access
CASE-технологии
СУБД Oracle "с нуля"
Delphi - проблемы и решения
 
Статьи по теме
 
Новинки каталога Download
 
Исходники
 
Документация
 
 



    
rambler's top100 Rambler's Top100