Oracle 12c Multitenant Architecture. Новые возможности для разработки и тестирования

Суть технологии состоит в возможности запустить несколько независимых баз (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, рассмотрен лишь частный случай применительно к конкретной задаче.