Материалов на эту тему достаточно много: документация, WP, форумы... Есть интересные ссылки на документы от Oracle, на форумах обсуждается магический “REDO RATE”. Но, как вычислить этот Redo Rate ? Есть мнение: http://forums.oracle.com/forums/thread.jspa?messageID=4556370&tstart=0
Required bandwidth = ((Redo rate bytes per sec. / 0.7) * 8) / 1,000,000 = bandwidth in Mbps
Тем не менее, пошаговой инструкции или рецепта так и не нашел. Основной документ, который я использовал: «Data Guard Redo Transport & Network Best Practices
Oracle Database 10g Release 2» http://www.oracle.com/technetwork/database/features/availability/maa-wp-10gr2-dataguardnetworkbestpr-134557.pdf
В нем раскрываются основные принципы и подход по расчету. Основной раздел так и называется «How Much Bandwidth is Enough?». Информация в документе актуальна и для 11g.
Итак, переходим непосредственно к расчету. Расчет производим в два шага:
1) Определение среднего объема REDO/sec и перевод его в Mbit/sec.
2) Учет пиковых значений по генерации REDO, удаленности ЦОД-ов – влияет на задержки и т.д.
Шаг 1
1) Собираем AWR отчет за сутки или более (зависит от топологии работы приложения)
2) Беру значение "redo blocks written" в колонке "per Second"
3) Не забываем, что размер REDO блока 512 байт (на HP-UX 1KB)
4) Далее переводим в Mbit/sec , используя формулу.
1 мегабит = 1048576 бит = 131072 байт = 128 КБайт
итого, в моем случае: «значение из AWR отчета» * (512) / 131072 = «искомое значение» Mbit/sec
Шаг 2
Этот шаг является необязательным и ведет к увеличению требований к каналу связи между дата центрами. В результате, как правило, стоимость канала увеличивается. Далее, вы должны принять для себя решение будете ли учитывать пики нагрузки и задержки сети при значительном удалении ЦОД-ов. Цена, в большинстве проектов, является ключевым фактором для принятия решения.
PS:
Также, в AWR отчете есть значение "Redo size" в колонке "per Second", раздел "Load Profile" в байтах. Но это абсолютное значение для REDO, без учета того, что блок, записанный на диск с REDO информацией может быть не обязательно заполненным на 100%. Поэтому рекомендуется использовать способ описанный выше.
Дополнительные ссылки по теме: «Data Guard Redo Apply and Media Recovery Best Practices
Oracle Database 10g Release 2»
http://www.oracle.com/technetwork/database/features/availability/maa-wp-10gr2-recoverybestpractices-131010.pdf
Описание параметров в AWR отчете: http://download.oracle.com/docs/cd/E11882_01/server.112/e17110/stats002.htm#i375475
28 мая 2011 г.
20 мая 2011 г.
Shadow-сервисы в Oracle RAC 11.2
В Real Application Cluster версии 11.2 появился интересный тип сервисов - так называемые preconnect-сервисы. Мне больше нравится определение их как "теневых" (shadow).
Теневой сервис автоматически создается при создании основного сервиса, если вы укажете ключ -P PRECONNECT:
После создания сервиса OLTP автоматически будет создан сервис OLTP_PRECONNECT:
Теневой сервис, при старте основного сервиса, автоматически запускается на резервных узлах. Поэтому shadow-сервис может существовать только тогда, когда у основного сервиса определены и "живы" резервные узлы:
Теперь проделаем интересный эксперимент: принудительно переместим наш сервис OLTP на узел rac2
обратите внимание, что теневой сервис oltp_preconnect переехал на узел rac1, то есть произошел своеобразный "Switсh Over"!
При остановке основного сервиса, теневой сервис также автоматически останавливается.
Как использовать теневые сервисы на клиенте ?
К сожалению, пока клиент не понимает их наличие и нужно его явно конфигурировать в backup-соединении в файле tnsnames.ora:
Сделаем тестовое соединение и проверим как распределяются сессии:
Как видите, соединение было сделано к основному сервису (первый узел), а резервное - к теневому сервису (второй узел).
Теневой сервис автоматически создается при создании основного сервиса, если вы укажете ключ -P PRECONNECT:
rac1-> srvctl add service -d racdb -s OLTP -P PRECONNECT -r "racdb1" -a "racdb2"
После создания сервиса OLTP автоматически будет создан сервис OLTP_PRECONNECT:
rac1-> crs_stat -p | grep oltp
NAME=ora.racdb.oltp.svc
NAME=ora.racdb.oltp_preconnect.svc
rac1->
Теневой сервис, при старте основного сервиса, автоматически запускается на резервных узлах. Поэтому shadow-сервис может существовать только тогда, когда у основного сервиса определены и "живы" резервные узлы:
rac1-> crs_stat
... ... ...
NAME=ora.racdb.oltp.svc
TYPE=ora.service.type
TARGET=ONLINE
STATE=ONLINE on rac1
NAME=ora.racdb.oltp_preconnect.svc
TYPE=ora.service.type
TARGET=ONLINE
STATE=ONLINE on rac2
... ... ...
Теперь проделаем интересный эксперимент: принудительно переместим наш сервис OLTP на узел rac2
rac1-> srvctl relocate service -d racdb -s OLTP -i racdb1 -t racdb2 -f
rac1-> crs_stat
... ... ...
NAME=ora.racdb.oltp.svc
TYPE=ora.service.type
TARGET=ONLINE
STATE=ONLINE on rac2
NAME=ora.racdb.oltp_preconnect.svc
TYPE=ora.service.type
TARGET=ONLINE
STATE=ONLINE on rac1
... ... ...
обратите внимание, что теневой сервис oltp_preconnect переехал на узел rac1, то есть произошел своеобразный "Switсh Over"!
При остановке основного сервиса, теневой сервис также автоматически останавливается.
Как использовать теневые сервисы на клиенте ?
К сожалению, пока клиент не понимает их наличие и нужно его явно конфигурировать в backup-соединении в файле tnsnames.ora:
OLTP =
(DESCRIPTION =
(FAILOVER=YES)
(ADDRESS = (PROTOCOL = TCP)(HOST = rac-scan)(PORT = 1521))
(CONNECT_DATA =
(SERVICE_NAME = oltp.rac.com)
(FAILOVER_MODE=
(BACKUP=OLTP_PRECONNECT)
(TYPE=SELECT)
(METHOD=PRECONNECT)
)
)
)
OLTP_PRECONNECT =
(DESCRIPTION =
(ADDRESS = (PROTOCOL = TCP)(HOST = rac-scan)(PORT = 1521))
(CONNECT_DATA =
(SERVICE_NAME = oltp_preconnect.rac.com)
)
)
Сделаем тестовое соединение и проверим как распределяются сессии:
C:\Work\RACDD4D\v3.1>sqlplus rscott/rtiger@oltp
SQL*Plus: Release 11.2.0.2.0 Production on Fri May 20 21:55:45 2011
Copyright (c) 1982, 2010, Oracle. All rights reserved.
Connected to:
Oracle Database 11g Enterprise Edition Release 11.2.0.2.0 - Production
With the Partitioning, Real Application Clusters, Automatic Storage Management, and Real Application Testing options
SQL> SELECT inst_id FROM gv$session WHERE username='RSCOTT' and program='sqlplus.exe';
INST_ID
----------
1
2
SQL> select dbms_utility.current_instance from dual;
CURRENT_INSTANCE
----------------
1
Как видите, соединение было сделано к основному сервису (первый узел), а резервное - к теневому сервису (второй узел).
19 мая 2011 г.
srvctl support TAF
В версии Oracle Database 11.2 утилита srvctl стала поддерживать определение TAF-policy на уровне сервиса, то есть теперь при создании сервиса вы также сразу можете определить политики TAF:
Обратите внимание что вы также можете сразу задать Runtime-балансировку для сервиса!
Создаем сервис (SELECT и BASIC):
На клиенте в файле tnsnames.ora определяем алиас для сервиса DSS (ни слова про настройки TAF - все берется из серверной политики!):
подключаемся к БД по данному сервису и проверяем TAF-политику:
Все работает !
rac1-> srvctl add service -help
... ... ...
-P {NONE | BASIC | PRECONNECT} TAF policy specification
-l Role of the service (primary, physical_standby, logical_standby, snapshot_standby)
-y Management policy for the service (AUTOMATIC or MANUAL)
-e Failover type (NONE, SESSION, or SELECT)
-m Failover method (NONE or BASIC)
-w Failover delay
-z Failover retries
-j Connection Load Balancing Goal (SHORT or LONG). Default is LONG.
-B Runtime Load Balancing Goal (SERVICE_TIME, THROUGHPUT, or NONE)
... ... ...
Обратите внимание что вы также можете сразу задать Runtime-балансировку для сервиса!
Создаем сервис (SELECT и BASIC):
rac1-> srvctl add service -d racdb -s DSS -e SELECT -p BASIC -w 5 -z 3 -r "racdb1,racdb2"
rac1-> srvctl start service -d racdb -s DSS
На клиенте в файле tnsnames.ora определяем алиас для сервиса DSS (ни слова про настройки TAF - все берется из серверной политики!):
DSS =
(DESCRIPTION =
(ADDRESS = (PROTOCOL = TCP)(HOST = rac-scan)(PORT = 1521))
(CONNECT_DATA =
(SERVER = DEDICATED)
(SERVICE_NAME = dss.rac.com)
)
)
подключаемся к БД по данному сервису и проверяем TAF-политику:
[oracle@racc ~]$ sqlplus rscott/rtiger@dss
SQL*Plus: Release 11.2.0.2.0 - Production on Wed May 18 18:59:27 2011
Copyright (c) 1982, 2010, Oracle. All rights reserved.
Connected to:
Oracle Database 11g Enterprise Edition Release 11.2.0.2.0 - Production
With the Partitioning, Real Application Clusters, Automatic Storage Management, OLAP,
Data Mining and Real Application Testing options
SQL> select FAILOVER_TYPE, FAILOVER_METHOD from v$session where sid=sys_context ('userenv', 'sid');
FAILOVER_TYPE FAILOVER_M
------------- ----------
SELECT BASIC
SQL>
Все работает !
13 мая 2011 г.
Ускорение "1С:Предприятие for Oracle" за счет сжатия таблиц
Кроме выступления Вадима Гусева на мероприятии "Модернизация системы управления бизнесом с помощью ERP-решений 1С с помощью инновационной технологической платформы Oracle" Андрей Забелин демонстрировал возможности OLTP-сжатия для увеличения производительности одного из бухгалтерских отчётов приложения "1С:Предприятие 8.2".
Ролик можно посмотреть здесь.
Как это ни странно на первый взгляд: при сжатии не только уменьшается объем данных на диске, но и возрастает скорость выполнения запроса !
Это происходит за счет уменьшения ввода-вывода (СУБД меньше читает и пишет на диск), а это самая ресурсоёмкая операция. И это происходит не на каком-то искусственном тесте, а в реальном приложении !
Программное окружение было аналогичным как в демонстрации Вадима.
Сервер приложений "1C:Предприятие" также работал под управлением ОС Oracle Linux x64 5U6.
Основная идея демонстрации – показать:
Поскольку Андрей (как и все мы впрочем) не является специалистом в бухгалтерском учёте, выбранный отчёт «Анализ субконто» и параметры этого отчёта могут показаться опытному бухгалтеру некорректными, но цель была одна - нагрузить БД таким образом, чтобы набор обрабатываемых данных был наибОльшим в тестовой БД.
К сожалению, в текущей версии "1С:Предприятие" не поддерживается настройка сжатия данных таблицы через интерфейс самой 1С, что приводит к возможной потери этой настройки при обновлении конфигурации 1С, но это уже совсем другая история ... Следите за следующими публикациями !
Приятного просмотра!
Cсылка: видео.
Ролик можно посмотреть здесь.
Как это ни странно на первый взгляд: при сжатии не только уменьшается объем данных на диске, но и возрастает скорость выполнения запроса !
Это происходит за счет уменьшения ввода-вывода (СУБД меньше читает и пишет на диск), а это самая ресурсоёмкая операция. И это происходит не на каком-то искусственном тесте, а в реальном приложении !
Программное окружение было аналогичным как в демонстрации Вадима.
Сервер приложений "1C:Предприятие" также работал под управлением ОС Oracle Linux x64 5U6.
Основная идея демонстрации – показать:
- Возможности Enterprise Manager для быстрого обнаружения ресурсоёмкого SQL-запроса, который являлся причиной долгого выполнения одного из бухгалтерских отчётов приложения "1С:Предприятие 8.2";
- Быстрота и удобство анализа плана SQL-запроса;
- Удобство навигации от плана запроса к редактированию свойств таблицы;
- Эффективность сжатия данных с помощью Advanced Compression, которое позволяет не только уменьшить объём данных на диске, но и значительно ускорить выполнение запроса за счёт уменьшения количества обрабатываемых блоков.
Поскольку Андрей (как и все мы впрочем) не является специалистом в бухгалтерском учёте, выбранный отчёт «Анализ субконто» и параметры этого отчёта могут показаться опытному бухгалтеру некорректными, но цель была одна - нагрузить БД таким образом, чтобы набор обрабатываемых данных был наибОльшим в тестовой БД.
К сожалению, в текущей версии "1С:Предприятие" не поддерживается настройка сжатия данных таблицы через интерфейс самой 1С, что приводит к возможной потери этой настройки при обновлении конфигурации 1С, но это уже совсем другая история ... Следите за следующими публикациями !
Приятного просмотра!
Cсылка: видео.
9 мая 2011 г.
Условная компиляция в SQL+
Оказывается с помощью хитрого трюка с переменными замены SQL*Plus (substitution variables) можно делать условную компиляцию не только на сервере - в движке PL/SQL, но и на клиенте:
В чем разница по сравнению с PL/SQL Conditional Compilation ?
В данном случае код просто будет в виде комментария.
К сожалению, подобное можно сделать только в блоке PL/SQL, но не в потоке DDL-команд: SQL+ обрабатывает переменные замены только в составе какого-либо оператора. Если Вы знаете как это обойти, пожалуйста дайте мне знать об этом!
:-)
На фото - до боли знакомый графический SQL+, как его нам не хватает сегодня в 11g ...
:-)
--Включаем трассировку
define is_client_trace="--"
begin
&is_client_trace
dbms_output.put_line('Код включаемый для трассировки');
--*/
dbms_output.put_line('Оcновная логика ...');
end;
В чем разница по сравнению с PL/SQL Conditional Compilation ?
В данном случае код просто будет в виде комментария.
--Выключаем трассировку
define is_client_trace=/*
begin
&is_client_trace
dbms_output.put_line('"Этот код будет в виде комментария');
--*/
dbms_output.put_line('Оcновная логика ...');
end;
К сожалению, подобное можно сделать только в блоке PL/SQL, но не в потоке DDL-команд: SQL+ обрабатывает переменные замены только в составе какого-либо оператора. Если Вы знаете как это обойти, пожалуйста дайте мне знать об этом!
:-)
На фото - до боли знакомый графический SQL+, как его нам не хватает сегодня в 11g ...
:-)
5 мая 2011 г.
Защита "1С:Предприятие" с помощью Oracle Clusterware
Не так давно (27 апреля 2011), состоялось мероприятие «Модернизация системы управления бизнесом с помощью ERP-решений 1С с помощью инновационной технологической платформы Oracle». На нем я показывал возможность защиты приложения "1С:Предприятие 8.2" с помощью Oracle Clusterware.
Ролик можно посмотреть здесь.
Программное обеспечение, которое было использовано в демонстрации:
Все ПО работало в виртуальной инфраструктуре от Oracle:
Основная идея – показать возможности Oracle Clusterware для защиты приложений. В качестве испытуемого приложения было "1С:Предприятие".
Демонстрация разбита на две части. Первая, где показывается возможности Failover для Базы данных Oracle и 1C. Вторая - в ней показано поведение клиентского приложения в случае сбоя. Оба сервиса управлялись Oracle Clusterware.
Посмотрев ролик до конца, вы заметите, что при Failover сервиса 1С, или переезде экземпляра БД на другой узел (я использовал Oracle RAC One Node, а не Failover Cluster), пользователю приходилось заново рестартовать клиентское приложение.
Да,- к сожалению, в текущей версии 1С:Предприятие не обрабатывается потеря текущей транзакции при TAF, но важно другое: работоспособность системы, к тому моменту, когда пользователь создает новое соединение, уже восстановлена. Т.е. данная конфигурация , прежде всего, создана для снижения времени простоя самого приложения и БД.
Особенности конфигурации:
Бинарные файлы Oracle (ORACLE_HOME) и 1С расположены на разделяемом разделе ASM File System.
При настройке Oracle Clusterware я использовал зависимости между ресурсами. Для того, чтобы была возможность запускать на различных узлах кластера экземпляр БД и приложение 1С , я создал два виртуальных IP-адреса [VIP]. При описании ресурса , установил HARD DEPENDENCY на старт application-ресурса.
Демонстрация готовилась вместе с Андреем Забелиным, за что ему большое спасибо.
Приятного просмотра!
Cсылка: видео.
Ролик можно посмотреть здесь.
Программное обеспечение, которое было использовано в демонстрации:
- Oracle Enterprise Linux 5U6 x86
- Oracle Database 11gR2 (11.2.0.2)
- Oracle Enterprise Manager Database Control 11gR2
- 1C:Предприятие 8.2 for Oracle
Все ПО работало в виртуальной инфраструктуре от Oracle:
- Oracle VM Server 2.2.1
- Oracle VM Manager
Основная идея – показать возможности Oracle Clusterware для защиты приложений. В качестве испытуемого приложения было "1С:Предприятие".
Демонстрация разбита на две части. Первая, где показывается возможности Failover для Базы данных Oracle и 1C. Вторая - в ней показано поведение клиентского приложения в случае сбоя. Оба сервиса управлялись Oracle Clusterware.
Посмотрев ролик до конца, вы заметите, что при Failover сервиса 1С, или переезде экземпляра БД на другой узел (я использовал Oracle RAC One Node, а не Failover Cluster), пользователю приходилось заново рестартовать клиентское приложение.
Да,- к сожалению, в текущей версии 1С:Предприятие не обрабатывается потеря текущей транзакции при TAF, но важно другое: работоспособность системы, к тому моменту, когда пользователь создает новое соединение, уже восстановлена. Т.е. данная конфигурация , прежде всего, создана для снижения времени простоя самого приложения и БД.
Особенности конфигурации:
Бинарные файлы Oracle (ORACLE_HOME) и 1С расположены на разделяемом разделе ASM File System.
При настройке Oracle Clusterware я использовал зависимости между ресурсами. Для того, чтобы была возможность запускать на различных узлах кластера экземпляр БД и приложение 1С , я создал два виртуальных IP-адреса [VIP]. При описании ресурса , установил HARD DEPENDENCY на старт application-ресурса.
Демонстрация готовилась вместе с Андреем Забелиным, за что ему большое спасибо.
Приятного просмотра!
Cсылка: видео.
4 мая 2011 г.
OPatch 11.2.0.1.5 Automation
Очень полезная возможность появилась в утилите установки патчей - OPatch: теперь она может за один проход читать информацию из inventory и "накатывать" патчи на несколько ORACLE_HOME-ов, при этом конечно-же проверяется сама возможность установки патча.
На одном из моих серверов (под управлением Oracle Linux 5U6 x64) установлено два каталога $O_H:
Согласно своей стратегии патчинга я решил установить на него Grid Infrastructure 11.2.0.2.2 PSU (включает в себя Database PSU 11.2.0.2.2).
Патч кстати, довольно серьезный - весит 740 Mb.
0) Делаем полную копию БД и всех ORACLE_HOME-s (включая inventory)
1) Скачиваем и устанавливаем OPatch 11.2.0.1.5
2) Скачиваем и распаковываем Grid Infrastructure 11.2.0.2.2 PSU
3) Создаем response file для Oracle Configuration Manager [OCM].
Если Вы уже используете OCM то вы можете пропустить шаг. Утилита OPatch в любом случае запросит этот rsp-файл.
4) Останавливаем БД.
5) Накатываем патч сразу на все ORACLE_HOME-ы (как пользователь root!)
Обратите внимание, что мне не пришлось останавливать компоненты Clusterware: все автоматически проделала утилита OPatch
OPatch продолжает развиваться и стал значительно умнее!
:-)
На одном из моих серверов (под управлением Oracle Linux 5U6 x64) установлено два каталога $O_H:
- - Grid Infrastructure 11.2.0.2 (ASM и Oracle Restart)
- Database 11.2.0.2
Согласно своей стратегии патчинга я решил установить на него Grid Infrastructure 11.2.0.2.2 PSU (включает в себя Database PSU 11.2.0.2.2).
Патч кстати, довольно серьезный - весит 740 Mb.
0) Делаем полную копию БД и всех ORACLE_HOME-s (включая inventory)
1) Скачиваем и устанавливаем OPatch 11.2.0.1.5
[oracle@ais3 ~]$ cd /u01/app/oracle/product/11.2.0/dbhome_1/
[oracle@ais3 ~]$ rm -rf OPatch/
[oracle@ais3 ~]$ cp /mnt/p6880880_112000_Linux-x86-64.zip ./
[oracle@ais3 ~]$ unzip p6880880_112000_Linux-x86-64.zip
[oracle@ais3 ~]$ cd /u01/app/11.2.0/grid/
[oracle@ais3 ~]$ rm -rf OPatch/
[oracle@ais3 ~]$ cp /mnt/p6880880_112000_Linux-x86-64.zip ./
[oracle@ais3 ~]$ unzip p6880880_112000_Linux-x86-64.zip
2) Скачиваем и распаковываем Grid Infrastructure 11.2.0.2.2 PSU
[oracle@ais3]$ cd /u01/app/oracle/install/
[oracle@ais3]$ cp /mnt/p12311357_112020_Linux-x86-64.zip ./
[oracle@ais3]$ unzip p12311357_112020_Linux-x86-64.zip
3) Создаем response file для Oracle Configuration Manager [OCM].
Если Вы уже используете OCM то вы можете пропустить шаг. Утилита OPatch в любом случае запросит этот rsp-файл.
[oracle@ais3]$ /u01/app/11.2.0/grid/OPatch/ocm/bin/emocmrsp
OCM Installation Response Generator 10.3.4.0.0 - Production
Copyright (c) 2005, 2010, Oracle and/or its affiliates. All rights reserved.
Provide your email address to be informed of security issues, install and
initiate Oracle Configuration Manager. Easier for you if you use your My
Oracle Support Email address/User Name.
Visit http://www.oracle.com/support/policies.html for details.
Email address/User Name: [ENTER]
You have not provided an email address for notification of security issues.
Do you wish to remain uninformed of security issues ([Y]es, [N]o) [N]: Y
The OCM configuration response file (ocm.rsp) was successfully created.
[oracle@ais3 ~]$ ls /home/oracle
dbenv dbenv~ gienv gienv~ ocm.rsp oradiag_oracle
4) Останавливаем БД.
[oracle@ais3~]$ srvctl stop database -d ais3
5) Накатываем патч сразу на все ORACLE_HOME-ы (как пользователь root!)
[oracle@ais3~]$ su - root
Password: oracle
[root@ais3]# export PATH=/u01/app/11.2.0/grid/OPatch:$PATH
[root@ais3 ~]# opatch auto /u01/app/oracle/install/
Executing /usr/bin/perl /u01/app/11.2.0/grid/OPatch/crs/patch112.pl -patchdir /u01/app/oracle -patchn install -paramfile /u01/app/11.2.0/grid/crs/install/crsconfig_params
opatch auto log file location is /u01/app/11.2.0/grid/OPatch/crs/../../cfgtoollogs/opatchauto2011-05-04_22-21-07.log
Detected Oracle Restart install
Using configuration parameter file: /u01/app/11.2.0/grid/crs/install/crsconfig_params
OPatch is bundled with OCM, Enter the absolute OCM response file path:
/home/oracle/ocm.rsp
patch /u01/app/oracle/install/12311357/custom/server/12311357 apply successful for home /u01/app/oracle/product/11.2.0/dbhome_1
patch /u01/app/oracle/install/11724916 apply successful for home /u01/app/oracle/product/11.2.0/dbhome_1
Successfully unlock /u01/app/11.2.0/grid
patch /u01/app/oracle/install/12311357 apply successful for home /u01/app/11.2.0/grid
patch /u01/app/oracle/install/11724916 apply successful for home /u01/app/11.2.0/grid
ACFS-9300: ADVM/ACFS distribution files found.
ACFS-9312: Existing ADVM/ACFS installation detected.
ACFS-9314: Removing previous ADVM/ACFS installation.
ACFS-9315: Previous ADVM/ACFS components successfully removed.
ACFS-9307: Installing requested ADVM/ACFS software.
... ... ... ... ... ... ... ... ... ... ... ...
CRS-4123: Oracle High Availability Services has been started.
[root@ais3 ~]#
Обратите внимание, что мне не пришлось останавливать компоненты Clusterware: все автоматически проделала утилита OPatch
OPatch продолжает развиваться и стал значительно умнее!
:-)
3 мая 2011 г.
ASM and thin provisioning
В среде систем хранения корпоративного класса широкое распространение получила технология Thin Provisioning. Это технология позволяющая с стороны системы хранения выделять приложению столько емкости, сколько ему нужно в данный момент времени. У каждого производителя storage эта технология имеет особенности. Вот например, очень подробное описание этой технологии в массивах NetApp.
В случае использования ASM возникает проблема так называемого "Space Reclamation" - возврата неиспользуемого пространства в пул системы хранения.
Например: Вы удалили большой "холодный" бэкап с ASM группы, которая в свою очередь находится на thin-provisioning разделе системы хранения, и хотите использовать освободившееся дисковое пространство для других целей. Но как система хранения узнает, о том что это область хостом уже не используется и его нужно вернуть в пул свободного пространства ?
Для решения данной проблемы была выпущена отдельная утилита -
ASM Storage Reclamation Utility
Скачать ее можно с OTN.
Принцип действия ASRU очень простой: она просто записывает нулями свободное пространство на заданной группе ASM, и далее массив может "понять" о том, что эта область дискового пространства свободна и ее можно использовать для других целей.
Другое очень полезное применение утилиты ASRU - сжатие thin-дисков виртуальных машин: вначале обрабатываем раздел утилитой ASRU, а затем проводим сжатие (shrink) диска с помощью соответствующей утилиты гипервизора.
Например:
мне нужно сжать vmdk-файл otafra.vmdk размер которого составляет 4596M,
диск создан в VMware как thin c максимальным размером 20Gb, в этом файле соответственно расположена ASM-группа FRA виртуальной машины.
1) Из окружения Grid Infrastructure запускаем утилиту ASRU:
2) На хост-машине сжимаем диск с помощью утилиты vmware-vdiskmanager
3) Виртуальную машину можно архивировать: теперь размер файла orafra.vmdk составляет всего 280Mb!
Здесь приведены очень подробные примеры использования утилиты ASRU для массивов 3par и EMC Simmetrix
В случае использования ASM возникает проблема так называемого "Space Reclamation" - возврата неиспользуемого пространства в пул системы хранения.
Например: Вы удалили большой "холодный" бэкап с ASM группы, которая в свою очередь находится на thin-provisioning разделе системы хранения, и хотите использовать освободившееся дисковое пространство для других целей. Но как система хранения узнает, о том что это область хостом уже не используется и его нужно вернуть в пул свободного пространства ?
Для решения данной проблемы была выпущена отдельная утилита -
ASM Storage Reclamation Utility
Скачать ее можно с OTN.
Принцип действия ASRU очень простой: она просто записывает нулями свободное пространство на заданной группе ASM, и далее массив может "понять" о том, что эта область дискового пространства свободна и ее можно использовать для других целей.
Другое очень полезное применение утилиты ASRU - сжатие thin-дисков виртуальных машин: вначале обрабатываем раздел утилитой ASRU, а затем проводим сжатие (shrink) диска с помощью соответствующей утилиты гипервизора.
Например:
мне нужно сжать vmdk-файл otafra.vmdk размер которого составляет 4596M,
диск создан в VMware как thin c максимальным размером 20Gb, в этом файле соответственно расположена ASM-группа FRA виртуальной машины.
1) Из окружения Grid Infrastructure запускаем утилиту ASRU:
[oracle@ais3 asru]$ ./ASRU fra
Checking the system ...done
Calculating the new sizes of the disks ...done
Writing the data to a file ...done
Resizing the disks...done
/u01/app/11.2.0/grid/perl/bin/perl -I /u01/app/11.2.0/grid/perl/lib/5.10.0 /u01/app/oracle/product/11.2.0/dbhome_1/asru/zerofill 1 /dev/oracleasm/disks/FRA1 286 20473
20187+0 records in
20187+0 records out
21167603712 bytes (21 GB) copied, 129.256 seconds, 164 MB/s
Calculating the new sizes of the disks ...done
Resizing the disks...done
Dropping the file ...done
2) На хост-машине сжимаем диск с помощью утилиты vmware-vdiskmanager
C:\>vmware-vdiskmanager.exe -k orafra.vmdk
Shrink: 100% done.
Shrink completed successfully.
3) Виртуальную машину можно архивировать: теперь размер файла orafra.vmdk составляет всего 280Mb!
Здесь приведены очень подробные примеры использования утилиты ASRU для массивов 3par и EMC Simmetrix
Подписаться на:
Сообщения (Atom)