Доброго времени суток всем.Работаю администратором баз данных далеко не первый год, но всегда работал в больших компаниях. За это время работал с Linux, Solaris, HP-UX. Но примерно год назад попал в небольшую компанию, и о ужас, все сервера на Windows, как такового резервного копирования не делалось, точнее только экспорт.

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

Для мониторинга использования индексов Oracle предлагает простой способ — включить мониторинг индекса и выключитьпо завершению значимого для данного индекса периода. Описание на сайте Oracle тут. В результате в представлении V$OBJECT_USAGE вы можете увидеть ответ “Yes” или “No”.

Но что делать если:
— Вы уже знаете что индекс используется,
— популяция запросов уже настолько велика что проанализировать их на предмет использования запросами не представляется возможным
— Вам нужны доп. сведения о выполнении запросов

Совсем недавно на работе стало необходимым контролировать рост размера базы данных Oracle. Связано это было с тем, что места осталось не так много, что -то около 100 Гб, а в двух компаниях (компании крупные, страховые) базы стремительно растут.

Для начала мы создадим таблицу DB_TABLESPACE_SIZE, в которой будем хранить данные о каждом дне.

В конце декабря компания Oracle сообщила о падении своих акций на 9%. Но мне эта новость не показалась удивительной, потому что всего за пару дней до её появления я беседовал с Эдом Бояджаном (Ed Boyajian), президентом и CEO компании EnterpriseDB.

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

Некоторое время назад потребовалось сделать бэкап базы данных на RAC. Задача, на самом деле, вполне тривиальная, если бы не несколько но: у заказчика паранойя по поводу безопасности (не удивительно и понятно), у заказчика нет своего DBA (ну так уж вышло) и у меня есть доступ только к консоли сервера с базой данных. Таким образом, пришлось отказаться от использования красивого и удобного Enterprise Manager и придумать банальные консольные скрипты. И вот тут-то и возникла загвоздка.

Стандартное решение: написать скрипты бэкапа, настроить cron, который будет их вызывать по расписанию, и на этом успокоиться до тех пор, пока база таки не упадёт. Но поскольку мы имеем дело с кластером из нескольких нод, встал вопрос, на которой из них дёргать бэкап. На всех — как-то многовато. На одной — а что, если именно она-то и упадёт, а все остальные останутся в строю? По очереди — а что, если упадёт именно та, чья очередь делать бэкап как раз и наступила? На каком-нибудь третьем сервере — нету лишней железки для дополнительной базы данных.

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

Понятно, что изобретённое решение — это нецелевое использование любопытной фичи. Но получилось забавно.

Не так давно мне нужно было быстро поднять маленькую виртуалку под Linux, чтобы проверить переносимость одного модуля в своем приложении, написанного на Java и вызывающего Oracle SQL Loader через java.lang.Process API.

Поскольку, как известно, Oracle SQL Loader не входит в поставку Oracle Instant Client, то для такой задачи надо или копировать руками нужные библиотеки с машины, где установлен сервер, либо ставить на этой виртуалке полный сервер Oracle.

Установка Oracle Enterprise Edition под Ubuntu это задача не на 5 минут. Полная и точная (по словам автора — я сам пробовал многочисленные похожие инструкции, все равно полностью без ошибок поставить ни разу не удавалось) инструкция находится здесь — www.excession.org.uk/blog/installing-oracle-on-ubuntu-karmic-64-bit.html. Сравните, насколько это геморройнее и сложнее, чем установка того же Oracle EE под Windows — там запустил OUI (Oracle Universal Installer) и следуешь его указанием. Короче, отличный пример протекающей абстракции в Linux среде (хотя, казалось бы, user-friendly дистрибутив) в духе Джоэля Спольски.

Но для Express (XE) версии есть все же человеческое решение.

Контроль целостности данных — одна из важнейших функций СУБД. Чем тщательнее этот контроль организован, тем проще реализовывать прикладную логику, ведь чем больше ограничений контролируется базой данных, тем меньше вариаций «а что, если» следует предусмотреть при реализации логики. В то же самое время контроль целостности оказывается достаточно удобно использовать и для проверки корректности работы прикладного слоя. Что-то вроде юнит-тестов. «Лишняя» проверка, порой может сослужить очень добрую службу.

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

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

Довольно часто случается такая неприятность, что в alert.log базы одно за другим сыпятся сообщения типа «Checkpoint not complete». Стандартный совет в этом случае: «увеличьте количество и/или размер redo логов». А дальше вопрос, кто такие эти redo логи и с чем их едят.

Введение

В этой небольшой статье я хочу рассказать о том, как я настраивал отправку почты из Oracle и чем это закончилось. Хочу сразу уточнить две вещи: во-первых, делал я это не для рассылки спама, во-вторых, ранее я не имел дела с настройкой почтовых серверов, поскольку это лежит вне области моей профессиональной деятельности.

Казалось бы, зачем вообще может возникнуть необходимость разбирать XML на стороне БД?

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

В этой статье я хотел бы продемонстрировать на сколько легко и непринужденно можно разобрать XML различной степени сложности используя инструментальные средства Oracle Database.

Введение

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

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

Первая часть статьи, посвященная особенностям оператора order by, функционированию not in и примеру неявного преобразования типов, находится здесь.

Введение

Примерно полтора года назад я сдал экзамены на OCP Advanced PL/SQL Developer, далее специфика работы несколько изменилась, и после стандартного производственного использования Oracle я занимался разработкой архитектуры двухуровневой клиент-серверной системы на основе Oracle для нужд компьютерной лингвистики. Далее был этап развития системы и решения наукоемких задач на ее основе, пришлось заниматься использованием иерархических запросов в решении нестандартных задач и другими специфическими вещами. Результатом углубления в специфику стало некоторое «проседание» базы, а значит, наступило время снова просмотреть материалы, использовавшиеся для подготовки к экзаменам.

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

Всем привет!
Долго думал, что бы написать полезного про Оракл, перепробовал кучу тем. Каждый раз получалось слишком длинно, потому что уносило глубоко в дебри. Поэтому решил начать с максимально простой темы, чтобы оценить интерес аудитории и её отношение к моему стилю изложения материала (имхо, писатель из меня не очень). Несколько замечаний:

• заметка относится к СУБД Oracle, но большинство написанного касается и других СУБД;
• не получилось симпатично оформть код: тег source lang=«sql» подсвечивает слишком мало, как сделать по другому не в курсе. Если кто покажет, быстро всё приведу в более читабельный вид.

Итак.

Основные положения

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

Основная особенность NULLа заключается в том, что он не равен ничему, даже другому NULLу. С ним нельзя сравнить какое-либо значение с помощью любых операторов: =, <, >, like… Даже выражение NULL != NULL не будет истинным, ведь нельзя однозначно сравнить одну неизвестность с другой. Кстати, ложным это выражение тоже не будет, потому что при вычислении условий Oracle не ограничивается состояниями ИСТИНА и ЛОЖЬ. Из-за наличия элемента неопределённости в виде NULLа существует ещё одно состояние — НЕИЗВЕСТНО.

Каждый из нас сталкивался с необходимостью интеграции разных систем. Я хотел бы рассказать о том, как предоставить возможность отобразить данные из базы Lotus Domino оператором SQL select в Oracle Database. Возможно, эта тема не будет интересна многим. Но, на мой взгляд, эти два коммерческих продукта заслуживают того, чтобы написать о возможностях, которые они предоставляют.

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

SELECT Data, COUNT(*)
FROM tbl
WHERE Data BETWEEN SYSDATE-7 AND SYSDATE
GROUP BY Data
ORDER BY Data


За неделю ожидаем получить пять строчек — по одной на каждый рабочий день. Все работает. До тех пор, пока пользователи совершают хоть одно действие в день. Если же в таблице не окажется ни одной строки с датой, то и в результате этой даты не будет. И вместо ожидаемых пяти строк в отчете будет четыре… или три… или вообще ни одной. А пользователи хотят видеть пять, пусть и с нулями!

Думаю, многим разработчикам ПО и предпринимателям буду интересны некоторые особенности лицензионной политики и технической поддержки компании Oracle.

Начать разработку своих приложений на Oracle очень просто, и денег за это Oracle не возьмет. Интересное начнётся потом, когда проект надо будет легализовать.

Я решил написать цикл небольших заметок благодаря посту Хорошие привычки в PL/SQL, советы которого и рассмотрю.

В этой части обсудим:

1. Нюансы %TYPE/%ROWTYPE
2. Select for update
3. Работа с коллекциями

Предлагаю Вашему вниманию перевод интересного на мой взгляд поста про неочевидную особенность Oracle.

Далее будет говориться об Oracle Database 11g, о тех привычках что мы выработали со временем.