Самым крупным нововведением недавно вышедшего Oracle 12c безусловно является Multitenant Architecture. Сам Oracle преподносит эту возможность в основном как средство консолидации и снижения расходов.
Суть технологии состоит в возможности запустить несколько независимых баз (pluggable database, PDB) в рамках одного инстанса (container database, CDB). Каждая база имеет свой набор схем и табличных пространств, но при этом у них общая SGA и один набор серверных процессов. Есть возможность клонировать pluggable database, как в рамках одного контейнера, так и между контейнерами. Вот эту возможность и будем использовать для создания копий тестовых баз и экономии ресурсов.
Задача — имеем большую систему, с большой базой. Нужно проводить тестирование изменений, причем изменений разрушительных — удаление/модификация таблиц. Как это делается сейчас — создаем новую базу, заливаем в нее минимально возможный набор схем и данных и проводим тестирование. Процесс сам по себе не быстрый, трудоемкий и всегда есть возможность ошибиться. Да и «минимальный набор данных» может быть не таким уж и маленьким.
В документации на команду CREATE PLUGGABLE DATABASE, в разделе клонирования есть упоминание об опции SNAPSHOT COPY. Судя по описанию, при создании клона с опцией SNAPSHOT COPY, файлы данных клонируемой базы копироваться не будут. Для них будут
созданы copy on write снапшоты и место на диске будут занимать только измененные блоки клонированной базы. Создание клонов со снапшотами возможно либо на ACFS, либо на специализированных NAS.
Эксперимент проводился в среде Oracle Virtualbox 4.2.14. Я не буду подробно описывать инсталляцию, она хорошо освещена в документации, буду останавливаться только на важных моментах.
Инсталляция
Ставим Oracle linux 6.4 c апдейтами, зависимости для oracle и поддержку ASM:
$ uname -a
Linux ora12.local 2.6.39-400.109.1.el6uek.x86_64 #1 SMP Tue Jun 4 23:21:51 PDT 2013 x86_64 x86_64 x86_64 GNU/Linux
$ yum install oracle-rdbms-server-11gR2-preinstall
$ yum install oracleasm-support
конфигурируем ASM и создаем ASM disk:
$ oracleasm configure -i
$ oracleasm createdisk -v data /dev/sdb1
Инсталлируем Oracle Database 12c Release 1 Grid Infrastructure (12.1.0.1.0) for Linux x86-64 в режиме singl node. В discovery path -> /dev/oracleasm/disks.
Командами asmcmd или с помощью asmca создаем disk group (DATA) volume (DATAVOL) и ASM cluster filesystem c точкой монтирования (/data). Из под root монтируем ACFS и убеждаемся что все хорошо:
$ mount | grep data
/dev/asm/datavol-326 on /data type acfs (rw)
Подключаемся к инстансу ASM и меняем режим совместимости:
$ sqlplus "/ AS SYSASM"
ALTER DISKGROUP data SET ATTRIBUTE 'compatible.rdbms' = '12.1.0.0.0';
ALTER DISKGROUP data SET ATTRIBUTE 'compatible.advm' = '12.1.0.0.0';
Ставим Oracle Database 12c Release 1 (12.1.0.1.0) for Linux x86-64, при инсталляции выбираем только установку софта (enterprise). После успешной установки запускаем dbca и создаем базу — контейнер: Create database->Advanced mode->Custom Database->Create As Container Database (Create an Empty Container Database).
В качестве Storage Type указываем ASM (+DATA). Все Database Components будут выбраны без возможности редактирования. Character set нужно выбирать подходящий для всех баз которые будем создавать в этом контейнере. Запускаем создание базы и ждем успешного завершения.
В результате получаем базу-контейнер и с seed database (модельная база для создания pluggable database).
Проверяем что все получилось:
$ sqlplus "/ AS SYSDBA"
SQL*Plus: Release 12.1.0.1.0 Production on Thu Jul 4 13:48:26 2013
Copyright (c) 1982, 2013, Oracle. All rights reserved.
Connected to:
Oracle Database 12c Enterprise Edition Release 12.1.0.1.0 - 64bit Production
With the Partitioning, Automatic Storage Management, OLAP, Advanced Analytics
and Real Application Testing options
SQL> SELECT NAME,OPEN_MODE FROM V$PDBS ;
NAME OPEN_MODE
------------------------------ ----------
PDB$SEED READ ONLY
Работа с клонами
Создаем каталог на ACFS /data/oradata, и меняем владельца на oracle. Меняем параметр db_create_file_dest на /data/oradata. Cоздаем клон который будет изображать тестовую базу:
CREATE PLUGGABLE DATABASE PDB001 ADMIN USER admin IDENTIFIED BY qwerty123
STORAGE (MAXSIZE 100G MAX_SHARED_TEMP_SIZE 100M)
PATH_PREFIX = '/data/oradata/PDB001';
На ACFS должен появиться каталог с буквенно-цифровым именем (случайным), содержащий наш PDB:
$ ls /data/oradata/ORCL/E0A1FFE9FFCF393FE0430F02000A6D7E/datafile/
o1_mf_sysaux_8x9131gt_.dbf o1_mf_system_8x912hvo_.dbf o1_mf_temp_8x914mbg_.dbf
PDB после создания или рестарта контейнера нужно открывать:
alter pluggable database all open;
Имитируем создание тестовой базы — создадим tablespace test размером 2G:
alter session set container=pdb001; -- выбираем активным наш клон
create tablespace test datafile size 2g;
Убеждаемся что файл данных есть и размер его 2 гигабайта:
$ ls -l /data/oradata/ORCL/E0A1FFE9FFCF393FE0430F02000A6D7E/datafile/*test*
-rw-r----- 1 oracle grid 2147491840 Jul 4 10:55 /data/oradata/ORCL/E0A1FFE9FFCF393FE0430F02000A6D7E/datafile/o1_mf_test_8x97xv5k_.dbf
Ради чего все это затевалось
Мы имеем тестовую базу большого объема и хотим протестировать особо крупное изменение, затрагивающее структуру таблиц и требующее для проверки всех данных.
Клонируем тестовую базу в режиме snapshot:
$ sqlplus "/ AS SYSDBA"
SQL> alter pluggable database pdb001 close immediate;
Pluggable database altered.
SQL> alter pluggable database pdb001 open read only;
Pluggable database altered.
SQL> create pluggable database pdb003 from pdb001 SNAPSHOT COPY;
Pluggable database created.
SQL> alter pluggable database pdb001 close immediate;
Pluggable database altered.
SQL> alter pluggable database all open;
Pluggable database altered.
И смотрим что произошло на файловой системе:
$ ls -l /data/oradata/ORCL/E0AB0DD4BA9D2C11E0430F02000AED35/datafile/
total 20500
lrwxrwxrwx 1 oracle grid 132 Jul 4 10:54 o1_mf_sysaux_8xb71r49_.dbf -> /data/.ACFS/snaps/E0AB0DD4BA9D2C11E0430F02000AED35/oradata/ORCL/E0A1FFE9FFCF393FE0430F02000A6D7E/datafile/o1_mf_sysaux_8x9131gt_.dbf
lrwxrwxrwx 1 oracle grid 132 Jul 4 10:54 o1_mf_system_8xb71r49_.dbf -> /data/.ACFS/snaps/E0AB0DD4BA9D2C11E0430F02000AED35/oradata/ORCL/E0A1FFE9FFCF393FE0430F02000A6D7E/datafile/o1_mf_system_8x912hvo_.dbf
-rw-r----- 1 oracle grid 20979712 Jul 4 10:55 o1_mf_temp_8xb71tn1_.dbf
lrwxrwxrwx 1 oracle grid 130 Jul 4 10:54 o1_mf_test_8xb71r49_.dbf -> /data/.ACFS/snaps/E0AB0DD4BA9D2C11E0430F02000AED35/oradata/ORCL/E0A1FFE9FFCF393FE0430F02000A6D7E/datafile/o1_mf_test_8x97xv5k_.dbf
Файлы данных всех табличных пространств кроме TEMP это ссылки на ACFS снапшот, и место на диске они не занимают. Узнать сколько реально занял снапшот можно так:
$ acfsutil snap info /data
snapshot name: E0AB0DD4BA9D2C11E0430F02000AED35
RO snapshot or RW snapshot: RW
parent name: /data
snapshot creation time: Thu Jul 4 10:54:48 2013
number of snapshots: 1
snapshot space usage: 286388224
Чего и добивались — 286МB против более 3GB
$ du -k /data/oradata/ORCL/E0A1FFE9FFCF393FE0430F02000A6D7E/datafile
3105828 /data/oradata/ORCL/E0A1FFE9FFCF393FE0430F02000A6D7E/datafile
Естественно, если активно начать изменять блоки клона со снапшотами, занимаемое им место вырастет.
После того как провели тестирование, удаляем ненужный клон:
SQL> alter pluggable database PDB003 close immediate;
Pluggable database altered.
SQL> drop pluggable database pdb003 including datafiles;
Pluggable database dropped.
Убеждаемся что место освободилось:
$ acfsutil snap info /data
number of snapshots: 0
snapshot space usage: 0
Результат
В результате нам удалось сэкономить время и ресурсы. И не только дисковые, напомню, что все базы PDB используют один комплект процессов и одну SGA.
PS. Статья не претендует на полное описание Oracle Multitenant Architecture, рассмотрен лишь частный случай применительно к конкретной задаче.
Автор: xlix123
