Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Oracle Новый топик    Ответить
 Как будем называть CDB, PDB итп? :-)  [new]
Денис1
Member

Откуда:
Сообщений: 61
Здравствуйте, уважаемые!

Пытаясь обобщить в очередной заметке то, что я успел накопать по Oracle 12c, я столкнулся с просто-таки непреодолимой дилеммой :-)

Как все знают, я и так не силен в терминологии - а тут просто фейерверк новых терминов - container database, pluggable database, unplug, split dictionary ...

В общем, буду очень признателен если кто попытается внести ясность как мы всю эту красоту будем называть по-русски.

Немного по самому Oracle 12c. Я с ним вожусь очень плотно вот уже несколько суток, просто удивительные изменения! Всё что я успел сделать (на мой взгляд, наиболее интересное с практической точки зрения) я обобщил и с примерами изложил у себя на сайте, все уже наверное знают где это и так, извините :-)

Заметочку назвал "Установка Oracle 12c как Контейнерной и Подключаемой базы данных", буду рад если пригодится кому-нибудь. Как уже сказал, вопрос с терминологией остаётся открытым :-)

Вкратце, на мой взгляд, как я в конце заметки и написал, вместе со значительным усложнением продукта, подключаемые pluggable databases привносят целый ряд важных положительных изменений:

1)Быстрое и эффективное "клонирование" баз данных для новых приложений, а также для тестирования и разработки. На мой взгляд, механизм PDB делает всю концепцию "storage snapshots" просто ненужной

2)Быстрый "перенос" существующих баз данных (путём отключения- копирования- подключения) на новую платформу или систему с новой версией Oracle

3)Упрощение и значительное ускорение процесса обновления версии продукта - даже для десятков баз данных приложений обновление требуется всего единожды - для контейнерной базы CDB

4)Разделение обязанностей администраторов баз данных приложений и самих данных - имея доступ только к одной PDB, администратор не может изменять или видеть данные в других контейнерах

5)Значительное уменьшение числа необходимых экземпляров Oracle - а значит, удешевление лицензирования путём более эффективного использования CPU. Такое же число баз данных потребует значительно меньше процессов на уровне ОС - всеми фоновыми процессами экземпляра владеет CDB и предоставляет их для совместного использования всеми PDB

6)"Разделённый" системный словарь Oracle позволяет хранить "клиентскую" часть метаданных в самой PDB, перенося их из одной системы в другую вместе с данными пользователя

7)Все PDB защищены через Data Guard и RAC на уровне CDB, при этом резервное копирование и восстановление может быть выполнено индивидуально для каждой PDB, независимо от остальных.

Кто что думает по существу вопроса?

=================================================
С уважением,
Денис

Библия для людей, работающих с командной строкой.
http://www.read-and-think.org/
=================================================
29 июн 13, 12:24    [14500285]     Ответить | Цитировать Сообщить модератору
 Re: Как будем называть CDB, PDB итп? :-)  [new]
Sal
Member

Откуда:
Сообщений: 1595
я дословно перевожу pluggable как втыкаемые :)

по существу
по п.2. не все так радужно - cross endian так и нет.
п.5. стоимость oпции Multitenant (17500$ на проц) явно перебивает остальную "экономию".
Имхо, PDB - это костыль к экзадате (если хотите делать на ней консолидацию) ввиду ее хилого железа,
ну и маркетинг - раз у MS SQL такое есть ...
насчет разделяемых процессов только что Льюис высказался скептически
http://jonathanlewis.wordpress.com/2013/06/25/12c/
да и раньше народ шумел на тему одного LGWR для всех баз
29 июн 13, 12:46    [14500313]     Ответить | Цитировать Сообщить модератору
 Re: Как будем называть CDB, PDB итп? :-)  [new]
Sal
Member

Откуда:
Сообщений: 1595
уточню, Льюис писал про чуть другое - use threading under Unix
29 июн 13, 12:49    [14500317]     Ответить | Цитировать Сообщить модератору
 Re: Как будем называть CDB, PDB итп? :-)  [new]
Alexander Ryndin
Member

Откуда:
Сообщений: 4917
Блог
Sal
да и раньше народ шумел на тему одного LGWR для всех баз
LGWR вполне справляется с 500 Гб редо в час (возможно и больше, но я таких систем не видел).
Ну а консолидация, все таки, важна не для систем, где каждая дает 500 Гб редо в час, а для систем, которых штук 50 и каждая генерит 1-30 Гб.
29 июн 13, 13:26    [14500376]     Ответить | Цитировать Сообщить модератору
 Re: Как будем называть CDB, PDB итп? :-)  [new]
suPPLer
Member

Откуда: Харків, Україна
Сообщений: 7794
Блог
Денис1
5)Значительное уменьшение числа необходимых экземпляров Oracle - а значит, удешевление лицензирования путём более эффективного использования CPU. Такое же число баз данных потребует значительно меньше процессов на уровне ОС - всеми фоновыми процессами экземпляра владеет CDB и предоставляет их для совместного использования всеми PDB


Упал главный — лежат все?

PS: Простите, автор, прочесть проповедь на Вашем сайте, перемежаемую небольшими отступлениями к возможностям Oracle 12c, не смог. Увы.
29 июн 13, 13:38    [14500400]     Ответить | Цитировать Сообщить модератору
 Re: Как будем называть CDB, PDB итп? :-)  [new]
xtender
Member

Откуда: Мск
Сообщений: 5704
Интересно кто смог....
29 июн 13, 15:40    [14500490]     Ответить | Цитировать Сообщить модератору
 Re: Как будем называть CDB, PDB итп? :-)  [new]
____NAK7777_____
Guest
Alexander Ryndin
Sal
да и раньше народ шумел на тему одного LGWR для всех баз
LGWR вполне справляется с 500 Гб редо в час (возможно и больше, но я таких систем не видел).
Ну а консолидация, все таки, важна не для систем, где каждая дает 500 Гб редо в час, а для систем, которых штук 50 и каждая генерит 1-30 Гб.



Ну ща то наконец то LGWR уже не один...
29 июн 13, 19:09    [14500823]     Ответить | Цитировать Сообщить модератору
 Re: Как будем называть CDB, PDB итп? :-)  [new]
Alexander Ryndin
Member

Откуда:
Сообщений: 4917
Блог
____NAK7777_____
Ну ща то наконец то LGWR уже не один...
Он уже давно не один
29 июн 13, 20:03    [14500907]     Ответить | Цитировать Сообщить модератору
 Re: Как будем называть CDB, PDB итп? :-)  [new]
Sal
Member

Откуда:
Сообщений: 1595
Денис1,
насчет терминологии - В.Юринский кидал ссылку на каталог ПО
https://docs.google.com/file/d/0B9Y-s2qUNtytNXdQekVUNnNEblU/edit?usp=sharing
там используются термины и контейнерная и подключаемые БД
29 июн 13, 23:08    [14501224]     Ответить | Цитировать Сообщить модератору
 Re: Как будем называть CDB, PDB итп? :-)  [new]
___NAK7777___
Guest
Alexander Ryndin
____NAK7777_____
Ну ща то наконец то LGWR уже не один...
Он уже давно не один


В single instance ?
29 июн 13, 23:46    [14501272]     Ответить | Цитировать Сообщить модератору
 Re: Как будем называть CDB, PDB итп? :-)  [new]
Alexander Ryndin
Member

Откуда:
Сообщений: 4917
Блог
___NAK7777___
Alexander Ryndin
пропущено...
Он уже давно не один


В single instance ?
В кластере, конечно.
30 июн 13, 00:59    [14501346]     Ответить | Цитировать Сообщить модератору
 Re: Как будем называть CDB, PDB итп? :-)  [new]
Денис1
Member

Откуда:
Сообщений: 61
Здравствуйте, Sal, suPPLer и все ответившие.

Несколько комментариев, если можно.

> Sal: "по п.2. не все так радужно - cross endian так и нет."
Да, там ещё и осталось старое ограничение по "compatible" national character sets ...
точно, ещё есть куда улучшать продукт :-) Но мне кажется уже сам факт что я могу взять десяток PDB, "выткнуть" :-) их из системы 12.0.1.0 и "воткнуть" :-) в 12.1.1.0 без заморочек с upgrade - уже хорошее начало. Там, конечно, надо будет ещё процедуру запустить для согласования (?) common users - но всё равно это быстрее и легче чем "catupgrd.sql" в каждой базе. Ну а если предположить "out of place upgrade" с 12с на 13... - разница ещё заметнее.

> Sal: "п.5. стоимость oпции Multitenant (17500$ на проц)"
Ох ты, огромное вам человеческое спасибо! А я ведь почему-то предположил что все эти "pdb" будут в составе "ядра" EE, а не покупаться отдельно в виде опции ... Да уж. НО всё равно,
хоть теперь моя выгода от PDB уменьшилась как минимум на 17500$, всё равно - предположим, что у меня есть хорошая система "под завязку" забитая Power P7 CPU. Все они уже лицензированы на Enterprise Edition. На этой машине крутится с десяток баз данных. Мне надо перенести со старой машины, идущей на утилизацию, ещё штук 10 (типа пре-прод тест). В результате мне надо покупать новый сервер с P7 - старый наращивать некуда - и докупать EE лицензии по 47500$ (для P7 будет ещё дороже).

Вместо этого, я докупаю "Multitenant Option", экономя на каждом CPU 40000$. Делаю эти все базы PDB, использую "multiprocess multithread processes" (хоть это бесплатно!) - и вмещаю все 20 баз на тот же сервер (я думаю ещё и запас останется).

Как такой сценарий? Я серьёзно подумываю сделать такой финт в реальной жизни, а не теоретически.


> Sal: PDB - это костыль к экзадате (если хотите делать на ней консолидацию) ввиду ее хилого железа,
Вы имеете ввиду CPU или что-то другое? CPU на Екзадате в принципе самые последние (или уже почти?) из Интела, так что если говорить о "слабине" железа - тут разговор больше об Интеле, чем о Екзадате. Или вы имели ввиду IO систему и пр? Сеть вроде бы в Екза тоже самая последняя - полно 10Gbps интерфейсов, Инфинибэнд стандартный OpenFabrics, SUNовские IB свичи очень даже мощны ...

Но в принципе - согласен, для платформы Экза PDB - просто подарок. К тому же позволит решить вопрос с отсутствующими "storage snapshots", как я уже писал. Нет?

Sal, по поводу LGWR - именно на Экзадате по-моему есть опция с записью логов во флэш карты, что очень существенно "сглаживает" IO profile - то есть в принципе одного Logwriter достаточ-но. Ну а если нет - ведь на SMP платформе LGWR "форкал" (теперь похоже будут threads в самом LGWR) LGnn "workers" - они полностью решают проблему?

К тому же новые вьюхи V$IO_OUTLIER и V$LGWRIO_OUTLIER позволяют это всё мониторить ...


> suPPLer: "Упал главный — лежат все?"

А как было до этого? Точно так же - предположим, те самые 10 баз у меня "сконсолидированы" в одну, только с 10-тью разными схемами. Упал экземпляр - все 10 схем лежат.

Решается эта проблема или использованием RAC или путём DataGuard.

А если на одном сервере 10 баз, по одной схеме на каждую - вы представляете сколько памяти, context switches, CPU палится зазря на это всё? Именно такая проблема решается через PDB, нет?


suPPLer - не по теме, но по вашему ответу :-) Проповедуют в Церкви - сходите, чтобы ощутить разницу :-) Я просто излагаю своё собственное мнение. И ещё одно, только пожалуйста не обижайтесь на меня и поймите правильно, я просто говорю что много раз видел. Если кого-то, (живущего в Православном граде Харькове, кстати:-)) так прямо раздражают цитаты из Библии - это значит что чего-то есть за вами, о чём вы знаете и сами, да не хотите в этом признаться.
Прочтите ещё разик, чего я написал в самом начале той заметки - похоже, это именно для вас.
Благословит вас Господь, человек под псевдонимом "suPPLer".

Извините пожалуйста если был назойлив, ещё раз прошу не обижаться, ладно? :-)

=================================================
С уважением,
Денис

Библия для людей, работающих с командной строкой.
http://www.read-and-think.org/
=================================================
30 июн 13, 10:55    [14501646]     Ответить | Цитировать Сообщить модератору
 Re: Как будем называть CDB, PDB итп? :-)  [new]
Sal
Member

Откуда:
Сообщений: 1595
Денис1,

PDB в ядре то будет, но (бесплатно) одна.
Про "хилое" железо - в экзадате Х2(3)-2 используются самые простые 2-х процессорные х86 серверы (ширпотреб),
отнюдь не упомянутые Вами Р7-системы.
Но в этом как бы весь бизнес смысл - использовать дешевый ширпотреб и делать деньги на софте.
Это касается и PDB - либо платите за доп. ЦПУ, память и тд, либо ораклу за Multitenant опцию :)
Кстати, параллельная запись логов во флеш - это то уж точно костыль и именно из-за того,
что "дешевый" дисковый контроллер с малым (512МБ) кэшем затыкается на интенсивной записи.
В экзадате Х3 оракл пошел еще дальше - заменил дорогую SLC флеш на более дешевую eMLC (правда, большего размера).
Ну а насчет редулогов, LGWR и PDB - вот ссылка на дискуссию:
http://newsgroups.derkeiler.com/Archive/Comp/comp.databases.oracle.server/2012-10/msg00073.html
30 июн 13, 11:48    [14501672]     Ответить | Цитировать Сообщить модератору
 Re: Как будем называть CDB, PDB итп? :-)  [new]
suPPLer
Member

Откуда: Харків, Україна
Сообщений: 7794
Блог
Денис1
suPPLer: "Упал главный — лежат все?"

А как было до этого?

Как было до этого, мне известно. Вопрос был в том, изменили ли что-нибудь нововведения. Нет так нет.

Денис1
suPPLer - не по теме, но по вашему ответу :-)

Поиск соломинок в моих глазах Вы можете осуществить по указанным в профиле контактам, если Вам будет угодно.

Денис1
Извините пожалуйста если был назойлив, ещё раз прошу не обижаться, ладно? :-)

Нажать Ctrl+W на странице с заметками, которые тяжело воспринимать, очень просто. Какие обиды, помилуйте... Главное, что здесь на форуме Вы делитесь полезной информацией.
30 июн 13, 14:38    [14501828]     Ответить | Цитировать Сообщить модератору
 Re: Как будем называть CDB, PDB итп? :-)  [new]
Victor Metelitsa
Member

Откуда: Тюмень
Сообщений: 2550
другой подход:
http://askakorean.blogspot.hk/2013/07/culturalism-gladwell-and-airplane.html
(4) The NTSB report, helpfully, attaches the transcript of the events in the cockpit as an appendix. At p. 180 of the report, there is the entire transcript. And the transcript reveals a striking fact that Gladwell never mentions: 90 percent of the conversation among the three pilots is in English. In fact, the only part of the conversation that happens in Korea is idle banter, talking about how the company does not pay them enough or how Guam's airport must be staffed by former U.S. soldiers who were stationed in Korea.

This is in fact a common occurrence in professional settings in Korea. Because Korea did not develop many of the modern technologies on its own, Korean professionals learn how to use the cutting-edge technology with the original terminology (which is, in most cases, in English,) without bothering to translate them into Korean. When Korean professionals actually use the technology, they find themselves being more comfortable with simply using the English terms. The fact that a significant portion of Korea's professionals study abroad, usually in the United States, further reinforces this trend.

So for example, in case of an open-heart surgery, Korean surgeons communicate with each other in the surgery room using almost entirely English and Latin phrases--the same phrases that are found in American medical school textbooks. The same trend holds with airline pilots, only more so. Recall that airline pilots must communicate with the local airport in English. This means that it is a part of Korean airline pilots' job description to be proficient in English. As a result, Korea's pilots conduct most of their business in English, even with each other.
21 июл 13, 23:23    [14596431]     Ответить | Цитировать Сообщить модератору
 Re: Как будем называть CDB, PDB итп? :-)  [new]
_THIS_IS_
Guest
Денис1,
Денис1
Кто что думает по существу вопроса?

PDB/CDB - фигня. ЛюдЯм захотелось улучшить показатели консолидации на Exadatа, и под шумок они ухлопали независимость разных БД. Самая главная проблема - разные БД должны быть по-разному настроены потому, что разные приложения работают очень по-разному с очень разными требованиями. Очень часто разработчики приложений выдвигают требования к настройкам БД. А уж независимую восстановимость и независимый режим бэкапа привести в жертву - думали ОЧЕНЬ долго.
Это хорошо только... я даже затрудняюсь придумать для каких бизнесов эта фича может быть хороша. Может кто сможет?
30 июл 13, 16:19    [14638475]     Ответить | Цитировать Сообщить модератору
 Re: Как будем называть CDB, PDB итп? :-)  [new]
Деев И.
Member

Откуда: отсюда
Сообщений: 783
_THIS_IS_
Это хорошо только... я даже затрудняюсь придумать для каких бизнесов эта фича может быть хороша. Может кто сможет?


Может быть удобно для создания множества инстансов разработки и тестирования, особенно в системах с использованием нескольких схем данных. В SaaS-бизнесах.
30 июл 13, 17:07    [14638847]     Ответить | Цитировать Сообщить модератору
Все форумы / Oracle Ответить