Настоящие материалы являются авторскими, права автора защищены Законами РФ и международными соглашениями. Для использования настоящих материалов вам необходимо ознакомиться и полностью принять лицензионное соглашение . В случае, если вы не принимаете настоящее лицензионное соглашение полностью, вы не имеете права пользоваться настоящими материалами

Введение

Опыт автора говорит о высокой планке вхождения в администрирование СУБД Oracle даже для квалифицированного IT специалиста. Познакомившись с СУБД Oracle в 2001 году, автор долго и болезненно шёл к изучению и пониманию этого продукта в дополнение ко всем другим интересам и задачам, и вышел таки на уровень администратора БД, имел опыт практической работы и перевёл несколько книг из документации к СУБД, в частности руководство по тюнингу экземпляра версии 9i. В силу различных причин уровень углубления автора в эту тему не является абсолютным, и автор не считает себя так называемым гуру, но для задуманного цикла статей опыта и понимания будет достаточно. Важно, что в настоящее время профессия Oracle DBA привлекает IT специалистов своей востребованностью и довольно высоким уровнем оплаты. Конечно, это верно только для крупных городов Руси, и рынок этот не массовый, но всё же он есть, и интересен высококвалифицированным и опытным IT специалистам, ищущим новые направления в своей деятельности

Однако интерес интересом, но планка вхождения в профессию довольно высока. Конечно это связано с тем, что для введения интересующегося в круг понятий (проведения инициации) необходимо вложить в него объёмное знание, состоящее из нескольких моделей, наложенных друг на друга. Эффект объёмности является одним из основных в практиках даосизма и вполне себе работает и для мирских и социальных задач. Проще говоря для быстрого вхождения в тему администрирования СУБД Oracle необходимо познакомить интересующегося с определённой подборкой базовых понятий, после чего дальнейшее развитие такого интересующегося будет зависеть только от вложенных им желания, усилий и времени

Настоящий цикл статей не призван предоставить читающему абсолютно полноценную и достоверную документацию по СУБД Oracle, задача в другом - предоставить достаточно адекватную информационную модель для быстрого вхождения в администрирование СУБД Oracle, для общего понимания заложенных в СУБД идей и для выполнения типовых операций, которые обычно являются "первыми целями" - развёртывание движка СУБД, организация резервирования данных и навык восстановления данных (бэкап) и сервиса (стэндбай), начальная аналитика уровня экземпяра в целом и т.п.

В дальнейшем при желании идти вглубину профессии необходимо будет обратиться к обширной документации от производителя, начав с книги "Концепции", и перейдя к материалам, описывающим более детально конкретные аспекты. В любом случае эти материалы составляют не одну сотню страниц, к тому же барьером зачастую является английский язык изложения, поэтому короткие вводные материалы, котрыми является настоящий цикл статей, на взгляд автора могут быть интересны начинающим и раздумывающим - стоит ли заниматься администрированием Oracle, и как бы попробовать "малой кровью". В первую очередь настоящие материалы адресованы UNIX администраторам, перед которыми волею случая возникают те или иные задачи, связанные с администрированием СУБД Oracle. Зачастую такие IT специалисты заинтересованы не в погружении в глубины профессии администратра баз данных, но только в решении ряда типовых задач, что тоже требует некоего базового понимания "как это всё" работает, то есть достаточной для решения таких задач информационной модели

Я рекомендую читать материалы минимум два раза полностью, далее по необходимости, между прочтениями обеспечить себе хотя бы недельную паузу. Первое прочтение делать без каких либо попыток проработать что либо на практике и без желания запомнить всё. Задача первого прочтение - создать "координатно - понятийную сетку" в подсознании. Второе прочтение можно уже совмещать с попытками установить движок БД, создать и попробовать администрировать какие либо тестовые базы. Также нужно понимать, что процесс вникания и "намаливания" практических решений требует времени, которое может исчисляться как минимум несколькими месяцами

Также важно, что настоящие материалы являются авторской интеллектуальной собственностью и защищены Законами РФ и международными соглашениями, и без принятия условий лицензионного соглашения использовать эти материалы запрещено. И ещё - если материалы помогли вам, не постесняйтесь написать автору, ему важна обратная связь. Адрес электронной почты есть в разделе контактные координаты настоящего сайта

Обзор задач

Первое, с чем сталкиваешься при изучении работы СУБД - большое количество отдельных технических решений в составе движка СУБД Oracle. Это объективная необходимость, связанная с особенностями задач - обеспечение одновременной работы большого количества клиентских сессий на одном банке данных, транзакционность (атомарность) обработки запросов, обеспечение отказоустойчивости, целостности и не противоречивости данных, высокая производительность и одновременное оперирование большими объёмами информации

Для хранения и управления данными СУБД Oracle использует многодетальный комплекс технических решений, самостоятельно управляющий использованием аппаратных ресурсов - оперативной памятью, дисковым вводом/выводом, процессорными ресурсами

Также отличительной особенностью является выделение и использование различных буферов в оперативной памяти для резкого снижения нагрузки на дисковый ввод/вывод, и, соответственно, снижения времени отклика и роста производительности. Кроме того, управление данными включает разделение каждого пользовательского запроса на предварительный разбор, оптимизацию с возможным автоматическим переписыванием, кэширование и непосредственную отработку результата с отдачей ответа пользователю. Такой алгоритм позволяет дополнительно снизить затраты на повторный разбор и оптимизацию повторяющихся запросов

Для взаимодействия с клиентами по сети реализован свой механизм SQLNet, требующий установки на клиенте клиентского ПО, решающего ряд задач, например передачу запросов и приём результата, перекодировку в различные национальные кодировки и т.п. Для целей администрирования доступно несколько интерфейсов, базовым из которых является интерфейс командной строки и использование диалекта языка SQL от производителя. Для аналитики в СУБД поддерживается накопление разнообразной статистической информации

Таким образом базовыми понятиями для начального вхождения в тему являются

• архитектура движка СУБД и некоторое углубление в отдельные компоненты архитектуры
• понятия об алгоритмах обработки запросов и оптимизаторе (детальное понимание работы оптимизатора также достижимо, и доступна документация от производителя, но это уже следующий уровень углубления, который будет рассмотрен в отдельной статье)
• особенности проведения базовых работ, в частности установка движка СУБД, создание базы, доступные методы и базовые приёмы администрирования СУБД

Все эти моменты автор планирует раскрыть в настоящей статье, по возможности сократив объём информации для ясности восприятия. Но к многодетальности таки нужно быть готовым. Описание базовых понятий есть в книге "Концепции", доступной среди нескольких десятков книг, поставляемых производителем и доступных для скачивания на сайтах производителя, но книги эти англоязычные. Автору же интересно не только выверить собственную понятийную картину, но и подготовить вводный материал на основе его понимания методов преподавания компьютерных дисциплин - так что статья будет писаться в первую очередь "из головы", но не делаться перевод "концепций". В дальнейшем серьёзному интересующемуся потребуется обращаться к официальной документации, но сейчас наша задача - по возможности быстрое вхождение в тему

Как сказано у одного автора "эх, Каштанка, насекомое ты существо супротив человека, вот как столяр супротив плотника". И добавим - или как ДБА супротив администратора UNIX, для которого администрирование Oracle является задачей администрирования всего лишь ещё одного сервиса в череде десятков прочих. Так путь юниксоиды выбирают свободные СУБД, например PostgreSQL, но и при невозможности такого выбора, например, в силу "политических" моментов, пусть юниксоидов, знающих основные моменты работы с СУБД Oracle, будет больше

Помните, коллеги UNIX администраторы, редкий администратор баз данных (DBA) имеет опыт в администрировании нескольких пригодных для использования операционных систем семейства UNIX, и мало кто из них имеет навыки администрирования различных административных, файловых, инфраструктурных, коммуникационных и т.п сервисов. Поэтому быстрое вхождение в задачи администрирования СУБД Oracle для вас реальность - именно в силу специфической заточки мозгов на восприятие информации и "укладку" нового в уже наработанную вами картину IT мира. А вот обратное - быстрое вхождение коллег DBA в задачи администрирования OC UNIX, если не спользовать ОС только как подстилку для СУБД - дело на мой взгляд мало реальное

Обзор архитектуры движка

Как говорилось выше, СУБД Oracle использует большое количество комплексных технических решений. На серверный узел для начала устанавливается программное обеспечение движка СУБД. Одновременно может быть установлено несколько движков разных версий и редакций (standart edition, enterprice edition). После этого создаются непосредственно базы. Для управления каждой базой предварительно запускается так называемый экземпляр (движка)

Вообще запуск базы на серверном узле проходит через несколько фаз. Сначала на основании файла инициализационных параметров выделяется память и запускаются так называемые фоновые процессы (в терминах операционной системы), обязательными из которых для версии 9i являются только пять. Совокупность выделенной памяти и запущенных фоновых процессов называется экземпляром. Эта фаза носит названия "запуска без монтирования". Экземпляр (движка) обслуживает свою базу данных, представленную файлами или специализированным хранилищем. Одновременно на одном серверном узле может быть запущено несколько экземпляров движка одной или разных версий, обслуживающих каждый свою базу данных

В общем случае база содержит управляющий (контрольный) файл в двоичном формате, файлы оперативных журналов и файлы данных. Сразу после запуска экземпляра монтируется управляющий (контрольный) файл, содержащий, кроме прочего, информацию о расположении файлов оперативных журналов и файлов данных. Это фаза монтирования базы. Следующей фазой является открытие файлов данных и оперативных журналов, и предоставление пользователям доступа к базе. Эта фаза называется открытием базы и является окончательной. Остановка базы производится в обратной последовательности и, в общем случае, должна завершиться корректно до остановки операционной системы

Понимание архитектуры работы СУБД является обязательной основой. Ключевым понятием, от которого можно оттолкнуться, является использование оперативной памяти. На рисунке ниже представлена архитектура работы движка СУБД, и далее мы рассмотрим представленную на рисунке модель детально

После поднятия экземпляра и открытия базы экземпляр готов принимать запросы от пользователей. В наиболее распространённом случае (так называемый режим работы выделенного сервера - dedicated mode) на серверном узле запускается отдельное приложение, входящее в состав движка и называемое прослушиватель (listener), который ожидает запросы от пользователей и для каждой новой пользовательской сессии создаёт так называемый серверный процесс (в терминах операционной системы) на серверном узле, и передаёт ему взаимодействие с пользователем. Таким образом серверный процесс принимает запросы от пользователей, и, совместно с экземпляром движка обеспечивает выполнение таких запросов и отдачу пользователю результатов. По окончании пользователем сессии соответствующий серверный процесс убивается

При этом между экземпляром движка, а именно его фоновыми процессами, и всеми серверными процессами, взаимодействующими с пользователями, существует "разделение труда", которое обеспечивает эффективную работу с данными одновременно для множества пользовательских сессий. Для этого при старте экземпляра выделяется большая область памяти, называемая кэшем буферов (buffer cache). При обращении к данным каждый серверный процесс сначала пытается найти данные в кэше буферов, и, при удаче считывает данные из оперативной памяти (из кэша буферов), не задействуя довольно медленный ввод/вывод с физического хранилища (дисков). Если же данных в кэше буферов нет, то именно серверный процесс, отвечающий за обслуживание конкретной пользовательской сессии, читает требуемые данные из файлов базы данных и помещает их не куда нибудь, а в кэш буферов, после чего использует эти данные для отработки пользовательского запроса. Таким образом процесс чтения одних и тех же данных несколькими сессиями существенно оптимизируется

В случае, когда данные нужно не только прочитать, но и модифицировать, именно серверный процесс модифицирует данные, но не на диске, а только в буферном кэше. Модифицированные блоки памяти помечаются как "грязные" (dirty) и подлежат записи на диск специально выделенным процессом DBWR . Одновременно с модификацией в буферном кэше сохраняются и старые версии данных, подлежащие записи в так называемое пространство отмены (undo) для осуществления возможности получить прежние версии данных (например, прежние значения строки), что востребовано для обеспечения непротиворечивости чтения и при откате транзакций. Данные в пространстве отмены хранятся в соответствии с выделенным для этого пространства места, а само хранение организовано циклически, то есть сначала удаляются наиболее устаревшие данные

Запись грязных буферов на диск осуществляет фоновый процесс, принадлежащий движку и называемый DBWR. Перед тем, как записать данные в файлы данных базы на диск, все изменения заносятся в буфер оперативных журналов, откуда они достаточно часто переносятся в файлы оперативных журналов на диск (redo logs). Запись соответствующих изменений в файлы оперативных журналов до записи соответствующих грязных буферов в файлы данных базы обеспечивается и гарантируется движком СУБД. Запись в оперативные журналы производится выделенным фоновым процессом LGWR последовательно, в порядке проведения модификаций и достаточно часто (каждые три секунды, если заполнено больше 1 мегабайта, при отработке контрольной точки, при заполненности буфера оперативных журналов на треть, перед записью соответствующих данных DBWR, при фиксации транзакции). Это позволяет проводить довольно громоздкую операцию записи процессом DBWR в файлы данных относительно нечасто, и при этом гарантировать возможность восстановления данных в случае сбоя, используя прежние версии файлов данных и данные, сохранёные в оперативных журналах. Таким образом достигается оптимизация процесса одновременной модификации данных множеством сессий - модификации проводятся в оперативной памяти, в кэше буферов, и сбрасываются на диск фоновым процессом экземпляра по мере необходимости

Так как оперативные журналы используются циклически и, обычно, не могут вместить большого объёма журнальной информации за продолжительное время работы, реализован механизм фоновой архивации оперативных журналов. Архивация проводится фоновым процессом ARC. В дальнейшем архивные журналы, будучи наложены на резервную копию базы, позволяют "докатить" базу до состояния на заданное время, и произвести полное или неполное восстановление данных

Важным аспектом для обеспечения такой работы является понятие контрольных точек. Каждая модификация даных в базе имеет свой постоянно возрастающий номер модификации SCN. Понятие контрольная точка обозначает тот последний номер SCN, который гарантированно сохранён в файлах базы данных. Каждые три секунды процесс CKPT записывает в управляющий (контрольный) файл номер SCN, гарантированно сброшенный в файлы оперативных журналов. В то же время при записи процессом DBWR данных в файлы данных в каждом файле данных сохраняется максимальный записанный в файл данных номер SCN. Ситуация, когда в заголовке разных файлов данных присутствует разный SCN, вполне возможна, например, при сбое экземпляра.Поэтому в случае сбоя экземпляра или некорректного завершения работы базы при следующем старте движок будет знать, что, по сравнению с номером SCN из контрольного файла номер SCN отдельных файлов данных отличается, и, значит, нужно провести восстановление, докатив данные из оперативных журналов в файлы данных, и далее откатив изменения по незавершённым транзакциям, используя данные пространства отмены (undo), сохраняемые как часть файлов данных

Таким образом достигается оптимизация использования ввода/вывода и обеспечивается механизм отказоустойчивости и механизм версионности, то есть сохранения какого то количества прежних версий модифицированных данных. К слову сказать это не единственный вариант обеспечения механизма версионности. Если СУБД Oracle сохраняет только изменения для каждого блока данных, то СУБД PostgreSQL сохраняет несколько версий строки для модифицируемой таблицы целиком. Таким образом размер информации отката у СУБД Oracle существенно меньше, что может быть оптимальным для нагруженных баз, однако механизм версионности СУБД PostgreSQL не требует проверки модификации и наложения информации отмены на запрашиваемые блоки, что снижает стоимость получения прежних версий (количество физических чтений, операции проверки модификаций и поиск информации отмены в данном случае не нужны, потому что просто берётся строка, соответствующая затребованной точке времени)

Среди обязательных серверных процессов также присутствуют SMON, обеспечивающий восстановление экземпляра после сбоя (те самые докат журнальной информации в файлы данных при несовпадении SCN и последующий откат не зафиксированных трансакций), а также объединение свободного места в файлах данных (сливание экстентов) и очистку данных во временных сегментах, а также процесс PMON, отвечающий за освобождение ресурсов сбойных процессов (откат транзакций, снятие блокировок и т.п.)

Обзор оптимизатора

Вторым комплексным механизмом оптимизации является оптимизатор запросов и библиотечный кэш. Запросы, приходящие к СУБД, пишутся на языке SQL и допускают различные варианты написания. Не оптимальный текст многократно повторяющихся сложных запросов может резко увеличить нагрузку на сервер СУБД. Примером могут быть многократно вложенные запросы с несколькими внешними соединениями без адекватных уточняющих фильтров на больших таблицах без индексов. Поэтому каждый запрос, пришедший к СУБД, подвергается анализу, при необходимости он переписывается (производится трансформация), после чего генерируется несколько вариантов выполнения запроса - с различными методами доступа к данным (например, полное сканирование таблиц, поиск по подходящему индексу, выборка тоько из индекса), для сложных запросов - с различными методами соединения таблиц (например, соединения вложенным циклом, сортированное слияние, слияние по хэшу) и с различным порядками соединения (какая таблица ведущая, какая ведомая)

Такие варианты отработки запросов носят название "план выполнения запроса", и сопоставляются со статистикой по задействованным объектам - таблицам, индексам, материализованным представлениям, а также со статистикой использования аппаратных ресурсов. По результатам сопоставления вычисляется стоимость каждого плана исполнения, отражающая требуемое для отработки запроса количество аппаратных ресурсов - физических чтений, использования процессорного времени и т.п., и выбирается план с самой низкой стоимостью. Обычно такой план требует самого короткого времени для отработки, но возможно указать оптимизатору, нужно ли максимально быстро получить первую строку/строки или же всю результирующую выборку

Такая обработка каждого входящего запроса производится автоматически, называется полным или жёстким разбором запроса (hard parsing) и требует ресурсов, поэтому после проведения полного разбора запроса данные о таком запросе помещаются в библиотечный кэш, выделенный в оперативной памяти, и повторные запросы по возможности используют результаты разбора из библиотечного кэша. Этим достигается как цель оптимизации метода выполнения самого запроса, так и оптимизация ресурсов, затрачиваемых на повторный разбор запросов

Администратору БД требуется сконфигурировать размеры буферов, выделяемых в оперативной памяти, таким образом, чтобы их хватало для работы под нагрузкой именно вверенных экземпляров СУБД. В первую очередь речь идёт именно о кэше буферов с данными базы и о библиотечном кэше. Такое конфигурирование производится на основании предоставляемой экземпляром статистики, в том числе информации о событиях ожидания - но это тема отдельной статьи, для начального вхождения достаточно знать, что такая статистика собирается экземпляром самостоятельно. А вот статистика объектов базы, как и статистика использования аппаратных ресурсов, должны периодически собираться администратором БД, чтобы оптимизатор мог использовать актуальные данные статистик и выбирать адекватные планы исполнения, хотя и это - тема отдельной статьи по тюнингу экземпляра

Обзор методов администрирования

Когда основы архитектуры работы движка становятся примерно понятны, возникает следующий вопрос. Как администрируется движок? Основным способом является использование языка SQL, расширенного корпорацией Oracle в сторону команд, управляющих экземпляром и базой данных. Так что для управления, начиная от запуска экземпляра и до его остановки, используется обычная клиентская SQL сессия. Точно так же, как в MySQL или PostgreSQL существуют утилиты интерактивного доступа к базе (например для PostgreSQL это утилита psql), у СУБД Oracle существует утилита sqlplus, запускаемая из командной строки операционной системы, и позволяющая стартовать или потушить базу, а также отправлять SQL запросы и получать от СУБД ответы. Запросы же могут как обрабатывать данные, так и управлять объектами базы, создавая/удаляя/модифицируя их, или же выполнять административные задачи

СУБД Oracle предоставляет разнообразнейшую информацию от перечня объектов, созданных в базе и их свойств, до данных по системной, объектной статистике, статистике работы экземпляра и событиях ожидания, а также о текущей работе экземпляра, в частности сессиях, разобранных запросах, транзакциях и детальном статусе использования отдельных компонентов движка. Например пулов и буферов, выделенных в памяти, файлах данных, оперативных и архивных журналах, пространствах отмены (UNDO) и т.п.

Все такие данные представлены как таблицы или представления, к которым можно обращаться через обычные запросы выборки "select ...". Не все такие данные являются фактическими таблицами, многие из них просто маскируются движком под таблицы, являясь отражением структур, размещаемых движком в памяти на время работы экземпляра. Однако механизм получения доступа для администратора БД не меняется - все данные доступны администратору как таблицы и представления. Имена таких таблиц и представлений известны и детально расписаны в документации, поставляемой корпорацией Oracle, включая поля таблиц и их описание. Нюансом здесь является тот момент, что каждый объект базы данных, будь то таблица, хранимая процедура, правило целостности и т.д. имеет своего владельца. Все обьекты одного владельца называются "схемой". Вот удобное правило, помогающее понять, схема Oracle соответствует пользователю в операционной системе, роль Oracle соответствует группе в операционной системе

При создании каждой новой базы в базе создаётся так называемый словарь - хранилище метаданных, а также несколько системных пользователей и соответствующих им объектов данных. В частности все основные объекты, предоставляющие описанную выше информацию для администратора БД имеют владельцем пользователя SYS, или же, иначе, расположены в схеме SYS

Существует множество надстроек над базовым методом администрирования. Официальные надстройки от корпорации Oracle называются Oracle Enterprise Manager, Oracle Management Server, а упрощённым вариантом является DB Console. Однако такие надстройки не позволяют глубоко разобраться в деталях функционирования и администрирования движка и всегда более ограничены. чем базовый интерфейс через SQL запросы, однако могут быть интересны тем, что предоставляют наглядную и агрегированную информацию в виде графиков

Начальная сложность

Итак, начальная сложность вхождения в тему в том, чтобы понять архитектуру работы движка. Базовых сущностей довольно много и взаимосвязи между ними запоминаются не сразу. К сожалению от многодетальности здесь никуда не уйти. Перечислим эти базовые сущности ещё:

• Понятие структуры памяти, выделяемой экземпляру - SGA (system global area) , в том числе
  • кеш буферов (buffer cache, буферный кеш), в которрый читаются данные из файлов и в котором данные модифицируются
  • буфер оперативных журналов
  • библиотечный кеш (фактически SQL area), хранящий планы разборов запросов и наряду с резервным пулом, а также кешем словаря входящий в т.н. разделяемый пул
  • другие структуры памяти, например пул Java
• Понятие структуры памяти, выделенные серверным процессам - PGA (processes global area) , отвечающим за обслуживание процессов клиентских. Хранят результаты запросов, а также могут использоваться для сортировок при упорядочивании, опреациях соединения (нескольких таблиц в запросе) и т.п.
• Понятие оперативные журналы (redo logs) , в которые заносятся все модификации, выполненные в базе, и использующиеся для восстановления данных. Обычно создаётся несколько групп оперативных журналов, состящих из одного или нескольких файлов. Запись журнальной информации ведётся параллельно во всё файлы группы для обеспечения отказоустойчивости, а при восстановлении автоматически берутся доступные экземпляры файла журнала (в версии 9i приходилось напарываться на некорректность этого утверждения). Запись журнальной информации ведётся последовательно в каждую группу, и по исчерпании места продолжается с первой группы, то есть циклически
• Понятие архивные журналы (archive logs) , сохраняющие конкретные версии оперативных журналов, и необходимые потому, что размер оперативных журналов ограничен. Режим, при котором данные оперативных журналов сохраняются в архивных журналах, не является для БД обязательным и должен включаться или выключаться отдельно. Однако такой режим обязателен для создания бэкапа БД без остановки сервиса и для "продакшен" баз является фактическим стандартом
• Понятие пространства отмены (UNDO, более раннее - сегменты отката) - это выделенная в БД область (сегменты или целое табличное пространство специального типа), сохраняющая все прежние значения при проведении транзакций в базе данных. Количество сохраняемых прежних значений зависит от размера пространства отмены и интенсивности модификаций в базе, причём при исчерпании места в UNDO и невозможности автоматического расширения первыми удаляются наиболее старые данные о прежних значениях данных в завершённых транзакциях. Эта область используется для отката данных в отменённых транзакциях, восстановления после сбоев и получения старых значений данных для обеспечения мультиверсионности и непротиворечивости чтения
• Понятие физических и логических структур хранения данных . Каждый файл данных базы приписывается к какому либо табличному пространтву с уникальным именем, и размечаются на блоки фиксированной длины. Существует несколько предопределённых размеров блоков и размер по умолчанию 8 КБайт. Для каждого задействованного размера блоков, а он может быть разным для разных табличных пространств, обязательно выделение соответствующего такому размеру пространства в памяти SGA, а именно в кеше буферов. Данные таких объектов, как индексы и таблицы, располагаются в выделяемых в табличном пространстве сегментах данных, причём объекту обычно выделяется персональный сегмент. Сегмент фактически является списком непрерывных групп блоков, называемых экстентами

  Таким образом данные фактически хранятся в группах блоков (экстентах) файлов даных, такие группы соотнесены с сегментом данных для каждого объекта. Экстенты одного сегмента могут располагаться непоследовательно - сказывается специфика БД, а также могут размещаться в разных файлах одного табличного пространства. Файлы данных имеют заголовок, который среди прочего, хранит SCN, отражающий последние реально зафиксированные процессом DBWR в файле данные. Также важно, что выделяют постоянные табличные пространства, в которых хранятся данные и временные, используемые для создания временных таблиц и дисковых сортировок и соединений, когда последние не могут быть проведены в памяти

• Понятие экземпляра , описывающее запущенные фоновые процессы (это в терминологии Oracle, в терминологии ОС это настоящие серверные процессы, наравне с теми, что обслуживают клиентские запросы) и выделенные структуры памяти и понятие базы данных , описывающее файлы данных, контрольные файлы и файлы оперативных журналов. Контрольные файлы являются двоичными во внутреннем формате Oracle, содержат, кроме прочего. информацию о каждом файле данных, в том числе его место положения и максимальный заведомо сохранённый номер SCN (согласно технологии неполной контролькой точки), и могут быть пересозданны администратором при условии знания последним файлов даных базы с принадлежностью к табличным пространствам и оперативных журналов
• Понятие SCN - номер системной модификации , монотонно возрастающий для каждой модификации в базе. Понятие контрольной точки , которая бывает полная, когда соотнесённый с контрольной точкой SCN отражает реально записанные в файлы данных грязные буфера, и неполной, когда SCN из контрольного файла отражает максимально записанные в оперативные журналы данные. Во втором случае сохранность данных при сбоях экземпляра также гарантируется на момент контролькой точки, но могут потребоваться операции автоматического восстановления процессом SMON при старте после сбоя
• Понятие полного и мягкого разборов запросов , а также алгоритма работы оптимизатора
• Понятие модели разграничения прав - любой объект базы имеет владельцем какого либо пользователя, иначе говорят, что объект находится в схеме с именем этого пользователя. Существуют типовые права - привелегии, которые бывают системными, объектными и колоночными (на отдельные колонки какого либо объекта). Привелегии выдаются пользователю либо непосредственно, либо присваиваются именованой группе (называемой также ролью), а уже роль выдаётся пользователю

Также для начала необходимо понимание типовых процедур, проводимых администратором, а именно:

• Установка движка БД, создание БД и предоставление доступа к ней, обновление движка и базы - обзор вынесен в
• Методы холодного и горячего резервного копирования и снятия дампов данных - обзор вынесен в
• Методы организации отказоустойчивых решений - организация холодного и тёплого стэндбаев - обзор вынесен в
• Методы контроля деятельности и оптимизации работы экземпляра
• Методы оптимизации отдельных запросов. Хотя эта задача больше соответствует разработчику, администратор БД должени иметь общее представление о возможностях оптимизации запросов, хотя бы для того, чтобы выявить нетиповую нагрузку и аргументированно предложить разработчикам оптимизировать прикладную часть
• Продвинутые и зачастую дорогостоящие методы организации отказоустойчивых решений - организация кластера Oracle RAC

Такой практический багаж, будучи наработан с той или иной степенью углубления, уже позволяет говорить о начальном вхождении в профессию. Насколько глубоко стоит идти дальше - личное дело каждого. Автор статей выводит понимание всех этих тем, подтверждённое практическим опытом, на уровень формализации и объяснения себе своими словами - в первую очередь для того, чтобы освободить память для более достойного содержимого. И, как показывает практика - а именно несколько обученных с нуля администраторов UNIX, объяснение "от автора" воспринимается коллегами проще, чем сухая документация от производителя, хочется верить, что алгоритмы мышления и чувствования потенциальных ораклоидов отличаются слабо, в выбранная манера подачи материала и уровень углубления будут кому то полезны. Впрочем, это ещё и шпаргалка по отдельным темам для самого автора и его знакомых, так что принцип формирования многоосевого объёма в статьях соблюден. В настоящем цикле статей планируется рассмотреть большую часть отмеченных здесь задач

Обзор установки СУБД и создания БД

Эта часть вынесена в отдельную статью цикла. Обзор установки движка СУБД, создания базы и получения административного доступа вынесен в . Также в отдельные статьи планируется выносить обзоры по одельным административным задачам. Кроме того на сайте автора доступен FAQ по решению отдельных небольших административных задач, а также ряд статей автора по Oracle, не входящих в цикл "Oracle - это просто"

Обзор лицензионной политики

Лицензионная политика корпорации Oracle является темой множества обсуждений, но она такова, какова есть. Ниже в разделе автор приводит базовую информацию по особенностям лицензирования Oracle. Напоминаю, что, как и всё на сайте, не гарантируется достоверность, точность и пригодность этой информации для каких либо целей. Автор рекомендует обращаться за официальной информацией к официальным источникам

Также важно, что в свете принятия 4 части ГК РФ и ст. 146 части 2 УК РФ нелицензионная установка СУБД Oracle, учитывая стоимость лицензий, может сразу подпадать под крупный или особо крупный размер ущерба правообладателю, за который предусмотренна отсидка. Важно, что непосредственным исполнителем преступления, то есть установки нелицензионной копии, является обычно администратор, какие бы басни не пело руководство организации. Когда дойдёт до крайней точки, суд будет прислушиваться не к басням, а к фактам. Фактом является действие - установка не лицензионного программного обеспечения, и есть лицо, эти действия совершившее. Обычно это администратор. А пойдёт ли руководство соучастниками - большой вопрос, который можно рассматривать ещё и как отягчающее - преступление, совершённое группой по предварительному сговору. Так что в настоящее время у администратора, не желающего отсидки, два пути - либо добиваться лицензирования организацией программного обеспечения (ПО), или же немедленно "стучать", чтобы не оказаться крайним. Неприятная, однако, ситуация

Для СУБД корпорация предоставляет несколько релизов (версий), внутри которых выделяется несколько редакций (edition). Выделяют Enterprise edition (EE), Standart edition (SE), Standart edition one (SE One). Ставятся все редакции с одного дистрибутива, причём EE является наиболее полной, а SE - подмножеством EE. Кроме редакций существует понятие опций, то есть дополнительного функционала, такого, как кластер RAC, партицирование, ADDM(AWR) и т.п. Использование опций стоит отдельных лицензионных отчислений

Лицензирование непосредственно СУБД производится либо по сокетам, либо по количеству пользователей. Причём редакции имеют ограничения - SE One может использовать не более двух сокетов, но она и дешевле. Опции распределяются тоже довольно причудливо - например для SE построение кластера Oracle RAC будет бесплатным, а для EE за него придётся заплатить

Таким образом для лицензирования СУБД необходимо определиться, какая редакция вам требуется, какие дополнительные опции вам требуются, как вам выгоднее лицензироваться - по сокетам сервера или же по пользователям. Нюансом здесь является то, что лицензирование по пользователям подразумевает всех пользователей, заведённых в базе, а не тех, которые реально обращаются к ней

Ещё одним важным моментом является оплата технической поддержки. Насколько помню, она составляет около 25% от стоимости лицензий всех СУБД, приобретённых организацией, в год. Важно, что при возобновлении контракта на техническую поддержку после перерыва от вас потребуют оплаты техподдержки всех СУБД за период перерыва. Важно, что техподдержку вы сможете приобрести только на все свои лицензии скопом, но не на одну базу. Ну, в этом есть логика, но это совсем не дёшево. Однако я могу ошибаться, и эти моменты лучше уточнить из официальных источников

Для чего нужна техническая поддержка? После заключения контракта вы получаете доступ на сайт технической поддержки Oracle https://metalink.oracle.com, или Металинк. На сайте доступно множество материалов по возникавшим проблемам и методам их решения. Также на сайте доступны обновления для релизов СУБД. И, хотя зачастую используется только базовый функционал СУБД, информационная поддержка может оказаться очень нужной. Также на сайте можно задавать вопросы сотрудникам службы технической поддержки Oracle (к сожалению, только на нерусском английском языке), и получать консультации

Обзор других продуктов корпорации Oracle

СУБД является не единственным продуктом корпорации Oracle, ею представлены как системные продукты (например, Oracle HTTO server, Oracle Identity Management, Oracle Application Server), так и прикладные решения типа OEBS, Siebel и т.п. Автор имеет право на своё мнение, и мнение автора здесь таково - возможно для сверхбольших организаций, построенных по бездушному иудохристианскому (европейскому) принципу, эти продукты и оптимальны. Однако существуют свободные альтернативы, использование которых с учётом и сиюминутных интересов в виде лицензирования, и с учётом долговременной перспективы предпочтительнее. Проявленная корпорацией Oracle манера приобретения чужих продуктов не способствует уважению, проявляемому к разработчику, а не перекупщику. Тот же Oracle HTTP сервер - это прекрасно известный свободный HTTP сервер Apache с дополнительными модулями авторизации и увязки с хранимыми процедурами БД, а в основе LDAP каталога используется (по крайней мере в версии 9i) не менее широко известный свободный сервер OpenLDAP от компании PADL

В этом, конечно, нет криминала. Но последующий уход от типовых и привычных администраторам типовых решений, которые можно применять и вне "экосистемы Oracle", например замена своего сервера приложений на основе широко известного Apache приобретённым на стороне продуктом WebLogic, говорит о желании привязать пользователя к своим продуктам. Или, как минимум, сделать подбор альтернатив более сложным. Конечно, корпорация Oracle имеет право на выбор позиции, но и пользователь имеет право выбирать - использовать или нет её продукты, которые, я допускаю, пытаются манипулировать вашим выбором при наличии альтернатив. Альтернативой Application Server, например, является, например, связка Tomcat и Apache. И так далее - к результату всегда можно придти разными дорогами, и дорога корпорации Oracle более не представляется автору заманчивой

Кстати относительно недавно корпорация преподнесла очередной сюрприз - если ранее для установки СУБД Oracle можно было официально использовать несколько различных дистрибутивов Linux, то сейчас фактически остался только дистрибутив Linux от самой корпорации Oracle, потому что осталось только одно рекомендованное ядро. Всё бы ничего, если бы именно они вложили свой труд в создание этого дистрибутива с нуля. Но, насколько я помню, вся эпопея с дистрибутивом Linux от Oracle началась с предложения корпорации предоставлять техническую поддержку для дистрибутива RedHat за деньги меньшие, чем поддержка этого же дистрибутива самим производителем - компанией RedHat, вложившей в свой дистрибутив огромное количество труда и заслуживающей подлинного уважения сообщества Open Source. Конечно я могу ошибаться, и с тех времён корпорация Oracle могла сделать полностью свой, независимый дистрибутив, не основывающийся на наработках честного трудяги Red Hat. Что же, кому интересно - пусть задаст этот вопрос Ораклу

С учётом приобретённой ранее компании SUN Microsystems, являющейся владельцем патентов на процессоры SPARC и операционной системы SUN Solaris, и фактически похороненной далее разработкой Open Solaris (энтузиастами сделан форк, но врядли он жизнеспособен), а также созданием отдельной организации и массовым, если верить новостям, переходом в неё разработчиков офисного пакета Open Office, доставшегося корпорации по наследству (также сделан форк, правильный офисный пакет теперь называется LibreOffice и сопровождается основанием организации наподобие Mozilla Foundation, так что перспективы вполне радужные) на взгляд автора можно и нужно говорить о предпочтительности свободных альтернатив

• относительно эпопеи с OpenSolaris, который фактически умертвили - вот , вот , вот
• относительно хамского, на взгляд автора, поступка по отношению к PostgreSQL - вот

Кстати, применительно непосредственно к СУБД также существуют альтернативы, например свободный PostgreSQL приближен по функционалу к Oracle Database Standart Edition, а в чём то, на взгляд автора, и превосходит его, например поддержкой процедурных языков, известных администраторам - Perl, Python и т.д. И эти альтернативы по возможности нужно развивать и использовать - приоритетно. А если для зарабатывания на жизнь вам потребуется временно, до победы свободных или уж честно и самостоятельно созданных коммерческих продуктов, администрировать СУБД Oracle - настоящий цикл статей призван вам помочь

Свои выводы каждый делает сам. Мнение автора таково - программное обеспечение СУБД Oracle как базовые технологии настолько же хорошо, качественно и удобно для обеспечения управления большими базами с позиции администратора, насколько не удобны другие продукты. И, опять же на взгляд автора, лицензионная политика, проявляемое корпорацией отношение к проектам сообщества и тенденция перехода от базирующихся на свободных продуктах решений к "чёрным ящикам" обуславливает необходимость быстрого поиска альтернатив и переход на них там, где это возможно, и, по возможности это должны быть либо решения от национального производителя, дабы развивать отрасль внутри страны, либо же открытые программные решения, такие, как PostgreSQL

Белонин С.С. (С), сентябрь 2010 года

(даты последующих модификаций не фиксируются)

Нравится

30 сентября 2019 года (Москва) 2 декабря 2019 года (Москва)

Стоимость:

27 675 руб.

Курс дает базовые знания, требуемые для планирования, эксплуатации и настройки СУБД Oracle и баз данных на платформах класса Windows и Unix.

Знания даются для версий Oracle 8i, 9i, 10g, 11g и 12с. Курс сопровождается практическими упражнениями, позволяющими закрепить понимание главных понятий и освоить основные технические приемы администрирования БД.

По окончании курса слушатели получают представление о возможностях и подводных камнях администрирования Oracle. Они учатся самостоятельного выполнять основные задачи администрирования и обходить встречающиеся в разных версиях Oracle ошибки.

Основное отличие этого курса от ряда других со схожей тематикой состоит в следующем: целью ставится научить конкретных слушателей реальной работе с Oracle на оригинальном материале, а не отчитать программу, подготовленную третьей стороной.

Курс предназначен для администраторов баз данных, а так же разработчиков информационных систем на базе Oracle. Слушатели должны обладать хорошим уровнем компьютерной грамотности.

Программа курса "Администрирование баз данных Oracle"

1. Общая информация о СУБД Oracle

• Введение в Oracle
• Версии и разновидности Oracle
• Расширения базовой поставки
• Общая архитектура Oracle
• Основные элементы архитектуры
• Разновидности рабочих конфигураций
• Задачи администрирования БД
• Ресурсы знаний

2. Установка Oracle

• Местонахождение Oracle в операционной и файловой системе
• Рекомендуемая структура каталогов для Oracle
• Общая схема установки Oracle
• Основные этапы установки
• Установка ПО Oracle
• Формирование характеристик БД и СУБД
• Заведение инфраструктуры для размещения планируемой БД
• Порождение сценария заведения БД
• Номинальное создание БД: предложение CREATE DATABASE
• Заведение словаря-справочника для БД
• Создание дополнительных элементов и структур БД
• Указание свойств местности для БД и работающих с ней программ
• Выбор кодировки БД и приложения
• Выбор языка сообщений, форматов выдачи и прочего
• Где выполняются установки свойств местности, и где наблюдаются
• Замена и правка свойств существующих языковых установок БД и создание новых
• Запуск и останов СУБД и БД
• Службы ОС в Windows
• Запуск и останов СУБД и БД вручную
• Действия по убиранию Oracle с компьютера
• Убирание БД из компьютера
• Убирание программных компонент с помощью Oracle Universal Installer
• «Чистое» убирание Oracle

3. Использование SQL*Plus в администрировании

• Вызов SQL*Plus
• Наиболее популярные установки параметров и режимов SQL*Plus
• Наиболее популярные команды SQL*Plus
• Файлы glogin.sql и login.sql
• Использование SQL*Plus для форматированной выдачи
• Совместное использование команд SPOOL, SAVE и START

4. Средства слежения за работой Oracle

• Использование базовых и виртуальных таблиц
• Статические таблицы
• Динамические таблицы
• Сценарии на SQL и PL/SQL, поставляемые Oracle
• utlbstat.sql и utlestat.sql (все версии)
• STATSPACK (версия 8.1.6 и выше)
• AWR (версия 10 и выше)

• Активное отслеживание событий (версия 10 и выше)
• Прочие полезные сценарии на SQL и PL/SQL
• Примеры запросов для слежения за использованием ресурсов БД и СУБД
• Специальные программные продукты
• Oracle Enterprise Manager
• Собственные возможности наблюдения OEM

5. Конфигурирование, настройка и поддержка

• Процессы конфигурирования и настройки
• Объекты конфигурирования
• Объекты настройки
• Конфигурирование и настройка операционной среды
• Конфигурирование и настройка Windows
• Конфигурирование и настройка Unix/Linux
• Конфигурирование составных частей БД и СУБД Oracle
• Конфигурирование контрольного файла
• Конфигурирование сегментов отката/сегментов отмены
• Конфигурирование табличных пространств
• Конфигурирование табличных пространств для временных данных
• Конфигурирование файлов табличного пространства
• Конфигурирование журнальных файлов
• Конфигурирование хранимых объектов БД
• Конфигурирование таблиц
• Конфигурирование индексов
• Некоторые специальные случаи конфигурирования хранения и использования таблиц и индексов

6. Администрирование доступа в Oracle

• Политика безопасности
• Основные средства администрирования доступа
• Пользователи и схемы
• Привилегии
• Опосредованный доступ к данным в таблицах
• Ограничение доступа к отдельным частям таблицы
• Защита сведений в БД внешними средствами
• Шифрование данных
• «Шифрование» исходных текстов программных элементов в БД
• Подключение к СУБД
• Пример внешней (EXTERNAL) аутентификации в ОС Windows
• Профили пользователей
• Ограничения расходования ресурсов СУБД
• Контроль за использованием паролей
• Включение контроля ресурсов
• Динамическое регулирование выделяемых сеансам ресурсов СУБД и БД
• Рекомендации Oracle для администраторов

7. Аудит

• Виды действий для отслеживания системным аудитом Oracle
• Общее разрешение на сбор СУБД информации о действиях пользователей
• Примеры конкретной выдачи заданий на аудит
• Таблицы с протоколом аудита
• Пример рекомендаций по осуществлению политики аудита
• Примеры оформления рутинных действий с таблицей аудита
• Создание таблицы для сбора обобщенной ежедневной статистики
• Сбор обобщенной ежедневной статистики
• Чистка журнала аудита
• Выборочный аудит доступа к таблицам
• Аудит с помощью триггерных процедур
• Отслеживание изменений отдельных строк таблиц
• Отслеживание изменений строк с точностью до столбцов
• Отслеживание прочих действий
• Отслеживание истории изменений в БД по журналу

8. Администрирование работы в сети

• Общая архитектура сетевой поддержки в Oracle
• Дополнительные возможности и средства SQL*Net/Net8/Oracle Net
• Конфигурирование Oracle Net для среды клиент/сервер
• Конфигурируемые компоненты SQL*Net/Net8/Oracle Net
• Способы адресации нужной БД
• Конфигурирование с помощью Net Manager
• Конфигурирование вручную
• Наладка и контроль соединения по Oracle Net
• Использование программы lsnrctl
• Проверка соединения по Oracle Net
• Настройка соединений по Oracle Net

9. Экземпляр СУБД Oracle

• Составные части экземпляра СУБД
• Процессы СУБД
• Стандартные фоновые процессы
• Дополнительные фоновые процессы
• Серверные процессы
• Просмотр имеющихся в составе СУБД процессов
• Структуры данных в составе экземпляра СУБД
• Область SGA
• Область PGA
• Область UGA
• Схемы выполнения некоторых внутренних процедур
• Выполнение контрольной точки
• Журнализация изменений в БД
• Состояния базы данных в Oracle

10. Настройка экземпляра СУБД Oracle

• Ручная настройка (для всех версий)
• Методики настройки
• Настройка SGA
• Настройка областей PGA
• Настройка в версии 9
• Настройка SGA
• Настройка областей PGA
• Настройка в версиях 10+
• Настройка SGA
• Настройка PGA
• Экспертные советы СУБД по выбору новых значений
• Автоматический сбор статистики и авторегулирование
• Аппарат «советников»
• Настройка в версии 11
• Настройка SGA и PGA
• Настройка выполнения контрольных точек
• Настройка журнализации
• Настройка СУБД и БД
• Решения на уровне приложения

11. Организация хранения данных в Oracle

• Хранение объектов БД на диске
• Внутренняя организация хранения данных в табличных пространствах
• Управление памятью в табличных пространствах для нужд сегментов
• Управление памятью в сегментах для нужд размещаемых данных
• Управление памятью в блоках с данными

12. Настройки операций ввода/вывода

• Ручная настройка для всех версий
• Выбор варианта RAID
• Автонастройка и управление в версиях 10+

13. Резервное копирование и восстановление

• Виды резервного копирования
• Физическое резервирование
• Логическое резервирование
• Резервирование изменений (частичное)
• Холодное/горячее резервирование
• Режим ARCHIVELOG работы БД
• Основные сценарии физического резервирования
• Холодное резервирование
• Пример автоматизации
• Включение режима архивирования
• Горячее резервирование
• Резервирование журнальных файлов
• Основные сценарии восстановления на физическом уровне
• Восстановление по полной холодной копии
• Общая схема восстановления с использованием архивных копий журналов
• Восстановление всей БД
• Восстановление данных табличного пространства
• Пробное восстановление
• Режим автовосстановления
• Физическое копирование и восстановление с помощью RMAN
• Пример копирования и восстановления базы данных
• Другие примеры

14. Дополнительные базовые программные средства для администрирования

• exp и imp
• Общие принципы работы программ exp и imp
• Некоторые типовые сценарии
• Некоторые параметры настройки
• Полный экспорт и экспорт изменений
• Таблицы словаря-справочника для записи информации об экспорте
• Дополнительные достоинства экспорта/импорта
• expdp и impdp
• SQL*Loader
• Загрузка данных в фиксированном формате

В конце обучения на курсе проводится итоговая аттестация в виде теста или на основании оценок за практические работы, выполненных в процессе обучения.

В современном мире сложно обойтись без информационных технологий и их производных - компьютеров, мобильных телефонов, интернета и т.д., особенно в крупных компаниях и государственных организациях, работающих с большим количеством людей, а не только с парой VIP-клиентов, как это может быть в случае небольшой компании. А там, где есть большое количество контрагентов, заявителей и т.д. - не обойтись без баз данных, необходимых для обработки информации. Естественно, что времена гроссбухов и карточек, памятных многим по библиотекам, давно прошли, сегодня используются персональные компьютеры и электронные базы данных.

Сегодня невозможно представить работу крупнейших компаний, банков или государственных организаций без использования баз данных и средств Business Intelligence . Базы данных позволяют нам хранить и получать доступ к большим объемам информации, а система управления базами данных (СУБД) - осуществлять менеджмент доступных хранилищ информации.

В Учебном центре « Интерфейс» Вы научитесь эффективно использовать системы управления базами данных: быстро находить нужную информацию, ориентироваться в схеме базы данных, создавать запросы, осуществлять разработку и создание баз данных.

Обучение позволит Вам не только получить знания и навыки, но и подтвердить их, сдав соответствующие экзамены на статус сертифицированного специалиста. Опытные специалисты по СУБД Microsoft SQL Server или Oracle могут быть заинтересованы в изучении систем бизнес-аналитики. Это задачи достаточно сложные, использующие громоздкий математический аппарат, но они позволяют не только анализировать происходящие процессы, но и делать прогнозы на будущее, что востребовано крупными компаниями. Именно поэтому специалисты по бизнес-аналитике востребованы на рынке, а уровень оплаты их труда весьма и весьма достойный, хотя и квалифицированным специалистам по базам данных, администраторам и разработчикам, жаловаться на низкий уровень дохода тоже не приходится. Приходите к нам на курсы и получайте востребованную и высокооплачиваемую профессию. Мы ждем Вас!

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

Государственный комитет Российской федерации

По высшему образованию.

ГОСУДАРСТВЕННЫЙ САНКТ-ПЕТЕРБУРГСКИЙ

ИНСТИТУТ ТОЧНОЙ МЕХАНИКИ И ОПТИКИ

(ТЕХНИЧЕСКИЙ УНИВЕРСИТЕТ)

кафедра вычислительной техники

Администрирование баз данных

ORACLE
Санкт-Петербург

2000 год

1. Обязанности администратора базы данных (АБД) 3

2. Подключение в режиме INTERNAL 3

3. Утилиты АБД (Import, Export, Loader) 4

4. Пользователи базы данных и схемы 6

5. Табличные пространства и файлы данных 8

6.Схемы и объекты схемы 9

7. Блоки данных, экстенты и сегменты. 11

8.Структуры памяти и процессы 12

9. Пример работы Oracle. 13

10. Журнал Повторений 14

11. Транзакция (Transaction) 15

12. Обеспечение защиты базы данных 18

13. Представления словаря данных. 19

14. Привилегии (Grant, role). 20

15. Управление пользователями

16. Аудит базы данных 22

17. Обеспечение целостности базы данных 24

18. Создание базы данных. (файлы параметров) 25

19. Запуск и останов базы данных 26

20. Различные режимы работы базы данных 29

21. Резервное копирование базы данных 29

22. Динамический SQL 30

23. Объектно-ориентированные Базы Данных. 32

1. Обязанности администратора базы данных (АБД)

Поскольку система баз данных ORACLE может быть весьма большой и может иметь много пользователей, должно существовать лицо или группа лиц, управляющих этой системой. Такое лицо называется администратором базы данных (АБД).
В любой базе данных должен быть хотя бы один человек, выполняющий административные обязанности; если база данных большая, эти обязанности могут быть распределены между несколькими администраторами.

В обязанности администратора могут входить:

• 
  инсталляция и обновление версий сервера ORACLE и прикладных инструментов
• 
  распределение дисковой памяти и планирование будущих требований системы к памяти
• 
  создание первичных структур памяти в базе данных (табличных пространств) по мере проектирования приложений разработчиками приложений
• 
  создание первичных объектов (таблиц, представлений, индексов) по мере проектирования приложений разработчиками
• 
  модификация структуры базы данных в соответствии с потребностями приложений
• 
  зачисление пользователей и поддержание защиты системы
• 
  соблюдение лицензионного соглашения ORACLE
• 
  управление и отслеживание доступа пользователей к базе данных
• 
  отслеживание и оптимизация производительности базы данных
• 
  планирование резервного копирования и восстановления
• 
  поддержание архивных данных на устройствах хранения информации
• 
  осуществление резервного копирования и восстановления
• 
  обращение в корпорацию Oracle за техническим сопровождением

Сотрудники службы безопасности

В некоторых случаях база данных должна также иметь одного или нескольких сотрудников службы безопасности. СОТРУДНИК СЛУЖБЫ БЕЗОПАСНОСТИ главным образом отвечает за регистрацию новых пользователей, управление и отслеживание доступа пользователей к базе данных, и защиту базы данных.

Разработчики приложений

В обязанности разработчика приложений входит:
 проектирование и разработка приложений базы данных

 проектирование структуры базы данных в соответствии с требованиями приложений

 оценка требований памяти для приложения

 формулирование модификаций структуры базы данных для приложения

 передача вышеупомянутой информации администратору базы данных

 настройка приложения в процессе его разработки

 установка мер по защите приложения в процессе его разработки

2. Подключение в режиме INTERNAL

Запуск и останов базы данных - это мощные административные возможности. В угоду поддержания корректной работоспособности базы данных, функции(команды STARTUP или SHUTDOWN ) остановки и запуска разрешены, только для администратора подключенного к ORACLE в режиме NTERNAL(^ CONNECT INTERNAL ), а для возможности подключиться в режиме NTERNAL, вы должны соотвествовать одному из ниже следующих условий:

• 
  Ваше учетное имя в операционной системе имеет привилегии операционной системы, позволяющие вам соединяться в режиме INTERNAL.
• 
  Вы имеете полномочия соединяться в режиме INTERNAL.
• 
  Ваша база данных имеет пароль для INTERNAL, и вы знаете этот пароль.

Все эти требования образуют дополнительный слой защиты, препятствующий несанкционированному запуску или остановке баз данных ORACLE. Для систем, имеющих пароль для INTERNAL, существуют дополнительные, ниже описываемые соображения.

Использование пароля для INTERNAL

Некоторые операционные системы позволяют устанавливать пароль для соединений в режиме INTERNAL. Можно установить пароль для INTERNAL во время инсталляции сервера ORACLE, Oracle предоставляет утилиту для управления этим паролем (создания, изменения и удаления его).

INTERNAL и незащищенные соединения

Если используется незащищенное соединение(как большинство сетевых соединений), то ДОЛЖНО использовать пароль для INTERNAL, для последующего подключения в режиме INTERNAL; это требование подразумевает, что в системе должен быть установлен пароль для INTERNAL.
В некоторых О.С. можно либо включить, либо полностью отключить возможность соединений CONNECT INTERNAL для незащищенных соединений. Выбор делается во время инсталляции ORACLE, и может быть изменен позднее.

3. Утилиты АБД (Import, Export, Loader)

SQL*Loader

Одной из многих проблем, с которыми часто сталкиваются администраторы базы данных, является перемещение данных из внешних источников в базу данных Oracle. Сложность этой задачи возрастает с появлением хранилищ данных, приходится перемещать уже не мегабайты данных, а гигабайты, а в некоторых случаях – терабайты. Oracle предусматривает для решения этой задачи SQL*Loader – универсальное инструментальное средство, которое загружает внешние данные в таблицы базы данных Oracle. Утилита SQL*Loader является гибкой и настраиваемой до такой степени, что часто удается обойтись без процедур на языке третьего поколения с внедренными операторами SQL. Каждый раз, сталкиваясь с задачей преобразования инородных данных в формат Oracle, вначале рассмотрите возможность применения SQL*Loader, прежде чем обращаться к другим средствам.

Основные компоненты SQL*Loader

Для утилиты SQL*Loader необходимы входные данные 2-ух типов: внешние данные, которые могут находиться на диске или ленте, и управляющая информация (содержащаяся в управляющем файле), которая описывает характеристики входных данных. Выходные данные, часть которых является необязательной, включает таблицы Oracle, журналы, файлы некорректных записей и файлы отвергнутых записей.

Входные данные

Утилита SQL*Loader может обрабатывать файлы данных практически любого типа и поддерживает собственные типы данных почти любой платформы. Данные обычно считываются из одного или нескольких файлов данных, однако они могут быть также внесены в управляющий файл после управляющей информации. Файл данных может находиться:

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

Год выпуска: 2003

Издательство: Фолио

Формат:DJVU

К нига по священа СУБД Oracle - одной из самых популярных платформ, предназначенных для работы с базами данных. Рассматриваются общие вопросы технологии Oracle , структура баз данных и основные принципы управления файлами базы данных, их размерами, политика защиты баз данных, использование структурированного языка запросов SQL (создание простых и вложенных запросов, добавление и изменение информации в базах данных, создание и модификация основных объектов реляционных систем), язык программирования PL / SQL . Используемые практические примеры ориентированы на версию СУБД - Oracle 9 i

Введение

Часть I. ТЕОРИЯ БАЗ ДАННЫХ

Глава 1.1. Введение в базы данных

Что такое база данных

Структура базы данных

Глава 1.2. Реляционная модель базы данных

Домены и отношения

Целостность данных

Реляционная алгебра

Реляционное исчисление

Глава 1.3. Проектирование логической структуры базы данных

Концепция функциональной зависимости

Нормализация базы данных

Объектное моделирование

Глава 1.4. Функции защиты базы данных

Транзакции и параллелизм

Безопасность и целостность баз данных

Глава 1.5. Дополнительные аспекты реляционной технологии

Повышение производительности с помощью оптимизации

Домены, отношения и типы данных

Неопределенные значения и трехзначная логика

Распределенные базы данных

Часть II . ИНСТАЛЛЯЦИЯ ORACLE 9i

Глава 2.1. Oracle 9i - новые возможности

Oracle 9i - общие сведения

Новшества Oracle 9i Database

Новые возможности в SQL Oracle

Java и XML

Преимущества новых опций СУБД Oracle

Cache Fusion

Возможности восстановления

Возможности, основанные на усовершенствованной архитектуре

Другие возможности Oracle 9i

Глава 2.2. Требования по инсталляции

Компоненты Oracle_Home

Основные соглашения системы компонентов

Индивидуальные требования к компонентам

Требования к обновлению базы данных

Oracle Universal Installer - общее представление

Инсталляция продуктов Oracle 9 i

Выбор типа базы данных

Настройка сети

Конфигурация сервера в сети

Общее представление о пользователях и паролях

Глобальное имя базы данных и ее идентификатор

Табличные пространства

Часть III . ЭКЗЕМПЛЯР ORACLE

Глава 3 .1. Архитектура экземпляров Oracle

Экземпляр Oracle

Структура экземпляра

Фоновые процессы Oracle

Анатомия транзакции

Мониторинг экземпляра

Глава 3.2. Настройка СУБД Oracle

Необходимость выполнения настройки

Параметры настройки и ее этапы

Часть IV . ИНСТРУМЕНТАЛЬНЫЕ СРЕДСТВА ORACLE

Глава 4.1. Работа с SQL * PIus

Настройка программы SQL * Plus

Запуск SQL * Plus и некоторые соглашения

Команды SQL * Plus

Операция редактирования в SQL * Plus

Запуск команд SQL на выполнение

Блокировка команд SQL

Команды администратора БД

Команда EXECUTE

Управление выводом информации

План выполнения EXPLAIN PLAN

Глава 4.2. Импорт и экспорт

Назначение и возможности импорта и экспорта

Экспорт данных

Импорт данных

Глава 4.3. Oracle Enterprise Manager

Общие сведения и архитектура

Подключение Standalone

Подключение к Management Server

Приложения Management Packs и приложения управления базой данных

Планирование заданий

Часть V . ЯЗЫК СТРУКТУРИРОВАННЫХ ЗАПРОСОВ SQL

Глава 5.1. Выборка данных

Оператор SELECT

Базовый синтаксис оператора SELECT

Операторы сравнения

Диапазоны

Списки (IN и NOT IN)

Проверка значений на определенность

Поиск по шаблону

Дополнительные возможности оператора SELECT

Использование выражений

Использование специальных псевдостолбцов

Использование псевдонимов столбцов и таблиц

Выбор уникальных значений

Соединение в запросе нескольких таблиц

Использование подзапросов

Глава 5.2. Функции Oracle

Функции преобразования

Календарные функции

Числовые функции Oracle

Символьные функции Oracle

Универсальные функции Oracle

Аналитические SQL -вычисления в Oracle 9 i

Механизмы агрегирования

Глава 5.3. Сложные запросы Oracle

Древовидные (иерархические) запросы

Внешнее соединение

Слияние результатов нескольких запросов

Глава 5.4. Создание таблиц

Использование оператора CREATE TABLE

Использование оператора ALTER TABLE

Переименование и удаление таблицы

Глава 5.5. Изменение данных таблицы

Транзакции

Вставка данных

Копирование данных из другой таблицы

Изменение данных

Удаление данных

Использование функций в операторах изменения данных

Блокирование строк

Скоростное удаление данных

Изменение данных и привилегий

Индексы и ограничения

Триггеры базы данных

Глава 5.6. Другие объекты базы данных

Индексы

Особенности работы с индексами

Использование кластеров

Преимущества и недостатки кластеров

Последовательности

Представления

Синонимы

Часть VI . ЯЗЫК ПРОГРАММИРОВАНИЯ PL / SQL

Глава 6.1. Программы и модули

Процедуры и функции

Модули

Синтаксические конструкции

Глава 6.2. Использование подпрограмм и модулей

Общие сведения

Локальные подпрограммы

Хранимые и локальные подпрограммы

Хранимые подпрограммы и модули

Состояние модулей на этапе выполнения

Хранимые подпрограммы и привилегии.

Глава 6.3. Триггеры базы данных

Типы триггеров

Создание триггеров

Специфика использования триггеров

Изменяющиеся таблицы

Глава 6.4. Динамический SQL

SQL в PL / SQL

Использование DBMS . SQL

Использование внутреннего SQL

Дополнительные особенности

Глава 6.5. Взаимодействие между соединениями

Модуль DBMS_PIPE

Модуль DBMS _ ALERT

Сравнение модулей DBMS _ PIPE и DBMS _ ALERT

Глава 6.6. Объектные свойства

Объектные типы

Объекты в базе данных

Сборные конструкции

Часть VII . ОСНОВЫ АДМИНИСТРИРОВАНИЯ БАЗ ДАННЫХ

Глава 7.1. Окружение Oracle

Рабочая среда Oracle

Настройка рабочей среды Oracle

Глава 7.2. Администрирование баз данных

Обязанности АБД

Обязанности других пользователей базы данных

Учетное имя АБД в операционной системе

Подключение пользователя DBA

Учетные имена АБД

Планирование базы данных

Глава 7.3. Создание базы данных

Этапы создания БД

Создание экземпляра

Создание файла параметров инициализации

Создание базы данных

Создание объектов поддержки БД

Последние этапы создания БД

Запуск базы данных

Процедура остановки базы данных

Снятие сессий

Часть VIII . КОНФИГУРИРОВАНИЕ СЕРВЕРА ORACLE

Глава 8.1. Управление контрольными файлами

Общие сведения

Создание нового управляющего файла

Операции с контрольными файлами

Глава 8.2. Управление онлайновым журналом

Общие сведения

Создание групп онлайнового журнала

Создание членов онлайнового журнала

Переименование и перемещение членов онлайнового журнала

Удаление групп онлайнового журнала

Удаление членов онлайнового журнала

Глава 8.3. Управление контрольными точками и переключением журнала

Общие сведения

Установка интервалов контрольных точек БД

Форсирование переключения журнала

Форсирование быстрой контрольной точки без переключения журнала

Получение информации о журнале повторения

Часть IX . НАСТРОЙКА ПАРАМЕТРОВ ПАМЯТИ БАЗЫ ДАННЫХ

Глава 9.1. Управление размером и файлами базы данных

Политика управления табличными пространствами и файлами данных

Сегментирование табличных пространств

Создание табличных пространств и файлов данных

Добавление файлов данных к табличному пространству

Установка параметров памяти для табличных пространств

Переименование и перемещение файлов данных

Удаление табличных пространств и файлов данных

Глава 9.2. Управление объектами схемы

Управление использованием памяти блоками данных

Установка параметров памяти

Управление таблицами

Работа с представлениями

Управление последовательностями

Использование синонимов

Применение индексов

Работа с кластерами

Управление хеш-кластерами и их таблицами

Переименование объектов схемы

Очистка таблиц и кластеров

Работа с триггерами

Управление ограничениями целостности

Ручная перекомпиляция объектов

Глава 9.3. Управление сегментами отката

Общие сведения

Принцип работы сегмента отката

Множественные сегменты отката

Установка размера сегмента отката

Установка параметра OPTIMAL

Создание сегментов отката

Удаление сегмента отката

Глава 9.4. Фрагментация базы данных

Фрагментация табличного пространства

Фрагментация объектов

Глава 9.5. Анализ таблиц, индексов и кластеров

Общие сведения о возможностях анализа

Управление сбором статистики

Часть X . ЗАЩИТА БАЗЫ ДАННЫХ И АУДИТ

Глава 10.1. Установление политики защиты БД

Политика защиты данных

Управление пользователями базы данных

Идентификация пользователей

Политика защиты пользователей

Глава 10.2. Управление пользователями

Идентификация пользователей

Создание пользователей

Изменение пользователей

Удаление пользователей

Глава 10.3. Управление ресурсами через профили

Общие сведения

Создание профилей

Использование умалчиваемого профиля

Назначение профилей

Изменение профилей

Использование составных ограничений

Удаление профилей

Включение и выключение ресурсных ограничений

Получение информации о пользователях и профилях

Глава 1 0.4. Управление привилегиями и ролями

Системные привилегии

Объектные привилегии

Создание ролей

Удаление ролей

Назначение системных привилегий и ролей

Назначение объектных привилегий

Отзыв системных привилегий и ролей

Отзыв объектных привилегий

Каскадные эффекты отзыва привилегий

Получение информации о привилегиях и ролях

Глава 10.5. Аудит базы данных

Общие сведения

Включение и выключение опций аудита

Команда AUDIT

Выключение опций аудита

Контролирование роста и размера аудиторского журнала

Очистка аудиторских записей из аудиторского журнала

Защита аудиторского журнала

Обработка информации аудиторского журнала

Аудит с помощью триггеров базы данных

Аудит с помощью инструментальных средств Oracle

Часть XI . РАСПРЕДЕЛЕННЫЕ БАЗЫ ДАННЫХ

Глава 11. 1 Распределенные СУБД

Общие сведения о распределенных базах данных

Распределенные транзакции

Принудительное управление транзакцией

Глобальное имя базы данных

Использование связей

Обеспечение прозрачности местоположения

Глава 11.2. Управление материализованными представлениями (снимками)

Общие сведения о репликации с помощью материализованных представлений

Группы репликации

Виды материализованных представлений

Создание материализованного представления

Внутренняя реализация снимка

Установление параметров памяти

Обновление материализованных представлений

Обновляемые группы

Удаление материализованных представлений

Журналы материализованных представлений

Часть XII КОПИРОВАНИЕ И ВОССТАНОВЛЕНИЕ БД

Глава 12.1. Архивирование информации повторения

Выбор режимов архивирования

Установка режима архивирования

Глава 12.2. Стратегия резервного копирования

Физическая и логическая потеря данных

Подготовка к резервному копированию

Стратегия копирования базы, работающей в режиме ARCHIVELOG

Полное копирование базы данных («холодное» копирование)

Частичное копирование базы данных («горячее» копирование)

Копирование управляющего файла

Экспорт/импорт (логическое копирование)

Глава 12.3. Восстановление базы данных

Подготовка к восстановлению

Восстановление файлов данных

Реставрация архивных файлов журнала

Восстановление с «холодной» копии

Восстановление БД работающей в режиме ARCHIVELOG

Применение файлов журнала повторения

Потеря файлов оперативного журнала повторения

Потеря архивных файлов журнала повторения

Потеря управляющих файлов

Восстановление после ошибок пользователя

Глава 12.4. Использование RMAN

Что такое RMAN

Архитектура RMAN

Интерфейс RMAN

Работа RMAN