Oracle toma что это
Том Кайт:Я хочу отметить некоторые возможности СУБД Oracle 11g версии 2, которые нравятся лично мне.
1. Намного проще перенести критически важные корпоративные нагрузки.
Многие корпоративные приложения сложно перенести в облако, поскольку большинство провайдеров гипермасштабируемых облачных сред были построены на модели виртуальной машины с ресурсами, совместно используемыми через вычислительный гипервизор и сети с избыточной подпиской. Эта более старая архитектура облачных вычислений затрудняет действие корпоративных приложений с ожидаемыми уровнями производительности и доступности без каких-либо существенных модификаций, что усложняет работу и увеличивает риски. Корпоративные приложения и другие высокопроизводительные приложения были разработаны для оптимальной работы в следующих условиях: в масштабируемых архитектурах для масштабирования ресурсов (а не горизонтального масштабирования); минимальные задержки; постоянные подключения к реляционным базам данных; кластеризация ресурсов на предмет доступности. OCI была разработана с использованием ключевых облачных технологий для удовлетворения требований корпоративных приложений.
Заключение
Я попытался описать большинство вещей, который на мой взгляд могут пригодится программисту. Так как их довольно много, то я их только обозначил, часто не вдаваясь в детали. Как конкретно сделать необходимую настройку можно всегда прочитать в упомянутой книжке Тома Кайта, найти в колонке asktom или просто нагуглить. Главное знать что гуглить, и, надеюсь, данный топик вам это подсказал.
Объемы баз данных и сложность запросов к ним всегда росли быстрее, чем скорость их обработки. Поэтому лучшие умы человечества много лет думали о том, что произойдет, когда оперативной памяти станет столько, что можно будет всю базу данных взять и поместить в кэш оперативной памяти.
В последние годы логический момент для этого, казалось бы, настал. Стоимость оперативной памяти падала, падала, и упала совсем. Еще в начале века казалось, что 256 МБ памяти для сервера — это нормально, и даже много. Сегодня нас не удивишь параметром 256 ГБ оперативной памяти на сервере начального уровня, а с промышленными серверами вообще настал полный коммунизм, любой благородный дон может набрать хоть терабайт оперативной памяти на сервере, если захочет.
Но дело не только в этом — появились новые технологии индексирования данных, новые технологии компрессии данных — OLTP-компрессия, компрессия неструктурированных данных
(LOB Compression). В Oracle Database 11g, например, появилась технология Result Cache, которая позволяет кэшировать не просто строки таблиц или индексы, но и сами результаты запросов и подзапросов.
То есть, с одной стороны, наконец-то можно использовать оперативную память по ее прямому назначению, но с другой стороны — не так все просто. Чем больше кэш, тем больше накладные расходы на его сопровождение, включая процессорное время. Вы ставите больше памяти, увеличиваете объем кэша, а система работает медленнее, и это, в общем-то, логично, потому что алгоритмы управление памятью, разработанные в Раннем средневековье нашими прапрадедушками, попросту не годятся для эпохи Возрождения, и все тут. Что же делать?
А вот что. Давайте вспомним о том, что существует, по сути дела, две категории баз данных: строчные базы данных, которые и в буферном кэше в оперативной памяти, и на диске хранят информацию в строчном виде — Oracle Database, Microsoft SQL Server, IBM DB/2, MySQL и т.д.; и колоночные СУБД, в которых информация хранится по столбцам, и которые большого распространения в индустрии, к сожалению, не нашли. Строчные базы данных хорошо обрабатывают OLTP-операции, а вот для обработки аналитики больше подходят, вы будете смеяться, колоночные базы данных — зато DML-операции для них проблема, ну вы поняли, почему. Промышленность, как вы знаете, пошла по пути строчных баз данных, на которые в виде компромисса навешиваются аналитические возможности.
И вот, появилась технология Oracle Database In-Memory, в которой преимущества обоих подходов наконец-то совмещены.
И что получается?
Получается фантастика. Обработка транзакций ускоряется в два раза, вставка строк происходит в 3–4 раза быстрее, запросы для аналитики выполняются в реальном времени, практически мгновенно! Маркетологи говорят, что аналитика стала в сто раз быстрее, но это они скромничают, чтобы не пугать рынок, реальные результаты куда более впечатляющие.
А теперь давайте разбираться, как и в чем это работает.
Итак, технология появилась в версии Oracle Database 12.1.0.2, и смысл ее в том, что рядом с нашим привычным буферным кэшем, который хранит строки таблиц и блоки индексов, находится новый кэш, точнее новая разделяемая область для данных в оперативной памяти, в которой данные из таблиц хранятся в колоночном формате! Вы поняли, да? И строчный и колоночный формат хранения в памяти для одних и тех же данных и таблиц! Причем данные одновременно активны и транзакционно согласованы. Все изменения, как обычно, сначала производятся в обычном буферным кэше, после чего отражаются в колоночном, или, как его называют наши англоязычные друзья, «колумнарном» кэше.
Несколько важных деталей. Во-первых, в колумнарном кэше отражаются только таблицы, то есть индексы не кэшируется — это первое. Во-вторых, технология не делает ненужную работу. Если данные читаются, но не изменяются, то в обычном, то есть в строчном буферном кэше хранить их незачем. А вот если данные изменяются, тогда их надо хранить в обоих кэшах, буферном и колоночном. Ну, и соответственно быстрее работает аналитика потому что для нее более эффективно именно колоночное представление информации. Это второе. И в-третьих — еще раз, чтобы было понятно. В колоночном кэше хранятся не блоки данных с диска. В блоках на диске информация хранится по строкам. В колумнарном кэше информация хранится по столбцам, в своем собственном представлении, в так называемых In-Memory «компресс юнитах». Это третье.
А теперь детали
Мы поняли, что аналитика работает в сотни раз быстрее, потому что колоночное представление для нее более эффективно — а, собственно говоря, почему?
В обычном буферном кэше информация хранится по строкам. Вот пример — из четырехколоночной таблицы нужно извлечь колонку №4. Для этого придется полностью просканировать всю эту табличку в оперативной памяти:
А что происходит, если та же таблица хранится в колоночном формате? Вся четвертая колонка нашей таблички находится в одном экстенте, т.е. в одном блоке памяти. Мы можем сразу выделить ее, тут же прочитать и вернуть приложению. Уменьшаются затраты на сканирование, на пересылку этих данных процессору, снижается загрузка процессора. Все работает значительно быстрее.
Такие операции сканирования очень характерны для ERP-приложений, для хранилищ данных в аналитических системах. Согласитесь, нужная штука для прогресса человечества.
Технически, чтобы это запустить, нужно включить кэширование для нужных столбцов в таблице. Для этого предназначено специальное расширение синтаксиса команды ALTER TABLE:
Делается это один раз, информация записывается в системный словарь СУБД Oracle, после чего автоматически используется базой данных в процессе своей работы. В вышеприведенном примере служебные столбцы не участвуют в отчетах, они нужны только для внутреннего аудита приложения, и поэтому мы их не кэшируем.
Можно указать кэширование по всем столбцам для материализованного представления:
SQL> ALTER MATERIALIZED VIEW cities_mv INMEMORY
Materialized view altered.
Можно включить кэширование на уровне всего табличного пространства:
А можно гибко кэшировать таблицы по столбцам на уровне секций, чтобы увязать стратегию кэширования с бизнес-правилами:
Например, есть у нас исторические данные, и они секционированы по дате. Когда у происходит закрытие периода, допустим, операционного дня, данные в этой секции таблицы уже не меняются, и по ним может начинать работать аналитика. Вот для этого нужно кэширование по секциям таблицы, по которым период закрыт. А для данных, по которым идут интенсивные операции изменения и удаления, включать кэширование пока незачем.
За сценой
Что происходит, когда мы включаем кэширование и информация записывается в словарь СУБД Oracle? Происходит волшебство — SQL-оптимизатор перестраивает план запроса. В первый раз, когда запрос приходит из приложения, на этапе так называемого жесткого парсинга (hard parse), генерируется план выполнения запроса.
В данном примере подсчитывается общее количество строк в табличке справочника городов CITIES. Оптимизатор видит, что выгодно выполнить запрос по колоночному представлению, и выполняет сканирование TABLE ACCESS INMEMORY FULL. Для приложения это полностью прозрачно, переписывания или модификации приложения не требуется!
Сама база данных Oracle при этом используют ряд интересных техник оптимизации:
1. Каждое процессорное ядро производит сканирование собственного столбца. При этом используются быстрые векторные SIMD-инструкции, т.е. специальные команды процессора, которые в качестве аргументов используют не скалярные значения, а вектор значений. Это дает сканирование миллиардов строк в секунду.
2. Мы не просто сканируем данные. Происходит сканирование и соединение данных из нескольких таблиц. На колоночном представлении это гораздо эффективнее, чем обычные joins. Такие joins выполняются в среднем в 10 раз быстрее.
3. В процессе выполнения запроса используется технология In-Memory Aggregation: в памяти создается динамический объект — промежуточный отчет. Объект заполняется во время сканирования таблицы и позволяет ускорить выполнение запроса. В результате отчеты строятся в 20 раз быстрее без заранее созданных аналитических кубов.
4. Чтобы не загромождать оперативную память, используется сжатие столбцов в памяти. Есть шесть вариантов:
• NO MEMCOPRESS — без сжатия
• MEMCOMPRESS FOR DML — оптимизированный для DML-операций
• MEMCOMPRESS FOR QUERY LOW — оптимальный вариант, который используется по умолчанию
• MEMCOMPRESS FOR QUERY HIGH — оптимизированный для скорости выполнения запроса и для экономии памяти
• MEMCOMPRESS FOR CAPACITY HIGH — оптимизированный для скорости выполнения запроса
• MEMCOMPRESS FOR CAPACITY LOW — оптимизированный для экономии памяти
В этом примере выбраны для сжатия столбцы данные в которых часто повторяются, уникальные столбцы не сжимаются.
В системной таблице словаря USER_TABLES появился новый атрибут сегмента INMEMORY. Столбец INMEMORY также появился в системных таблицах *_TAB_PARTITIONS. Чтобы узнать, что и в каком объеме находится в кэше, нужно использовать специальное системное представление V$IM_SEGMENTS:
В этом примере мы видим, что в кэше находятся четыре таблицы, причем на диске каждая таблица занимает примерно по 5 МБ, а в памяти, за счет сжатия — от 100 КБ до 1 МБ. Колонка POPULATE_STATUS показывает статус информации. Видим, что таблицы CITIES, COMPANIES, и AIRPORTS уже полностью загрузились в In-Memory-кэш, а COUNTRIES — еще не полностью, 400 КБ осталось загрузить. То есть именно сейчас эта таблица транспонируется в формат по столбцам и загружается в кэш.
Первым делом — приоритеты
С технической точки зрения чтение в память с диска может происходить двумя способами:
• При первом обращении к данным. Это возможность по умолчанию.
• Автоматически после старта экземпляра БД. Эта возможность включается установкой атрибута сегмента PRIORITY.
Во втором варианте чтение производят фоновые процессы ORA_W001_orcl (W001 — номер экземпляра), количество фоновых процессов регулируется с помощью нового параметра INMEMORY_MAX_POPULATE_SERVERS. В результате после рестарта экземпляр сразу доступен для работы в фоновом режиме, и время старта экземпляра при этом не увеличивается. Конечно, в начале возрастает нагрузка на процессор, куда ж деваться. Зато потом будут быстрее работать аналитические запросы.
Приоритетом загрузки в кэш можно управлять, вот варианты значений приоритета:
Допустим, мы держим в таблице cities справочник городов, и этот справочник постоянно нужен всем пользователям, он постоянно участвует в отчетах. В этом случае мы должны указать для этой таблицы критический приоритет, тем самым мы заставим систему автоматически считать экземпляр этой таблицы в кэш при старте базы данных:
А как же OLTP?
Как вы прекрасно знаете, чистых OLTP-систем практически не бывает. В любом OLTP-приложении есть поддержка отчетности, а для отчетности нужны дополнительные индексы. А что такое дополнительные индексы? Это ни что иное, как дополнительные накладные расходы на вставку данных.
А теперь разрешите мне с гордостью сообщить вам о том, что при переходе на Oracle Database In-Memory решается и эта проблема, потому что в этой технологии — правильно! — не используются индексы. Т.е. мы можем просто удалить те индексы, которые нужны нам для аналитики, и получаем парадоксальный эффект — система, предназначенная для повышения скорости работы хранилищ данных, прекрасно «разгоняет» и OLTP-приложения.
При этом тем операциям, которые и раньше работали хорошо, технология Oracle Database In-Memory не мешает и не пытается помочь (принцип «не надо чинить то, что не сломалось», в действии!), поскольку в ядре базы данных она находится, так сказать, в стороне. То есть на формат данных на диске эта технология никак не влияет, все работает точно так же, как и раньше, какую бы файловую систему вы ни использовали. Файлы данных не меняются, журнал, резервирование, восстановление данных работают по-прежнему. Все технологии, в том числе ASM, RAC, DataGuard, GoldenGate — работают прозрачно.
Контейнерная архитектура
Главное архитектурное новшество в Oracle Database 12c — это контейнерная архитектура. Oracle Database In-Memory полностью поддерживает эту архитектуру. Параметр INMEMORY_SIZE устанавливается на уровне всей контейнерной базы данных, а на уровне конкретных баз данных его можно варьировать в зависимости от конкретного приложения. Например, на уровне контейнерной базы данных вы можете установить INMEMORY_SIZE равным 20 ГБ, а на уровне контейнеров — не включать кэш для ERP, для CRM установить объем кэша 4 ГБ, для хранилища данных — 16 ГБ.
Кластерная архитектура
Да, и в кластерах Oracle Real Application Cluster это тоже работает. Можно управлять распределением объектов в кэше In-Memory между узлами в кластере. Например, можно указать опцию DUPLICATE, тогда при изменении кэша на одном из узлов кластера они будут автоматически синхронизироваться со вторым узлом, это нужно для того, чтобы всегда существовала доступная копия кэша с «разогретыми» колумнарными данными:
• AUTO DISTRIBUTE — синхронизацией кэша управляет СУБД (используется по умолчанию);
• DUPLICATE ALL — на всех узлах кластера синхронизируется одинаковый кэш;
• DISTRIBUTE BY ROWID RANGE;
• DISTRIBUTE BY PARTITION;
• DISTRIBUTE BY SUBPARTITION.
Опция DUPLICATE и DUPLICATE ALL работает только на Oracle Exadata и Oracle SuperCluster, на обычном сервере эта опция игнорируется. Остальные варианты нужны для более гибкого управления — например, с помощью параметра DISTRIBUTE BY ROWID RANGE можно указать, что часть секций должна находиться в колоночном виде на одном узле, а остальные — на другом узле.
Резюме
Не могу больше скрывать от вас полный синтаксис команды ALTER TABLE INMEMORY. Вот он:
Можно указать приоритет загрузки в кэш, способ синхронизации кэша между узлами кластера, имена столбцов, которые нужно и не нужно кэшировать в памяти, степень сжатия. Команда, как я уже писал, выполняется один раз, далее информация запоминается.
Для настоящих инженеров есть возможность тонко настраивать свои запросы с помощью хинтов SQL-оптимизатора: INMEMORY,NO_INMEMORY, INMEMORY_PRUNING и NO_INMEMORY_PRUNING.
NO_INMEMORY, как видите, является здесь простейшим хинтом. Например, можно в явном виде дать оптимизатору указание не использовать технологию In-Memory — если вы уверены в том, что это попросту не нужно, потому что у вас хороший запрос, построены индексы и т.д. Еще два интересных хинта — INMEMORY_PRUNING и NO_INMEMORY_PRUNING, они управляют использованием storage-индексов. Storage-индекс хранит минимальное и максимальное значение столбца в каждом экстенте памяти кэша и прозрачно исключает ненужные сканирования столбцов, например: WHERE prod_id> 14 AND prod_id < 29.
В файле инициализации INIT.ORA появились новые параметры, дарю их вам безвозмездно, то есть даром:
• INMEMORY_SIZE
• INMEMORY_FORCE= < DEFAULT | OFF >
• INMEMORY_CLAUSE_DEFAULT= [INMEMORY] [NO INMEMORY] [compression-clauses][priority-clauses]
• INMEMORY_QUERY=
• INMEMORY_MAX_POPULATE_SERVERS
• OPTIMIZER_INMEMORY_AWARE
• INMEMORY TRICKLE REPOPULATE SERVERS PERCENT
INMEMORY_SIZE позволяет указать размер области памяти для колумнарных данных, по умолчанию равен нулю. Например, INMEMORY_MAX_POPULATE_SERVERS — это количество фоновых процессов, которые считывают данные с диска в кэш, по умолчанию он равен количеству процессоров, которые «видит» Oracle Database. Еще один интересный параметр — OPTIMIZER_INMEMORY_AWARE, при его помощи можно указать, видит или не видит оптимизатор In-Memory-кэш. Например, это нужно, если вы нужно оценить накладные расходы. Подробности предлагаю вам найти в документации.
Oracle Database In-Memory больше всего подходит для приложений, в которых много запросов, сканирующих много строк с такими фильтрами как: «=», «», «IN». Технология очень эффективна, когда приложение запрашивает всего лишь несколько столбцов из большого числа (типично для SAP), соединяет большие факторные таблицы с таблицами измерений, с фильтрами по таблицам измерений. Соответственно, это такие приложения, как хранилища данных, информационно-аналитические системы, включая OLTP-приложения. Кстати, есть полезный дополнительный продукт — Oracle Database In-Memory Advisor, он помогает оценить применимость технологии Oracle Database In-Memory к конкретным приложениям. Oracle Database In-Memory Adviser анализирует статистику работы базы данных и выдает рекомендации по размеру памяти, по типу таблиц, которые необходимо кэшировать в In-Memory-кэше.
Важно понимать, что в отличие от конкурентов, Oracle Database In-Memory не требует переписывания приложений. Нет ограничений на SQL, не нужна миграция данных, технология готова для облака.
Не надо путать Oracle Database In-Memory и Oracle TimesTen In-Memory Database, это разные технологии. TimesTen — это встраиваемая база данных для приложений, она предназначена для чистых, а не смешанных OLTP-систем, для тех случаев, когда приложение должно работать в режиме реального времени, и время ответа должно составлять буквально секунды, а не секунды и не миллисекунды. TimesTen полностью загружает все данные в оперативную память. В отличие от нее Oracle Database In-Memory является расширением классической СУБД Oracle, находится внутри ее ядра и расширяет ее возможности с точки зрения ускорения аналитических запросов за счет колоночного представления.
Мне кажется, я написал достаточно, чтобы пробудить в вас неудержимое желание прочитать документацию к Oracle Database In-Memory. Но тут дело такое — технология новая, экспертизы по ней мало, один я на все ваши вопросы ответить не смогу. Поэтому, друзья, записывайтесь на наши онлайн-тренинги. Мы их будем прямо здесь будем обязательно анонсировать. А у меня пока все.
Stand by копия
Вышеупомянутые архивные файлы можно отправлять по сети и на лету применять к копии БД. Таким образом у вас всегда под рукой будет горячая копия с минимальным запаздыванием данных. В некоторых приложениях, где нет необходимости показывать данные с точностью до последнего момента, можно настроить такую БД только на чтение и разгрузить основной экземпляр БД, причем таких экземпляров на чтение может быть несколько.
Заказчики, использующие автономные сервисы
Компания интегрировала данные о продажах и маркетинге в автономное хранилище данных. Рост производительности в 50–60 раз по сравнению с локальной средой, повышение безопасности и экономия 15 часов еженедельного времени администратора.
Объединила 30 финансовых и операционных систем в новое хранилище финансовых данных, которое обеспечивает единый источник достоверной информации. Автомасштабирование обеспечивает гибкость затрат и производительность в периоды основной финансовой отчетности.
Перенесла комплексную систему управления информацией и проектами в облако всего за две недели, повысив производительность и обеспечив экономию до 90 % затрат и времени по сравнению с локальной версией.
Oracle Data Guard – больше возможностей
В версии 1 СУБД Oracle 11g уже имелись существенные изменения и усовершенствования механизма Oracle Data Guard, включая функциональность Oracle Active Data. Две особенности Oracle Data Guard, которые привлекли мое внимание в версии 1:
- Возможность оставить физическую копию основной базы данных, т.е. резервную базу, доступной для операции чтения, в то время как она находится в управляемом режиме восстановления основной базы данных. (Другими словами, одновременно можно восстанавливать главную базу после сбоев и не прерывать работу пользователей с данными, хотя некоторые ограничения присутствуют: пользователи смогут только просматривать данные, а изменять или вносить новые не смогут.)
- Возможность использования резервной базы в качестве реалистичной среды для тестирования. Резервный экземпляр совершенен для тестирования, поскольку он представляет собой побитовую, побайтовую копию основной базы, используемой в приложении. При тестировании изменений на копии будут получены результаты, которые очень точно отражают, что произойдет в основной базе при применении данного изменения.
Итак, Oracle Data Guard снова был усовершенствован. Первое, что бросилось мне в глаза, когда я просматривал информацию об Oracle Data Guard из релиза 2 – это его возможность производить автоматическое восстановление на уровне блока данных. Если в основной или резервной базе данных присутствуют поврежденные блоки, Oracle Data Guard сможет автоматически передать целую копию блока в любом направлении (из основной базы в резервную, либо из резервной в основную) и затем восстановить/перезаписать блок – возможно, прежде чем кто-то заметит проблему.
Истории успеха заказчиков, использующих стратегии гибридного облака
NRI переместила свои критически важные приложения SaaS в частный регион, который используется почти 70 % компаний на рынках капитала в Японии. Компания повысила как экономическую, так и операционную эффективность по сравнению с локальным развертыванием.
Компания переместила свои бизнес-приложения и нагрузки VMware в Oracle Cloud Infrastructure. Снизила расходы на инфраструктуру на 50 % по сравнению с локальными системами, а также сократила трудозатраты на администрирование и мониторинг на 90 %.
Tim Brasil перенесет 7000 серверов, 35 000 ядер, 1200 баз данных и 15 петабайт хранилища. Основное выставление счетов, CRM, пользовательские приложения БД и VMware перейдут в OCI. Интеграция облачной инфраструктуры Oracle и Microsoft Azure обеспечит скорость передачи данных 40 Гбит/с, федеративную идентификацию и соблюдение соглашения об уровне обслуживания, гарантируя доступность системы 99,95 %.
Продолжение следует…
Количество новых возможностей Oracle 11g v.2 огромно – слишком огромно даже для того, чтобы собрать в одной статье все, которые кажутся мне интересными. В следующих статьях я буду освещать эти новшества более подробно. Например, в ближайшей статье я рассмотрю на более глубоком уровне возможность обновления на основе редакций (Edition-Based Redefinition), которую мы затронули в этой статье.
Oracle Cloud — первое публичное облако, разработанное с нуля для того, чтобы стать лучшим облаком для каждого приложения. Переосмыслив проектирование ядер и систем для облачных вычислений, Oracle разработала инновации для решения проблем, возникающих у заказчиков, связанных с существующими публичными облаками. Мы ускоряем миграцию существующих корпоративных нагрузок, повышаем надежность и производительность всех приложений, а также предлагаем все сервисы, необходимые заказчикам для создания инновационных облачных приложений. Шесть основных причин, по которым заказчики выбирают Oracle Cloud Infrastructure (OCI) для всех своих облачных нагрузок.
Mutual Materials перемещает локальный E-Business Suite в облако и повышает производительность на 20 % (2:30)
Подвисание некоторых запросов на запись
При зависании некоторых ваших запросов в произвольный момент времени стоит заглянуть в alert.log на предмет наличия incomplete checkpoint. Это говорит о том, что ваши оперативные журнальные файлы слишком большие или их слишком мало, таким образом, защищаемые ими данные не успевают сбрасываться из кэша на диск, а СУБД заполнила уже все доступные оперативные журнальные файлы и хочет использовать их по кругу повторно, чего делать ни в коем случае нельзя, вот и появляется пауза. Хотя если ваше приложение работает на java, то в первую очередь я бы загляну на наличия Full GC в логах.
Рекурсивные подзапросы
СУБД Oracle поддерживает иерархические запросы с момента ее создания 30 лет назад. Уже самый первый выпуск позволял выполнить такой запрос:
Oracle 11g версии 2 вводит новый синтаксис создания того же самого иерархического запроса. Теперь можно использовать рекурсивные подзапросы, как показано в Листинге 3.
Листинг 3. Рекурсивный подзапрос.
Новый синтаксис, совместимый с ANSI-стандартом, дает точно такие же возможности, какие предоставляли раньше конструкции с CONNECT BY. Однако новый синтаксис – в рамках реализации ANSI SQL и, соответственно, более «стандартный». Он позволяет создать более аккуратный запрос для получения данных:
За более подробной информацией обратитесь к руководству «Oracle Database SQL Language Reference 11g Release 2», глава 19 «SQL Statements: SAVEPOINT to UPDATE».
Что позволяет БД Oracle работать так быстро?
Когда вы меняете данные в БД, то ваши изменения сначала идут в кэш, а потом асинхронно в нескольких потоках (число можно сконфигурировать) пишутся на диск. Синхронно же пишется специальных лог (оперативный журнальный файл), чтобы была возможность восстановить данные после сбоя, если они еще не успели с кэша сброситься на диск. Данный подход позволяет выиграть в скорости, так как в этом случае на диск все пишется последовательно в один файл, причем можно настроить так, чтобы писалось параллельно на два или больше дисков, тем самым увеличивая надежность защиты от потери изменений. Описанных файлов должно быть несколько, и они используются по кругу: как только все данные защищенные одним из лог файлов были записаны фоновым процессом в блоки данных на диск, то данный лог файл может быть переиспользован. Таким образом в какой-то мере это позволяет еще и сэкономить, имея ультрабыстрые диски небольшого размера только для небольших журнальных файлов используемых по кругу.
Обычно я рассказываю об этом, когда мне предлагают что-то сохранять просто в файл на диске, так как это будет «быстрее» за счет того, что мы будет писать все данные последовательно и головке жесткого диска не надо будет бегать и искать рэндомные блоки. Я все же настаиваю, что мы тут ничего не выиграем, так как будем писать на медленный диск, который скоро всего активно используется множеством других процессов для записи огромного количества различных логов, а Oracle синхронно тоже пишет у себя на диск только последовательно, как я описал выше.
4. Oracle Cloud обеспечивает максимальную поддержку стратегий гибридного облака.
Мы разработали архитектуру Oracle Cloud для поддержки широкого спектра вариантов развертывания для заказчиков. Заказчики могут запустить весь регион OCI из своего центра обработки данных, переместить все локальные среды VMware в публичные облачные регионы или предоставить сервисы OCI, например Exadata и Roving Edge, прямо на место проведения необходимых работ. Критичным компонентом решений Oracle является интеграция облачной инфраструктуры Oracle и Microsoft Azure, позволяющая предоставлять мультиоблачные сервисы с малой задержкой и унифицированной идентификацией в восьми регионах мира. Независимо от того, выбрали ли заказчики основного облачного провайдера или уже начали внедрять облачные решения, они могут модернизировать свой бизнес, используя возможности управления, производительности и ценности, предлагаемые в виде гибридных решений OCI.
Публичные регионы Oracle
Гипермасштабируемые облачные регионы более чем в 30 точках по всему миру.
Частные регионы
Все сервисы OCI работают в центрах обработки данных заказчиков.
Решение VMware
Нативная среда VMware на базе OCI в публичном облаке или частных регионах.
Exadata Cloud@Customer
Облачные автономные базы данных, работающие в Вашем ЦОД.
Инфраструктура Roving Edge
Вычислительные ресурсы и хранилище OCI для удаленного автономного использования.
Интеграция с Microsoft Azure
Региональная интеграция с низкой задержкой для мультиоблачных архитектур.
Истории успеха заказчиков, перенесших бизнес в облако
Компания перенесла свою систему управления запасами на OCI без каких-либо изменений в приложении. обеспечив снижение затрат на 50 %.
Перенесла свои системы управления человеческим капиталом (HCM) и финансового планирования, а также 60 ТБ ключевых данных в OCI. Производительность возросла на 25 %, а затраты сократились на 40 %.
Компания перенесла основные приложения ERP и бэк-офиса в OCI за 13 недель. Только OCI может соответствовать требованиям масштабируемости и отказоустойчивости базы данных.
Аналитические функции: лучшее, что случалось с SQL со времен появления ключевого слова SELECT
Аналитические функции – впервые появившиеся в СУБД Oracle 8i версии 1 – претерпели некоторые изменения в Oracle 11g версии 2.
Первым нововведением, которое привлекло мое внимание, было появление аналитической функции LISTAGG. Эта функция создает список значений столбцов, сгруппированных по какому-то значению. Значения перечисляются через «;» либо другой определенный пользователем разделитель. Да, эту функцию действительно долго хотели и ждали!
Когда вышла СУБД Oracle 10g версии 1, появилась возможность использовать новую функцию SYS_CONNECT_BY_PATH чтобы реализовать ту же функциональность, используя только «чистый SQL» без написания каких-либо процедур или функций. Однако этот «чистый SQL» был слишком громоздким. Сейчас, с появлением Oracle 11g версии 2, мы можем реализовать переход «из столбца в список» очень легко:
Сравните с подходом, который использовался в Oracle 11g версии 1 и более ранних версиях, когда нам приходилось использовать SYS_CONNECT_BY_PATH (этот код показан в Листинге 1), и я уверен, что вы тоже согласитесь: LISTAGG сделал сложное простым.
Листинг 1. Создание списка с помощью SYS_CONNECT_BY_PATH
Другая удобная аналитическая функция, появившаяся в Oracle 11g версии 2 – это функция NTH_VALUE. Как следует из названия, функция позволяет выделить N-ый элемент из аналитического окна, как показано в Листинге 2.
Листинг 2. Использование аналитической функции NTH_VALUE
Это просто пример некоторых из новых возможностей в области аналитики. Также были добавлены некоторые новые аналитические функции, и некоторые существующие расширены поддержкой выражения IGNORE NULLS. Для того чтобы узнать о них, обратитесь к руководству «Oracle Database Data Warehousing Guide 11g Release 2», глава 21 «SQL for Analysis and Reporting».
Еще пара заметок для программиста
Если у вас колонка имеет тип VARCHAR2(100), то попытка туда запихнуть строку longString.substring(0, 100) не факт, что увенчается успехом, так как ограничение 100 в определении колонки по умолчанию относится к количеству байтов, а не символов, поэтому при наличии двухбайтовых символов вы можете попасть впросак. На самом деле данное поведение можно немного сконфигурировать, подробнее можно почитать тут. Хорошо если вы еще не пытаетесь выполнить вставку в бесконечном цикле, по принципу делать пока не получиться, ведь это «получиться» в данном случае никогда не наступит.
Ну и общая рекомендация для всех типов БД: никогда не делайте update всех колонок в таблице при изменении одного поля объекта. Кажется весьма очевидным, но как показывает практика, данный антипаттерн часто имеет место быть, поэтому я настоятельно рекомендую проверить, что ваши фреймворки делают UPDATE только действительно измененных полей.
6. OCI предлагает превосходное соотношение «цена-производительность»
При разработке Oracle Cloud мы стремились добиться не только максимальной производительности облака для каждого приложения, но и лучшего соотношения «цена-качество». Ценообразование продуктов Oracle глобально согласованно: стоимость сервиса вычислений или хранения данных постоянно снижается во всех регионах для упрощения внедрения. Мы сделали наши цены конкурентными, не требуя от заказчиков принятия значительных многолетних обязательств. Такие основные облачные возможности, как безопасность и управление контейнерами, изначально включены в стоимость вычислительных ресурсов и не требуют дополнительных расходов. Мы создали сети с более высокой производительностью, но также оценили стоимость перемещения данных из облака, учитывая то, как наши заказчики строят мультиоблачные сети для обслуживания своих заказчиков.
Кроме того, мы постоянно упрощаем работу с Oracle Cloud. Мы обеспечили поддержку наших сервисов с помощью комплексного соглашения об уровне обслуживания (SLA), в котором мы предоставляем финансовые гарантии доступности и производительности сервисов сети и хранения Oracle, а также возможности управлять сервисами с помощью API в любое время. Для упрощения миграции мы обеспечиваем разработку, планирование и миграцию нагрузок в облако без каких-либо дополнительных затрат с помощью программы Oracle Cloud Lift. Наконец, мы можем сократить расходы заказчиков на поддержку лицензий на программное обеспечение на 25–33 % по мере увеличения объемов использования OCI с помощью Oracle Support Rewards.
Еще больше преимуществ. Предположим, что Вы перемещаете пользовательское приложение в OCI. Вы можете выбрать более низкую цену на использование лицензии Bring Your Own License для СУБД Oracle Database в облаке, получить бесплатную техническую поддержку для перемещения Вашего приложения и снизить общие расходы за счет оптовых скидок на OCI и получения вознаграждений за поддержку.
Ключевые инновации в Oracle Cloud Infrastructure
Виртуализация в автономном режиме
Полная изоляция экземпляров в целях повышения безопасности и производительности.
Пользовательские микросхемы безопасности
Концепция нулевого доверия для защиты заказчиков от других арендаторов.
Неблокирующие сети
Облачные сети, предназначенные для работы в специализированных локальных сетях.
Виртуализация сети L2
Облачная сеть для встроенной поддержки VMware, СУБД Oracle Database и других архитектур кластеризации.
Кластерная сеть RDMA
Кластеры с микросекундной задержкой для самых ресурсоемких нагрузок.
Гибкая инфраструктура
Онлайн-инфраструктура масштабирует ресурсы вверх и вниз без перезаписи приложений.
Индексы
Кроме всем известных индексов в виде B-деревьев в Oracle еще есть так называемые битовые индексы, которые показывают очень высокую производительность на запросах к таблицам в которых есть колонки с очень разреженными значениями. Особенно эффективно в этом случае будут работать запросы (по сравнению с обычными индексами) в которых присутствуют сложные комбинации OR и AND к разряженным столбцам. Данный индекс храниться не в B-дереве, а в битовых картах, что и дает возможность быстрого выполнения описанных запросов. Вопрос в количестве уникальных значений в таблице при которых данный индекс еще будет более предпочтителен весьма сложен: это может быть как 10 уникальных значений, так и 10 000. Здесь надо создавать индекс на конкретной таблице и смотреть что получается. Главное не пытайтесь использовать данный индекс на таблицах с большим количеством вставок и обновлений индексируемой колонки, так как такие операции будут блокировать довольно большие участки в индексируемой таблице и ваша система может встать колом или даже поймаете deadlock.
Одна из вещей, которая меня всегда очень радовала в Oracle — это возможность создания индекса по функции. Т.е. если вам в запросах приходиться использовать какую-нибудь функцию, то вы можете построить по ней индекс и значительно ускорить операции чтения.
Еще одно интересное свойство индексов, о котором необходимо знать, это то, что в индексе не хранятся значения NULL. Таким образом если вы будете делать запросы с условием или <> по индексируемой колонке, то в ответ строчек со значением NULL в индексируемой колонке вы обратно не получите. С другой стороны данное свойство можно очень эффективно использовать дня некоторых специфичных случаев. Например, у вас есть очень большая табличка в которой хранятся ордера, которая никогда не чистится. И существует фоновый процесс, который обязан все ордера отсылать в какую-нибудь backoffice систему. Первое решение, которое напрашивается — это завести еще одну колонку с флагом is_sent, где изначально стоит 0 и при отсылке мы будем проставлять 1. Т.е. фоновый процесс при каждом запуске будет делать запрос к таблице с условием is_sent=0. Битовый индекс вы здесь использовать не можете, так как табличка очень активно пополняется. Обычный индекс на основе В-дерева будет занимать очень много места, так как нужно хранить ссылки на огромное количество строчек. Но если мы слегка поменяем нашу логику и в качестве пометки отсылки, и в колонку is_sent будем класть NULL вместо 1, то индекс у нас будет крошечный, так как в любой момент в нем будут храниться только не NULL значения, а их будет очень мало.
5. Встроенный по умолчанию подход к безопасности без дополнительной платы
При создании облака нового поколения мы не просто усовершенствовали архитектуру, но и улучшили ключевые атрибуты, такие как безопасность. В большинстве публичных облаков создаются приложения, а затем, когда они расширяются и становятся более функциональными, безопасность становится доступной для приложения и запускаемых сервисов. Для каждого приложения, которое Вы хотите защитить, требуется несколько сервисов, отличающихся по цене. Безопасность — главный принцип OCI, заложенный в приложения еще на этапах развертывания или миграции. Мы сделали большинство наших инструментов обеспечения безопасности бесплатными в Вашей среде.
Дополнительные возможности безопасности по умолчанию
Конфигурация безопасности по умолчанию устраняет ошибки настройки. Все данные по умолчанию шифруются при хранении и передаче.
Автоматическое обнаружение и устранение неполадок
Постоянное сканирование на предмет неправильной конфигурации, нарушений политики и подозрительной активности. Устранение проблем автоматически или после того, как Вы их рассмотрите.
Автоматическая база данных и защита данных
Автоматическое применение обновлений безопасности без простоев. Оценка безопасности конфигураций и данных баз данных и рекомендации обновлений.
Большинство служб безопасности встроены без дополнительной оплаты
Все ИТ-специалисты имеют доступ к средствам безопасности. Все больше приложений используют лучшие практики для обеспечения безопасности.
Пустые строки
В оракл есть одна очень интересная особенность, от которой они теперь уже никогда не смогут избавиться. Дело в том, что если вы кладете в БД пустую строку, то она сохраниться как NULL. Таким образом при последующем чтении вы никогда не получите пустой строки, а только NULL. Имейте так же в виду, что по этой же причине пустые строки не попадают в индекс, так что если вы будете делать запросы, план выполнения которых, будет использовать индекс, то ваше пустые (вернее NULL) строки вы никогда не получите, но об этом чуть позже.
Таблицы бывают разные
Кроме обычных таблиц в oracle как и во многих других БД есть так называемые индекс-таблицы, когда данные таблицы непосредственно лежат в индекс-дереве первичного ключа. Таким образом достигается сразу две вещи: во первых для чтения данных по первичному ключу вы имеете на одно чтение меньше, во вторых данные в таблице получаются упорядоченными по первичному ключу, так что операция ORDER BY PK будет выполняться без дополнительной сортировки. К недостаткам можно отнести тот факт, что отличить логирование в оперативные журнальные файлы данного индекса вы уже не сможете.
Еще один замечательный тип таблиц — это кластерные таблицы, которые позволяют хранить данные из двух или более таблиц кластеризованные по одному значению ключа в одном блоке данных. Это может быть весьма эффективно если вы всегда используете какие-нибудь таблицы совместно.
На основе кластерных таблиц есть еще кластерные хэш-таблицы, в которых для доступа вместо B-дерева используется таблица на основе хеша кластерного ключа. Звучит, конечно, очень интересно, но, честно говоря, на практике никогда не сталкивался.
Механизм восстановления данных
В СУБД Oracle можно включить архивацию вышеописанных оперативных журнальных файлов, и все изменения будут архивироваться. Таким образом при потере любого диска с блоками данных мы можем восстановить их на любой момент времени, включая момент прямо перед падением, накатив на последние архивные журнальные файлы текущий оперативный журнал.
OCI: полная платформа облачной инфраструктуры для любой нагрузки
Oracle Cloud Infrastructure включает все сервисы, необходимые для миграции, построения и выполнения всех ИТ-ресурсов — от существующих корпоративных нагрузок до новых cloud native приложений и платформ данных.
Уровни изоляции транзакций
В Oracle вообще нет уровня изоляции READ_UNCOMMITED. Дело в том, что в других базах данных он используется для достижения максимального параллелизма путем удаления блокировок чтения. Но в Oracle чтение и так всегда выполняется без блокировок, таким образом мы уже имеем все преимущества, которые может дать этот уровень, не вводя никаких дополнительных ограничений.
Вообще, в Oracle явно доступно всего два уровня изоляции: по умолчанию используется READ_COMMITTED, но при желании вы можете установить SERIALIZABLE.
Однако на уровне операторов (SELECT, UPDATE и т.д.) у вас по умолчанию уже есть REPEATABLE_READ, т.е. в рамках одного оператора вы всегда получаете согласованное чтение, что достигается конечно же за счет сегмента отката. Мне всегда очень нравился пример приводимый Томом Кайтом для описания того, что это дает. Допустим у вас есть очень большая таблица со счетами и вы выполняете SELECT на получение суммы. В Oracle, в отличие от многих других БД, даже если в середине вашего запроса другая транзакция переведет некоторую суммы с первого счета на последний, вы в итоге все равно получите данные актуальные на начало вашего запроса, так как дойдя до последний строчки ваш SELECT увидит, что строчка была изменена, пойдет в сегмент отката и прочитает данные, которые были в этой ячейке на момент начала выполнения запроса. Во многих других базах данных, вы получите ответ в виде суммы, никогда не существующей в вашей таблице. Однако в Oracle в данном случае есть опасность получить ORA-01555: snapshot too old.
В дополнение к стандартным уровням изоляции в Oracle еще есть так называемые READ_ONLY транзакции, которые дают REPEATABLE_READ в рамках всей транзакции, а не только в рамках одного оператора. Но как следует из названия, в такой транзакции вы можете выполнять только чтение.
Вам письмо
Что ж, возможно, у вас и нет почты, но предположим, что у вас есть новый файл. Общие требования, которые я слышал на протяжении многих лет, были: «Когда появляется новый файл в таком-то каталоге, нам нужна возможность видеть его, затем обрабатывать его… и все это должно происходить автоматически». Теперь, используя пакет DBMS_SCHEDULER из релиза 11g R2, вы можете установить наблюдение за файлом путем создания задачи (job). Задача будет отслеживать появление файла и производить определенные действия при его появлении. Например, отсылать вам уведомление на почту.
Платформа и сервисы разработки OCI
Интерфейсы и автоматизация
Console, интерфейс командной строки, API SDK, Cloud Shell и Resource Manager (Terraform)
Управление API
Управление API от проектирования API до развертывания с помощью шлюза API
Машинное обучение
Сервис полного жизненного цикла ML (предварительная подготовка данных, обучение, справочная информация)
Бессерверный
Функции для бессерверного выполнения кода
Базы данных
Сервисы Oracle Autonomous Database и MySQL
Контейнеры
Реестр контейнеров и Container Engine for Kubernetes
Потоковая передача
Совместимый с Kafka управляемый сервис потоковой передачи
Операции
Непрерывное развертывание, наблюдаемость, управление и мониторинг.
Сервис OCI представляет собой лучшее облако для всего Вашего инструментария разработки, поддерживающее многие партнерские облачные сервисы.
Связывание переменных
Наверное об этом уже наслышан каждый программист, но я все же упомяну о такой обязательной техники, как связывание переменных. Дело в том, что для каждого уникального запроса строится план разбора и кладется в кэш. Если различных запросов очень много, как, например, весьма распространенный запрос по ID, то на каждый запрос буден генериться свой план, к тому же они будут вытеснять из кэша все другие планы, что может в разы увеличить время отклика вашей базы данных.
Стоит так же заметить, что не стоит этим злоупотреблять и использовать связывание для столбцов с небольшим количеством различных значений, как-то флаг is_deleted, ведь различных запросов в этом случае будет не так много, а, возможно, для более конкретного запроса СУБД удастся построить более эффективный план.
Параллелизм: прощай, ручная настройка
Ну что ж, с выпуском последней версии СУБД Oracle необходимость тонкой настройки отпадает. Теперь появился простой способ сделать то, что я пытался объяснить в прошлом. Используя новый пакет DBMS_PARALLEL_EXECUTE, можно разделить большую таблицу на диапазоны по rowid, по значениям первичного ключа, либо используя какой-либо определенный пользователем критерий. Таблица разбивается логично, и база данных обрабатывает каждый из диапазонов в фоновом режиме, используя планировщик, запись ошибок в лог-файлы и другие возможности.
То, что было раньше трудоемкой ручной работой, становится предельно просто. Всегда приятно видеть, как что-то сложное становится простым.
Более подробная информация находится в руководстве «Database PL/SQL Packages and Types Reference 11g Release 2», глава 98 «DBMS_PARALLEL_EXECUTE».
Неблокирующее чтение и сегмент отката
Одной из наиболее замечательных особенностей СУБД Oracle является неблокирующее чтение, которое достигается за счет сегмента отката. Запросы к Oracle на чтение никогда не блокируются, так как данные почти всегда могут быть прочитаны из сегмента отката.
Сегмент отката дает еще одну плюшку: из него можно попытаться считать немного устаревшие данные для какой-нибудь таблицы, которые были в ней на определенный момент. Называется данная фича — flashback.
Однако иногда сегмент отката может подложить свинью: если у вас есть большой job для bulk удаления данных (удаление генерирует всех больше данных в сегменте отката), то вы можете получить ORA-01555: snapshot too old. Главное что в этом случае надо помнить — это то, что не надо переписывать ваш job, чтобы он коммитил через каждые N операций, а нужно использовать отдельный специально созданный сегмент отката для таких операций.
Автономные сервисы Oracle
Oracle применяет данную автоматизацию и дополнительную оптимизацию для конкретных нагрузок, используя Autonomous Database во всех ключевых сценариях использования баз данных, включая хранилище данных, обработку транзакций и базы данных документов. Oracle также полностью автоматизирует операционную систему с помощью Autonomous Linux, который автоматически выполняет обновления во время работы системы, обеспечивая доступность 99,995 %.
Oracle Autonomous Data Warehouse
Нагрузки аналитики и машинного обучения
Автономная обработка транзакций Oracle
Бизнес-приложения и смешанные нагрузки
Oracle Autonomous JSON Database
База данных документов
Autonomous Linux
Автономная операционная система
Полная совместимость с Red Hat Enterprise Linux
Модификация приложений на лету
Oracle Database 11g версии 2 вводит новое революционное решение: Edition-Based Redefinition (обновление на основе редакций). Оно позволяет сократить время простоя при применении обновлений. Предыдущие релизы СУБД Oracle позволяли производить «на лету» такие операции, как модификация параметров инициализации, создание индексов, переопределение и реорганизация практически любой структуры, и даже обновление самой СУБД. Единственный случай, когда действительно требовалась остановка экземпляра – чтобы предотвратить доступ к базе данных на достаточно продолжительный период времени – это модификация приложения. Такой подход применялся, потому что было нужно время для перекомпиляции PL/SQL модулей, пересоздания видов, изменения пользовательских привилегий и т.п. Требовалось, чтобы во время обновления никто не вызывал PL/SQL процедуры, не обращался к видам, и в принципе не работал с обновляемым приложением. В версии 2 СУБД Oracle 11g появляется новая возможность, связанная с понятием редакции (edition), которая позволяет произвести смену версии приложения, не останавливая его.
Рассмотрим понятие «редакция». Редакция – механизм, обеспечивающий поддержку многоверсионности для объектов базы данных. Новая редакция создается как потомок существующей редакции и полностью наследует «состояние» своего родителя: весь PL/SQL код, виды, синонимы, и т.д. Когда дочерняя редакция только-только создана, она является полной копией своего родителя, которую можно модифицировать любым образом, не опасаясь испортить какой-либо критически важный объект. Например, вы можете создать новую редакцию, основанную на вашем текущем коде приложения, затем в этой новой редакции пересоздать процедуру Р (вызвав CREATE OR REPLACE PROCEDURE P). В текущей версии – единственной, которую видят пользователи – сохранится старая версия процедуры Р, так что ваше обновление никак не повлияет на пользователей. Вы можете как угодно изменить процедуру Р в новой редакции и заново ее перекомпилировать – и все это без каких-либо последствий для текущей редакции.
Когда вы решаете, что изменения новой версии достаточно «правильные и завершенные», вы можете провести релиз новой редакции. Раньше пришлось бы отсоединить всех пользователей, которые работали с процедурой Р, а затем установить новую копию Р и проверить все процедуры, которые зависели от Р (вызывали ее в своем коде). Сейчас же мы можем выполнить всю эту работу в фоновом режиме, разрешив пользователям вызывать и использовать старую версию Р, пока мы обновляем приложение. Это позволяет избежать недоступности важных приложений в течение многих часов, как бывало раньше при установке обновлений. Данный механизм делает процесс внесения изменений в приложение мгновенным с точки зрения конечных пользователей – людей, которым это действительно важно.
Если вам нужна еще одна причина для обновления вашей СУБД до версии 11g релиза 2, то механизм Edition-Based Redefinition мог бы быть ей. В этом кратком описании я только поверхностно коснулся его возможностей, но я изложу этот материал более детально в следующих статьях. (Тем временем обратите внимание на руководство «Oracle Database Advanced Application Developer’s Guide 11g Release 2», глава 19 под названием «Edition-Based Redefinition» - там вы найдете больше информации).
2. Все, что Вам нужно для создания современных нативных облачных приложений.
Хотя OCI разработана специально для улучшения корпоративных приложений, те же инновации в сетевых технологиях, вычислениях и хранении делают нативные облачные приложения более производительными, отказоустойчивыми и масштабируемыми. OCI предлагает широкий спектр облачных сервисов и партнерскую экосистему, необходимую для создания производственных нативных облачных приложений.
Новая жизнь старых вещей
Иногда маленькие вещи вызывают большие изменения. В Oracle 11g v.2 одна из таких маленьких вещей – режим «legacy mode» утилиты Data Pump.
У каждого из нас есть скрипты, накапливаемые годами, которые используют морально устаревшие EXP и IMP утилиты. Хотя эти утилиты все еще существуют в последних релизах СУБД, но все же нужно понемногу уходить от их использования для повышения производительности и в силу некоторых функциональных причин. Многие нововведения из последних версий СУБД Oracle не поддерживают утилиты EXP и IMP, и количество случаев, когда эти утилиты не работают, растет с течением времени.
Но у вас все те же сценарии и скрипты, которые используют устаревший синтаксис консольных приложений EXP и IMP, и у вас нет времени, чтобы переписать их заново. Так что уход от устаревших технологий оказывается довольно проблематичным.
Но теперь все изменилось. Просто включите в Data Pump «legacy mode» – режим совместимости. Oracle 11g v.2 научила инструментарий Data Pump говорить на языке устаревших EXP и IMP. И теперь вы можете начать использование утилиты Data Pump без переписывания каждого из ваших скриптов, которые производят выгрузку и загрузку данных: замена старых команд на новые уже сделана за вас.
Позвольте Oracle кэшировать ваши данные эффективно
В Oracle все данные читаются-пишутся не прямо на диск, а через кэш. По умолчанию кэш основан на LRU алгоритме, так что если вы читаете какую-нибудь очень большую табличку по идентификатору в больших количествах, запрашивая в каждый раз новую строчку, то такие запросы могут вытеснять из кэша небольшую статическую табличку, которой бы самое милое дело постоянно находиться в кэше. Для таких целей при создании таблицы вы можете указать специальный вид кэша, куда будут ходить запросы к вашим таблицам. Так для первой таблицы в вышеописанном примере подойдет кэш RECYCLE, который по сути не хранит никакие данные, а сразу их выбрасывает из кэша. А для второй таблицы подойдет кэш KEEP, который позволить хранить в кэше небольшие статические таблице и запросы ко всем остальным таблицам не будут вытеснять данные статических таблиц из кэша.
Сервисы для разработчиков
Создание, развертывание современных облачных приложений и управление ими с помощью удобных для разработчиков инструментов и сервисов.
Думаю, многим разработчикам ПО и предпринимателям буду интересны некоторые особенности лицензионной политики и технической поддержки компании Oracle.
Начать разработку своих приложений на Oracle очень просто, и денег за это Oracle не возьмет. Интересное начнётся потом, когда проект надо будет легализовать.
Order Form и стоимость стандартной технической поддержки
При каждой покупке лицензий Oracle обеими сторонами подписывается документ, называемый «Order Form», который содержит перечисление лицензий, дату начала их действия и стоимость.
За все свои продукты и техподдержку Oracle требует 100% предоплату. Исключение из этого правила могут получить только бюджетные организации, попросив это официальным письмом.
При покупке программных продуктов сразу в обязательном порядке продается и стандартная техподдержка для них сроком на 1 год.
Разумеется, по программе СТП Oracle решает только массовые проблемы. Если хотите получить внимание инженеров Oracle именно к своей конфигурации, то к стандартной ТП необходимо докупить расширенную техподдержку (менеджер Oracle прикинет, сколько часов и на что им надо будет потратить, умножит на 3,14 и т.д.). Разумеется, необходима 100% предоплата, а по окончании договора неизрасходованные средства не возвращаются и не переносятся на следующий период расширенной поддержки.
Стоимость СТП на 1-й год составляет 22% от стоимости лицензий, указанной в Order Form. Каждый последующий год стоимость СТП увеличивается на 3% от своей величины (не от стоимости лицензий, а на 3% от своего предыдущего значения).
Эту надбавку Oracle называет «inflation rate». В лицензионном соглашении [1] Oracle обещает не повышать стоимость стандартной техподдержки более чем на 4% в год (Пункт H на стр. 4).
Последствия отказа от техподдержки
От стандартной техподдержки со второго года и далее можно отказаться, и продолжать легально использовать купленные продукты, но есть два нюанса:
1. Если Вам когда-нибудь потом понадобится СТП, то перед тем, как Вы сможете купить её, Oracle потребует заплатить штраф — в 1,5 раза больше, чем стоила бы стандартная ТП за пропущенный период.
Понятно, что таким образом Oracle страхуется от вариантов «раз в 3 года купил СТП сроком на 1 год и обновил версию ПО». По-моему некоторую сумму за возобновление ТП можно требовать, но наличие повышающего коэффициента при этом совершенно выходит за границы добра. Мало того, что по сути Oracle получает выплату за неоказанную услугу (в России это незаконно), так еще и в 1,5 раза больше.
2. Свои программные продукты Oracle разделяет на «комплекты лицензий» (subset of licenses) — группы лицензий по их назначению (Database, Middleware, Applications и пр.), причем не важно, что они куплены в разное время по разным Order Form.
Например, все Купленные Вами Database Oracle отнесет к одному «комплекту лицензий», а WebLogic Server попадает уже в другую. Подробнее, какое ПО входит в какой «комплект» можно посмотреть в Oracle Software Technical Support Policies [2].
Oracle требует, чтобы у Пользователя все лицензии из одного «комплекта» находились на одном уровне стандартной техподдержки. Уровней целых два – «есть СТП» и «нет СТП».
Теперь предположим, у Вас есть давно купленный Database Standard, на котором у Вас крутится какая-то вспомогательная система, и Вам не нужна была СТП на неё. Со временем Вам потребовалось докупить на бизнес-критичную задачу Database Enterprise. Вот Вы и попали на штраф за пропущенный период СТП для DB Standard.
Oracle предлагает замечательный выход такой из ситуации – отказаться от «лишних» лицензий, по которым Вы не хотите платить штраф за пропущенный период СТП, написав так называемый Termination Letter.
Тут некоторые задумаются, нельзя ли передать ли DB Standard дружественному юрлицу перед покупкой DBE. Не углубляясь, замечу, что совместно использовать Oracle разными «своими» юрлицами тоже не просто, например, нельзя пускать пользователей из другого юрлица в DB, если она лицензирована по NUP, а не по CPU.
Особенности политики скидок Oracle
Один из положительных моментов сотрудничества с Oracle состоит в том, что если Вы покупаете лицензии на миллионы долларов, то имеете шанс добиться большой скидки, даже более 50% от GPL (стандартного прайс-листа) [3]. При этом пропорционально изменяется и стоимость стандартной техподдержки.
Но и тут не обошлось без пары половников дегтя:
1. Скидка связана с конкретными Order Form, и покупка новых лицензий никак не влияет на стоимость СТП для лицензий, купленных ранее. Т.е. у Вас СТП на один и тот же продукт, купленный по разным Order Forms, может стоить по-разному. Если компания у Вас росла, росли объемы закупок, скидка увеличивалась, и Вы захотели платить меньше за СТП первых лицензий, то вариантов нет – пишите Termination Letter, отказывайтесь от них, потом покупайте их повторно, но уже с большей скидкой.
2. В то же время, отказ от части лицензий внутри одной Order Form приводит к перерасчету скидки на все продукты, купленные по этой Order Form. Алгоритм пересчета, если он вообще есть, известен только Oracle. Из опыта мне известно, что хотя стоимость СТП и не увеличивается, но может совсем не уменьшиться, делая бессмысленным отказ от небольшой части лицензий из одной Order Form ради уменьшения суммы СТП.
Goodbye, SUN
После покупки SUN Oracle начала распространять свою отработанную политику техподдержки на оборудование:
1. Сокращено количество вариантов техподдержки.
2. Введен штраф за пропущенный период техподдержки – как обычно, в полтора раза выше, чем стоимость ТП за тот же период.
3. Чтобы принудить всех купить техподдержку, сервисным центрам вообще запретили ремонтировать железо не проходящее по контракту техподдержки.
Заключение
Замечательные продукты разрабатывают в компании Oracle (говорят, только инсталляторы никак им пока не удаются), и взять их легко можно с официального сайта, и защиты от нелицензионного использования в них нет…
Но лучше все же внимательно прочитать лицензионное соглашение до начала разработки, чтобы не было потом неприятных сюрпризов.
Нужно ли программисту прикладных приложений понимать как работает БД? Том Кайт, признанный специалист Oracle, автор знаменитой колонки asktom, в своей книге «Oracle для профессионалов. Архитектура и основные особенности.» настаивает, что это просто необходимо. Даже если в вашей команде есть грамотный администратор, знание того, как работает СУБД Oracle поможет вам лучше понимать друг друга и эффективней взаимодействовать, не говоря уже о случае, когда такого специалиста у вас нет. В данном топике я упомяну об основных вещах, понимание которых позволит грамотно работать с БД Oracle и использовать некоторые её особенности с большой отдачей для вашего приложения. Если же вы уже прочитали вышеупомянутую книгу Тома Кайта, то можете просто исползовать эту статью в качестве памятки. Одно замечание — книжку я читал давно, и тогда еще последней версией БД Oracle была 9i, курсы по администрированию я тоже проходил по девятке, так что, если в десятке и выше что-то поменялось и добавилось, то не обессудьте. Хотя я пишу о довольно фундаментальных вещах, которые вряд ли сильно поменяись.
Соответствие требованиям Oracle Cloud
Обширная программа обеспечения соответствия требованиям Oracle Cloud предназначена для обслуживания заказчиков во всем мире в сложной и быстро меняющейся бизнес-среде и нормативно-правовой среде. Oracle управляет более чем 80 глобальными, региональными и отраслевыми программами для предоставления сторонних аттестаций, таких как SOC, ISO, HIPAA и FedRAMP, а также рекомендаций по таким стандартам, как GxP, NIST, GDPR и FISC. Правила конфиденциальности данных варьируются в зависимости от региона и OCI активно поддерживают такие программы для соответствия стандартам, как PCI-DSS. OCI обеспечивает дополнительную защиту конфиденциальности путем предоставления сервисов, по умолчанию зависящих от региона, с использованием дополнительных функций конфиденциальности, а также опубликованных стандартов обработки данных и регулярной отчетности по запросам правоохранительных органов.
Путешествие во времени
Oracle 11g версии 1 предоставил возможность долгосрочных ретроспективных запросов, которые позволяют сделать выборку из данных, которые были в базе месяцы или годы назад (подобные запросы были подробно описаны в предыдущей статье журнала Oracle Magazine, «Managing History»). Одно из ограничений первоначального релиза – невозможность откатить большинство DDL-операций (т.е. операций, которые изменяют структуру таблиц). Например, таких операций как удаление какого-либо столбца таблицы или удаление всех строк из таблицы с помощью выражения TRUNCATE TABLE.
В релизе 2 эти и многие другие DDL-операции теперь поддерживаются, и возможность откатить изменения назад во времени перестала быть компромиссом. Это важно, поскольку мы на самом деле никогда не заканчиваем разработку наших приложений – мы постоянно меняем их и таблицы, в которых приложения хранят данные.
Заказчики выбирают OCI для повышения производительности и снижения затрат
Компания использует решение по безопасности SaaS сервиса на базе OCI для мониторинга тысяч нагрузок на каждого заказчика. Это позволяет повысить производительность в 60 раз и снизить затраты на 90 %.
Каждый месяц проводит масштабные облачные веб-конференции для 20 миллионов активных пользователей. Компания сэкономила 80 % на сетевых соединениях, перейдя на OCI, и повысила производительность на 20 %.
Компания планирует снизить затраты на 50 % для своей ERP-системы, поддерживающей 150 000 сотрудников, по всей стране.
Новые привилегии для новых возможностей
Каталог объектов (directory objects) – отображение баз данных Oracle на файловую систему ОС – получил новую привилегию: EXECUTE. (Раньше на каталог объектов могли выдаваться только привилегии READ или WRITE, которых было достаточно, поскольку единственное, что мы могли делать с каталогом объектов – это писать в него или читать из него).
Oracle 11g версии 2 также предусматривает возможность запуска «препроцессора» для файлов ОС. Например, вы можете указать в качестве программы-препроцессора утилиту-распаковщик, работающую в режиме командной строки. Тогда у вас появится возможность напрямую запрашивать сжатый файл из файловой системы и отпадет необходимость хранить его в распакованном виде.
Чтобы выполнить эту операцию безопасно (позволить СУБД Oracle безопасно вызвать эту консольную программу) мы должны выдать привилегию EXECUTE на директорию, содержащую исполняемый файл программы. Это позволяет осуществлять строгий контроль над тем, какие именно программы вызывались из баз данных Oracle, и избежать случайного вызова троянов.
3. Автономные сервисы автоматически защищают, настраивают и масштабируют Ваши приложения
Автономные сервисы предназначены для автоматизации установки обновлений и настройки производительности операционной системы и базы данных. Неправильная конфигурация и плохая оптимизация могут снизить производительность приложения, а неправильно примененные обновления безопасности могут внести уязвимости в систему. Автономные сервисы предназначены для снижения рисков и затрат, связанных с человеческими ошибками:
Автоматизация инициализации новых баз данных и вычислительных экземпляров
Автоматизация настройки доступа пользователей
Автоматизация шифрования сервисов
Автоматизация установки обновлений в режиме онлайн
Автоматизация масштабирования ресурсов по мере изменения спроса
Автоматизация настройки производительности
Читайте также: