Oracle Database 10g: самоуправляемая база данных Grid готова к работе
Есть тенденции, и есть те, кто их устанавливает. В начале и середине 1990-х годов корпорация Oracle предвидела парадигму интернет-вычислений, которую теперь организации всех типов внедряют в основу своего бизнеса. В рамках этого процесса ИТ-инфраструктура приобрела чрезвычайно важное значение для предприятий.
И это оказало большое влияние на обеспечение нужного уровня готовности, масштабируемости и производительности ИТ-систем для организаций всех размеров. Период простоя (downtime) даже для крайне необходимых операций обслуживания теперь недопустим, если весь бизнес организации должен функционировать в режиме 24/7 (24 часа в сутки; 7 дней в неделю).
В то же время более высокий, чем когда-либо, уровень конкуренции в современной глобальной экономике оказывает возрастающее давление на предприятия, заставляя их минимизировать свои расходы всюду, в том числе и в ИТ, чтобы сохранить уровень доходности.
Хотя ИТ-системы становятся неотъемлемой частью основного бизнеса предприятия, в то же время они становятся более сложными, трудными в управлении и более дорогими. Сложность добавляет расходы повсюду, это относится ко времени, затратам труда, потенциальным ошибкам и неспособности эффективного восстановления после сбоев.
Эти проблемы относятся к причинам столь большого интереса в настоящее время к коммерческим grid-сетям, которые частично поддерживаются эффективными (в ценовом отношении) blade-серверами. Благодаря небольшим последовательно производимым расходам, организации теперь могут получить больше мощности для обработки данных, которая может использована всеми ресурсами центра данных, более высокий уровень производительности, готовности и масштабирования в случае необходимости; но это возможно только если есть ПО, которое может эффективно использовать преимущества такой архитектуры.
Очевидно, что наступило время для ПО, которое управляет и контролирует самое себя, ПО, которое эффективно снижает сложность управления в ценовом отношении.
Без такого самоуправляющегося ПО компании окажутся заложниками возрастающей сложности своих приложений и разнородных систем, для которых сейчас необходимы десятки обученных администраторов.
Oracle Database10g была спроектирована для того, чтобы решить эти проблемы. Обеспечивая более высокие уровни производительности и готовности при сокращении затрат на управление, Oracle Database10g позволяет создавать центры данных для глобальных компаний, а также для предприятий с ресурсами, распределенными по всему миру, для оптимального использования и входа в новую эру мощных и управляемых вычислений в рамках предприятия.
Oracle Database10g – это реализация представлений корпорации Oracle об управляемости, охватывающей все предприятие стратегии, которая начала формироваться много лет тому назад. У этой стратегии управляемости две цели:
— упростить само управление базами данных, автоматизируя большую часть мониторинга и поддержки, и
— обеспечить центры данных богатым на возможности инструментом управления, который позволит им управлять всеми компонентами (а не только базой данных), которыми эти центры данных должны управлять, независимо от того, где эти компоненты находятся (в самом центре данных, распределены по grid-сети или по всему миру), и чем они являются (внешняя память, кластеры, серверы приложений и т.д.). Все это начинается с самоуправляемой базы данных.
самоуправляемая база данных
Долгосрочное представление Oracle об управляемости заключается в полной автоматизации всех задач, связанных с управлением базами данных Oracle. За последние три года кросс-функциональная команда из более чем 200 разработчиков и архитекторов Oracle была вовлечена в создание инфраструктуры и инструментов для поддержки этого представления об проактивном, автоматическом управлении базой данных. Автоматизация этих ежедневных, рутинных задач управления базами данных Oracle позволит ИТ-профессионалам использовать лучше и в большей степени свои таланты для решения стратегических задач.
новая аналитическая инфраструктура самоуправления
Так как же все это устроено? Базе данных со свойствами самонастройки (self-tuning) и самоуправления необходимы возможности автоматически "обучаться" тому, как она используется. В Oracle Database10g была создана полностью новая инфраструктура, которая позволяет СУБД собирать информацию о рабочей нагрузке и использовать ее для принятия многочисленных решений по самоуправлению. Соответствующий инструментарий был встроен на каждом уровне технологии, собирая жизненно важные метаданные, которые будут использоваться для диагностирования проблем; эти данные будут сохранены в базе данных, а именно в Automatic Workload Repository (AWR); основном компоненте всей новой инфраструктуры управления, которому принадлежит центральная роль как "хранилище данных базы данных."
Освоить все эти механизмы помогает полный набор “советчиков” (advisors), которые предоставляют указания по дальнейшей оптимизации работы СУБД. Например, SQL Tuning and SQL Access Advisor, предоставляют рекомендации по более быстрому выполнению SQL-предложений. “Советчики” по использованию оперативной памяти позволяют измерять компоненты, которые там находятся, не прибегая к методу проб и ошибок (trial-and-error). Segment Advisor позволяет справиться с проблемами использования внешней памяти, такими как утилизация плохо используемого пространства, предсказание размеров новых таблиц и индексов, анализ тенденций роста. Undo Advisor позволяет следить за табличным пространством отката (undo).
Полная инфраструктура сигналов (alert) интегрирована с этими компонентами для уведомления администраторов о любой текущей и “зависшей” (impending) проблеме; все эти компоненты доступны через веб-консоль Enterprise Manager. Многие сигналы предлагают рекомендуемые действия по исправлению проблем, о которых они сообщают. Вся необходимая инфраструктура и соответствующие компоненты, такие как EM, устанавливаются автоматически при установке Oracle Database10g либо на одном компьютере, либо в кластерной конфигурации Real Application Clusters (RAC).
целостное самоуправление
Наиболее революционный аспект новой самоуправляемой СУБД Oracle — это ее способность диагностировать свои собственные проблемы производительности. Oracle Database10g включает “машину” самодиагностики (self-diagnostic engine), встроенную в ядро СУБД и называемую Automatic Database Diagnostic Monitor (ADDM). ADDM автоматически отслеживает состояние базы данных через короткие, регулярные интервалы (30 минут по умолчанию), предоставляя диагностику текущей производительности базы данных. Вы получаете полный список всех проблем, обнаруженных ADDM, и возможные решения для них. Большая часть данных ADDM (и других “советчиков”) представляется в графической форме: line graphs over time, bar charts, pie charts, подходящие для конкретного типа данных, позволяют легко получить представление о сути дела за один взгляд.
Помимо изучения результатов проактивного анализа ADDM, вы можете запустить ADDM вручную из Enterprise Manager или в командной строке, используя его PL/SQL-интерфейс. ADDM выполняет анализ “сверху-вниз” (top-down) потенциальных узких мест, выдавая набор открытий, который включает основные причины (root causes) и рекомендации с логическим обоснованием. Помимо идентификации проблем, ADDM также сообщает о том, какое влияние каждая из этих проблем имеет на общую системную производительность и что можно добиться их решением. Такой анализ влияний и преимуществ, полученных благодаря решению проблем (impact-benefit analysis), поможет АБД сфокусироваться на проблемах, решение которых позволит добиться наибольшего роста производительности.
Питер Дессер (Peter Deusser) и Дхармендра Пател (Dharmendra Patel) из фирмы Aventis Pharma рассматривают возможность “выжать” более высокую производительность из приложений поставщика, благодаря использованию SQL Access Advisor и SQL Tuning Advisor. Фирма Aventis — это глобальная фармацевтическая компания со штаб-квартирами в Страсбурге, Бриджвотере и центрами по исследованиям и разработкам в Париже, Бриджвотере, Франкфукте, и Токио.
Группа Дессера ответственна за базы данных, которые управляют последними этапами клинических исследований, отслеживают неблагоприятные случаи, а также за базы данных по регулированию. Согласно Дессеру, "так как мы в основном полагаемся приложения поставщиков, то мы не можем изменять или повлиять на SQL-предложения, которые они посылают базе данных, если есть проблемы производительности. Поэтому мы хотим быть в состоянии добиться более высокой производительности, не ожидая исправления от поставщиков. Если мы сможем улучшить производительность и готовность, будучи уже на этапе эксплуатации, то это хороший шанс для нас."
поддерживая бизнес в режиме 24/7
В наше время простой практически не допустим ни для одной компьютерной системы. Многие из новых функций автоматизации управления в СУБД Oracle Database 10g разработаны для того, чтобы предвидеть и предотвратить простой. Например, оптимизатор теперь автоматически собирает свою собственную статистику и интеллектуально “освежает” ее, когда это нужно, а именно тогда, когда таблицы баз данных были значительно изменены. Это важно, так как использование устаревшей статистики может привести к плохой производительности. Автоматическое обновление статистики должно существенно помочь решению проблем производительности. Типичная проблема у пользователей, у которых на местах нет администраторов баз данных, заключается в том, что люди не представляют, что они должны собирать, начинать и обновлять, статистику баз данных.
Другая функция, которая обеспечит лучшую производительность и минимизирует число ошибок и проблем, связанных с оперативной памятью — это новая автоматизированная функция измерения (sizing) системной глобальной области (system global area, SGA). Теперь вместо ручного конфигурирования размеров оперативной памяти, выделенной кэшам буферов базы данных (database buffer cache), разделяемому пулу (shared pool), пулу для Java (Java pool) большому пулу (large pool), как это было в прошлом, АБД должны использовать автоматизированную функцию управления разделяемой оперативной памяти (shared memory management capability) и позволить самой СУБД Oracle Database 10g управлять этой памятью. И поскольку эта память автоматически выделяется различным пулам, то по мере изменения обрабатываемых нагрузок теперь не обязательно настраивать каждый компонент SGA на максимальные значения, чтобы справиться с пиковыми нагрузками.
И, конечно, новые, сгенерированные сервером сигналы (alerts) помогут предотвратить наступление сбоев, предоставляя администраторам точные и своевременные предупреждения, а также предлагая им действия для решения проблем.
искусство производительности
Автоматизированные механизмы настройки в СУБД Oracle Database 10g, особенно автоматизированное обновление статистики в оптимизаторе, ADDM, SQL Tuning Advisor и SQL Access Advisor, не только повышают уровни управляемости и готовности СУБД, но также напрямую влияют на производительность, так как позволяют любому АБД овладеть процессами настройки. Нет смысла использовать СУБД, которая показывает высокую производительность только тогда, когда затрачивается немало усилий для ее достижения, подчеркивает Винит Бух (Vineet Buch), директор подразделения Performance Product Management корпорации Oracle: "Это можно сравнить с обладанием Ferrari, когда водитель не может вести машину со скоростью больше 65 миль в час."
Кроме того, в СУБД появились улучшения, строго сфокусированные на производительности. Например, значительно улучшена производительность PL/SQL, так как компилятор PL/SQL был переписан для генерации меньшего по размеру и более оптимального кода.
Помимо прозрачных улучшений производительности, таких как более быстрый PL/SQL, есть еще несколько новых дополнительных средств для повышения производительности, которыми АБД и разработчики могут воспользоваться, некторые из них относятся к системам поддержки принятия решений (decision-support-system) или хранилищам данных. Например, приложения, которые интенсивно вставляют и просматривают данные в режиме first-in, first-out; такие, как системы, используемые телекоммуникационными компаниями для сбора данных о телефонных звонках, а затем генерации счетов, при которой данные выбираются в том порядке, как они были введены; они могут получить значительный рост производительности, используя новые отсортированные хэш-кластерные структуры таблиц в СУБД Oracle Database 10g.
Помимо улучшений, которые сводятся к более быстрой обработке данных в СУБД, есть другой тип улучшений производительности: средства, которые АБД используют для выполнения своей работы.
Grid
Многие из новых крупных функций самоуправления в СУБД Oracle Database 10g напрямую облегчат развертывание и полномасштабное оперирование управления центров данных, инициативы по серверной консолидации и эволюция к коммерческим grid-вычислениям. Самоуправляемая СУБД — это только часть решения. Гораздо чаще среда приложения (application stack) состоит не только из сервера баз данных, но также из сервера приложений, кода приложений и т.д.; и все эти компоненты должны также управляться.
Второй “фишкой” в этом релизе СУБД Oracle является управление grid-средой. EM предоставляет средства управления и утилиты для поддержки всего цикла жизни системы. Это автоматизированное предоставление (provisioning), управление и мониторинг во время системных операций, позволяются изменения в процессе функционирования системы. Автоматизация всего жизненного цикла даже более критично в среде grid, так как вам необходимо делать все это эффективно и надежно в среде из множества компонентов. Далее, вы хотите единую систему чтобы обслуживать все типы элементов: базу данных, приложения, хосты, элементы сети и внешней памяти.
Применяя EM, администраторы не только имеют доступ к ключевым функциям СУБД Oracle Database 10g, таким как ADDM, но они могут также управлять и другими компонентами grid, такими как балансировщики нагрузки (load balancers) и системы внешней памяти. Работающий а среде веб EM управляет любым числом баз данных Oracle: фермами серверов приложений Oracle и их хостами, такими как Linux- или UNIX-хосты. EM Application Performance Management (APM) мониторит в режиме реального времени производительность ваших веб-приложений. APM делает это с позиций конечного пользователя и позволяет “заглубляться” (drill down) в индивидуальные компоненты для детального анализа причин неполадок.
управление сложностью с использованием Power to Spare
Желание воспользоваться преимуществами лучшего управления системами и меньшими расходами было основной причиной для сильной тенденции к серверной консолидации, начиная с 1997. В статье "Server Consolidation: An Updated Look" (2003 г.) аналитики Gartner Джон Фелпс (John Phelps) и Майк Чуба (Mike Chuba) пишут: значение проблемы управления серверами очевидно на примере типичного центра обработки данных предприятия, который, вероятно, содержит сотни Unix и Intel серверов. Добавление одного приложения, как правило, вызывает добавление к датацентру от трех до пяти серверов для таких этапов как эксплуатация, разработка, тестирование и резервное копирование. Многие их этих распределенных серверов используются с низким уровнем загрузки. Ничего удивительного, что предприятия стремятся консолидировать свои серверы.
Возможности самоуправления СУБД Oracle Database 10g помогают максимизировать использование существующих ресурсов, тем самым помогая избежать частых покупок дополнительного оборудования. Например, функция Automatic Shared Memory Management позволяет более оптимально использовать доступную память SGA, а возможность регенерации (reclaim) пространства из существующих таблиц может снять необходимость в покупках дополнительной внешней памяти. Это те преимущества, которые Дессер из Aventis надеется достичь в долгосрочном плане с проектами консолидации. Будучи обязан управлять более 100 базами данных, Дессер говорит: «Мы стремимся к лучшей управляемости. Должно стать легче, если мы консолидируем все наши различные базы данных в несколько стоек."
Келли Вайсет (Kelli Wiseth), директор по технологиям в Alameda Tech Lab and Research Center.
Oracle Database 10g снимает барьер размеров файлов
Постоянно растущие в размерах жесткие диски и поддержка для больших файлов (больше 2 Гигабайт), доступная в 64-битных операционных системах заставляют задуматься: то, что рассматривается как очень большое в этом году, может быть оценено как небольшое через несколько лет. С новой функцией bigfile tablespace “потолок” для ваших сверхбольших баз данных просто поднимается до небес (и теоретически зависит только от операционной системы, что она может поддерживать — 8 exabytes. Это 8 миллионов терабайт, или на три порядка больше текущего лимита в 8 петабайт.
Функция bigfile tablespace упрощает управление базами данных, позволяя вам создавать табличные области в одном файле (single-file tablespace) и выполнять операции на уровне табличной области, а не на уровне лежащего в основе файла базы данных (чтобы поддерживать эту возможность, синтаксис SQL для предложения ALTER TABLESPACE был расширен.)
Создание bigfile tablespace не многим отличается от создания обычных табличных областей (теперь называемых smallfile tablespaces чтобы подчеркнуть разницу между двумя типами); одна разница в том, что размер bigfile tablespace может быть специфицирован не только в килобайтах и мегабайтах, но и в гигабайтах и терабайтах. Вот пример:
CREATE BIGFILE TABLESPACE datahuge /DATA FILE'/u02/oracle/data/ bigtbs01.dbf' SIZE 2T;
Не имеет смысла использовать bigfile tablespaces на системах, которые не поддерживают больших файлов. В этом случае значительно ограничиваются возможности табличных областей.
СУБД Oracle Database 10g может поддерживать оба типа bigfile и smallfile tablespaces одновременно; табличные пространства SYSTEM и SYSAUX продолжают использовать smallfile tablespaces и не могут быть созданы иначе. Bigfile tablespaces поддерживаются только для локально управляемых табличных областей с автоматизированным управлением сегментов пространства (tablespaces with automatic segment-space management).
И наконец, bigfile tablespaces должны использоваться с Automated Storage Management, или другим логическим менеджером томов, который поддерживает динамически расширяемые логические тома, striping и RAID.
И это оказало большое влияние на обеспечение нужного уровня готовности, масштабируемости и производительности ИТ-систем для организаций всех размеров. Период простоя (downtime) даже для крайне необходимых операций обслуживания теперь недопустим, если весь бизнес организации должен функционировать в режиме 24/7 (24 часа в сутки; 7 дней в неделю).
В то же время более высокий, чем когда-либо, уровень конкуренции в современной глобальной экономике оказывает возрастающее давление на предприятия, заставляя их минимизировать свои расходы всюду, в том числе и в ИТ, чтобы сохранить уровень доходности.
Хотя ИТ-системы становятся неотъемлемой частью основного бизнеса предприятия, в то же время они становятся более сложными, трудными в управлении и более дорогими. Сложность добавляет расходы повсюду, это относится ко времени, затратам труда, потенциальным ошибкам и неспособности эффективного восстановления после сбоев.
Эти проблемы относятся к причинам столь большого интереса в настоящее время к коммерческим grid-сетям, которые частично поддерживаются эффективными (в ценовом отношении) blade-серверами. Благодаря небольшим последовательно производимым расходам, организации теперь могут получить больше мощности для обработки данных, которая может использована всеми ресурсами центра данных, более высокий уровень производительности, готовности и масштабирования в случае необходимости; но это возможно только если есть ПО, которое может эффективно использовать преимущества такой архитектуры.
Очевидно, что наступило время для ПО, которое управляет и контролирует самое себя, ПО, которое эффективно снижает сложность управления в ценовом отношении.
Без такого самоуправляющегося ПО компании окажутся заложниками возрастающей сложности своих приложений и разнородных систем, для которых сейчас необходимы десятки обученных администраторов.
Oracle Database10g была спроектирована для того, чтобы решить эти проблемы. Обеспечивая более высокие уровни производительности и готовности при сокращении затрат на управление, Oracle Database10g позволяет создавать центры данных для глобальных компаний, а также для предприятий с ресурсами, распределенными по всему миру, для оптимального использования и входа в новую эру мощных и управляемых вычислений в рамках предприятия.
Oracle Database10g – это реализация представлений корпорации Oracle об управляемости, охватывающей все предприятие стратегии, которая начала формироваться много лет тому назад. У этой стратегии управляемости две цели:
— упростить само управление базами данных, автоматизируя большую часть мониторинга и поддержки, и
— обеспечить центры данных богатым на возможности инструментом управления, который позволит им управлять всеми компонентами (а не только базой данных), которыми эти центры данных должны управлять, независимо от того, где эти компоненты находятся (в самом центре данных, распределены по grid-сети или по всему миру), и чем они являются (внешняя память, кластеры, серверы приложений и т.д.). Все это начинается с самоуправляемой базы данных.
самоуправляемая база данных
Долгосрочное представление Oracle об управляемости заключается в полной автоматизации всех задач, связанных с управлением базами данных Oracle. За последние три года кросс-функциональная команда из более чем 200 разработчиков и архитекторов Oracle была вовлечена в создание инфраструктуры и инструментов для поддержки этого представления об проактивном, автоматическом управлении базой данных. Автоматизация этих ежедневных, рутинных задач управления базами данных Oracle позволит ИТ-профессионалам использовать лучше и в большей степени свои таланты для решения стратегических задач.
новая аналитическая инфраструктура самоуправления
Так как же все это устроено? Базе данных со свойствами самонастройки (self-tuning) и самоуправления необходимы возможности автоматически "обучаться" тому, как она используется. В Oracle Database10g была создана полностью новая инфраструктура, которая позволяет СУБД собирать информацию о рабочей нагрузке и использовать ее для принятия многочисленных решений по самоуправлению. Соответствующий инструментарий был встроен на каждом уровне технологии, собирая жизненно важные метаданные, которые будут использоваться для диагностирования проблем; эти данные будут сохранены в базе данных, а именно в Automatic Workload Repository (AWR); основном компоненте всей новой инфраструктуры управления, которому принадлежит центральная роль как "хранилище данных базы данных."
Освоить все эти механизмы помогает полный набор “советчиков” (advisors), которые предоставляют указания по дальнейшей оптимизации работы СУБД. Например, SQL Tuning and SQL Access Advisor, предоставляют рекомендации по более быстрому выполнению SQL-предложений. “Советчики” по использованию оперативной памяти позволяют измерять компоненты, которые там находятся, не прибегая к методу проб и ошибок (trial-and-error). Segment Advisor позволяет справиться с проблемами использования внешней памяти, такими как утилизация плохо используемого пространства, предсказание размеров новых таблиц и индексов, анализ тенденций роста. Undo Advisor позволяет следить за табличным пространством отката (undo).
Полная инфраструктура сигналов (alert) интегрирована с этими компонентами для уведомления администраторов о любой текущей и “зависшей” (impending) проблеме; все эти компоненты доступны через веб-консоль Enterprise Manager. Многие сигналы предлагают рекомендуемые действия по исправлению проблем, о которых они сообщают. Вся необходимая инфраструктура и соответствующие компоненты, такие как EM, устанавливаются автоматически при установке Oracle Database10g либо на одном компьютере, либо в кластерной конфигурации Real Application Clusters (RAC).
целостное самоуправление
Наиболее революционный аспект новой самоуправляемой СУБД Oracle — это ее способность диагностировать свои собственные проблемы производительности. Oracle Database10g включает “машину” самодиагностики (self-diagnostic engine), встроенную в ядро СУБД и называемую Automatic Database Diagnostic Monitor (ADDM). ADDM автоматически отслеживает состояние базы данных через короткие, регулярные интервалы (30 минут по умолчанию), предоставляя диагностику текущей производительности базы данных. Вы получаете полный список всех проблем, обнаруженных ADDM, и возможные решения для них. Большая часть данных ADDM (и других “советчиков”) представляется в графической форме: line graphs over time, bar charts, pie charts, подходящие для конкретного типа данных, позволяют легко получить представление о сути дела за один взгляд.
Помимо изучения результатов проактивного анализа ADDM, вы можете запустить ADDM вручную из Enterprise Manager или в командной строке, используя его PL/SQL-интерфейс. ADDM выполняет анализ “сверху-вниз” (top-down) потенциальных узких мест, выдавая набор открытий, который включает основные причины (root causes) и рекомендации с логическим обоснованием. Помимо идентификации проблем, ADDM также сообщает о том, какое влияние каждая из этих проблем имеет на общую системную производительность и что можно добиться их решением. Такой анализ влияний и преимуществ, полученных благодаря решению проблем (impact-benefit analysis), поможет АБД сфокусироваться на проблемах, решение которых позволит добиться наибольшего роста производительности.
Питер Дессер (Peter Deusser) и Дхармендра Пател (Dharmendra Patel) из фирмы Aventis Pharma рассматривают возможность “выжать” более высокую производительность из приложений поставщика, благодаря использованию SQL Access Advisor и SQL Tuning Advisor. Фирма Aventis — это глобальная фармацевтическая компания со штаб-квартирами в Страсбурге, Бриджвотере и центрами по исследованиям и разработкам в Париже, Бриджвотере, Франкфукте, и Токио.
Группа Дессера ответственна за базы данных, которые управляют последними этапами клинических исследований, отслеживают неблагоприятные случаи, а также за базы данных по регулированию. Согласно Дессеру, "так как мы в основном полагаемся приложения поставщиков, то мы не можем изменять или повлиять на SQL-предложения, которые они посылают базе данных, если есть проблемы производительности. Поэтому мы хотим быть в состоянии добиться более высокой производительности, не ожидая исправления от поставщиков. Если мы сможем улучшить производительность и готовность, будучи уже на этапе эксплуатации, то это хороший шанс для нас."
поддерживая бизнес в режиме 24/7
В наше время простой практически не допустим ни для одной компьютерной системы. Многие из новых функций автоматизации управления в СУБД Oracle Database 10g разработаны для того, чтобы предвидеть и предотвратить простой. Например, оптимизатор теперь автоматически собирает свою собственную статистику и интеллектуально “освежает” ее, когда это нужно, а именно тогда, когда таблицы баз данных были значительно изменены. Это важно, так как использование устаревшей статистики может привести к плохой производительности. Автоматическое обновление статистики должно существенно помочь решению проблем производительности. Типичная проблема у пользователей, у которых на местах нет администраторов баз данных, заключается в том, что люди не представляют, что они должны собирать, начинать и обновлять, статистику баз данных.
Другая функция, которая обеспечит лучшую производительность и минимизирует число ошибок и проблем, связанных с оперативной памятью — это новая автоматизированная функция измерения (sizing) системной глобальной области (system global area, SGA). Теперь вместо ручного конфигурирования размеров оперативной памяти, выделенной кэшам буферов базы данных (database buffer cache), разделяемому пулу (shared pool), пулу для Java (Java pool) большому пулу (large pool), как это было в прошлом, АБД должны использовать автоматизированную функцию управления разделяемой оперативной памяти (shared memory management capability) и позволить самой СУБД Oracle Database 10g управлять этой памятью. И поскольку эта память автоматически выделяется различным пулам, то по мере изменения обрабатываемых нагрузок теперь не обязательно настраивать каждый компонент SGA на максимальные значения, чтобы справиться с пиковыми нагрузками.
И, конечно, новые, сгенерированные сервером сигналы (alerts) помогут предотвратить наступление сбоев, предоставляя администраторам точные и своевременные предупреждения, а также предлагая им действия для решения проблем.
искусство производительности
Автоматизированные механизмы настройки в СУБД Oracle Database 10g, особенно автоматизированное обновление статистики в оптимизаторе, ADDM, SQL Tuning Advisor и SQL Access Advisor, не только повышают уровни управляемости и готовности СУБД, но также напрямую влияют на производительность, так как позволяют любому АБД овладеть процессами настройки. Нет смысла использовать СУБД, которая показывает высокую производительность только тогда, когда затрачивается немало усилий для ее достижения, подчеркивает Винит Бух (Vineet Buch), директор подразделения Performance Product Management корпорации Oracle: "Это можно сравнить с обладанием Ferrari, когда водитель не может вести машину со скоростью больше 65 миль в час."
Кроме того, в СУБД появились улучшения, строго сфокусированные на производительности. Например, значительно улучшена производительность PL/SQL, так как компилятор PL/SQL был переписан для генерации меньшего по размеру и более оптимального кода.
Помимо прозрачных улучшений производительности, таких как более быстрый PL/SQL, есть еще несколько новых дополнительных средств для повышения производительности, которыми АБД и разработчики могут воспользоваться, некторые из них относятся к системам поддержки принятия решений (decision-support-system) или хранилищам данных. Например, приложения, которые интенсивно вставляют и просматривают данные в режиме first-in, first-out; такие, как системы, используемые телекоммуникационными компаниями для сбора данных о телефонных звонках, а затем генерации счетов, при которой данные выбираются в том порядке, как они были введены; они могут получить значительный рост производительности, используя новые отсортированные хэш-кластерные структуры таблиц в СУБД Oracle Database 10g.
Помимо улучшений, которые сводятся к более быстрой обработке данных в СУБД, есть другой тип улучшений производительности: средства, которые АБД используют для выполнения своей работы.
Grid
Многие из новых крупных функций самоуправления в СУБД Oracle Database 10g напрямую облегчат развертывание и полномасштабное оперирование управления центров данных, инициативы по серверной консолидации и эволюция к коммерческим grid-вычислениям. Самоуправляемая СУБД — это только часть решения. Гораздо чаще среда приложения (application stack) состоит не только из сервера баз данных, но также из сервера приложений, кода приложений и т.д.; и все эти компоненты должны также управляться.
Второй “фишкой” в этом релизе СУБД Oracle является управление grid-средой. EM предоставляет средства управления и утилиты для поддержки всего цикла жизни системы. Это автоматизированное предоставление (provisioning), управление и мониторинг во время системных операций, позволяются изменения в процессе функционирования системы. Автоматизация всего жизненного цикла даже более критично в среде grid, так как вам необходимо делать все это эффективно и надежно в среде из множества компонентов. Далее, вы хотите единую систему чтобы обслуживать все типы элементов: базу данных, приложения, хосты, элементы сети и внешней памяти.
Применяя EM, администраторы не только имеют доступ к ключевым функциям СУБД Oracle Database 10g, таким как ADDM, но они могут также управлять и другими компонентами grid, такими как балансировщики нагрузки (load balancers) и системы внешней памяти. Работающий а среде веб EM управляет любым числом баз данных Oracle: фермами серверов приложений Oracle и их хостами, такими как Linux- или UNIX-хосты. EM Application Performance Management (APM) мониторит в режиме реального времени производительность ваших веб-приложений. APM делает это с позиций конечного пользователя и позволяет “заглубляться” (drill down) в индивидуальные компоненты для детального анализа причин неполадок.
управление сложностью с использованием Power to Spare
Желание воспользоваться преимуществами лучшего управления системами и меньшими расходами было основной причиной для сильной тенденции к серверной консолидации, начиная с 1997. В статье "Server Consolidation: An Updated Look" (2003 г.) аналитики Gartner Джон Фелпс (John Phelps) и Майк Чуба (Mike Chuba) пишут: значение проблемы управления серверами очевидно на примере типичного центра обработки данных предприятия, который, вероятно, содержит сотни Unix и Intel серверов. Добавление одного приложения, как правило, вызывает добавление к датацентру от трех до пяти серверов для таких этапов как эксплуатация, разработка, тестирование и резервное копирование. Многие их этих распределенных серверов используются с низким уровнем загрузки. Ничего удивительного, что предприятия стремятся консолидировать свои серверы.
Возможности самоуправления СУБД Oracle Database 10g помогают максимизировать использование существующих ресурсов, тем самым помогая избежать частых покупок дополнительного оборудования. Например, функция Automatic Shared Memory Management позволяет более оптимально использовать доступную память SGA, а возможность регенерации (reclaim) пространства из существующих таблиц может снять необходимость в покупках дополнительной внешней памяти. Это те преимущества, которые Дессер из Aventis надеется достичь в долгосрочном плане с проектами консолидации. Будучи обязан управлять более 100 базами данных, Дессер говорит: «Мы стремимся к лучшей управляемости. Должно стать легче, если мы консолидируем все наши различные базы данных в несколько стоек."
Келли Вайсет (Kelli Wiseth), директор по технологиям в Alameda Tech Lab and Research Center.
Oracle Database 10g снимает барьер размеров файлов
Постоянно растущие в размерах жесткие диски и поддержка для больших файлов (больше 2 Гигабайт), доступная в 64-битных операционных системах заставляют задуматься: то, что рассматривается как очень большое в этом году, может быть оценено как небольшое через несколько лет. С новой функцией bigfile tablespace “потолок” для ваших сверхбольших баз данных просто поднимается до небес (и теоретически зависит только от операционной системы, что она может поддерживать — 8 exabytes. Это 8 миллионов терабайт, или на три порядка больше текущего лимита в 8 петабайт.
Функция bigfile tablespace упрощает управление базами данных, позволяя вам создавать табличные области в одном файле (single-file tablespace) и выполнять операции на уровне табличной области, а не на уровне лежащего в основе файла базы данных (чтобы поддерживать эту возможность, синтаксис SQL для предложения ALTER TABLESPACE был расширен.)
Создание bigfile tablespace не многим отличается от создания обычных табличных областей (теперь называемых smallfile tablespaces чтобы подчеркнуть разницу между двумя типами); одна разница в том, что размер bigfile tablespace может быть специфицирован не только в килобайтах и мегабайтах, но и в гигабайтах и терабайтах. Вот пример:
CREATE BIGFILE TABLESPACE datahuge /DATA FILE'/u02/oracle/data/ bigtbs01.dbf' SIZE 2T;
Не имеет смысла использовать bigfile tablespaces на системах, которые не поддерживают больших файлов. В этом случае значительно ограничиваются возможности табличных областей.
СУБД Oracle Database 10g может поддерживать оба типа bigfile и smallfile tablespaces одновременно; табличные пространства SYSTEM и SYSAUX продолжают использовать smallfile tablespaces и не могут быть созданы иначе. Bigfile tablespaces поддерживаются только для локально управляемых табличных областей с автоматизированным управлением сегментов пространства (tablespaces with automatic segment-space management).
И наконец, bigfile tablespaces должны использоваться с Automated Storage Management, или другим логическим менеджером томов, который поддерживает динамически расширяемые логические тома, striping и RAID.
Сетевые решения. Статья была опубликована в номере 11 за 2003 год в рубрике software
