Сегодня присяжные вынесли вердикт, по которому Google не нарушал патентов Oracle. Это важная победа сил добра, но главное решение еще впереди. Однако давайте вернемся чуть-чуть назад.

Судья William Alsup (тот самый, который умеет программировать на Java) разбил вынесение решения на 3 фазы. На первой фазе присяжные решали нарушил ли Google в своем Андроиде копирайт Oracle на 37 различных API, используемых в Java или на некоторое количество строк кода (включая ставшую широко известной функцию rangeCheck). На второй фазе рассматривались претензии Oracle по поводу патентов. На третьей фазе (в зависимости от решения на предыдущих этапах) определялась сумма ущерба, нанесенная истцу.

Итак, тяжба по патентам завершена — суд вынес вердикт по делу Google и Oracle, в котором поставлена точка по вопросу о нарушении патентов Oracle при разработке ОС Android. Таким образом, претензии Oracle на $1 млрд. + отчисления не удовлетворены.
После оглашения решения акции Google поползли вверх.
Текст решения

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

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

В одном из моих прошлых постов была такая фраза: «Oracle, занимающая четвёртое место в списке крупнейших поставщиков, потеряла в доходах (4Q11) относительно прошлого года 11.5% и занимает 5.2% от рынка». Я подумал, что нужно подробнее на этом остановиться.

Согласно отчётам о доходах Oracle за третий квартал, прибыль направлений программного обеспечения и услуг выросли, а бизнес аппаратного обеспечения и комплексных систем снизился на 16% и 4%, соответственно. На фоне этих цифр аналитики говорят, что не уверены в хороших перспективах расселеров аппаратного обеспечения Oracle.

Все прогрессивное человечество с замиранием сердца следит за процессом Oracle против Google. Уже очень скоро присяжные вынесут вердикт по делу. Под катом перевод статьи Andrew Binstock, главного редактора сайта www.drdobbs.com о том, что будет, если выиграет Oracle.

Многие знают, что назревающий возможный скандал между крупными игроками IT-рынка Google и Oracle, подспудной причиной которого стала популярная платформа Android, вылился в суд между корпорациями, который начался в понедельник 16 апреля. Суть претензий Oracle заключается в том, что компания, купив в 2009 году Sun Microsystems, приобрела авторские права на язык программирования Java и теперь интернет-гигант незаконно использует технологии Java в Android, нарушая, таким образом, патенты Oracle.

Не вдаваясь в подробности, собственно юридических вопросов патентного права, кажется любопытным проследить логику адвокатов Oracle в намерении доказать, что Google отнюдь не начинала с чистого листа в Android, а исходный код системы, как минимум, содержит прямые вставки непосредственно из исходного кода Java. Всего, если отметить ради интереса, Oracle обвиняет Google в копировании 103 400 строк Java-кода (подробное описание иска можно посмотреть в этом pdf-документе)

Итак, после первичного заявления адвокатов Oracle о сознательном отказе от патентных отчислений в пользу законного владельца технологий, рассмотрение вопроса стало более конкретным. В суд был приглашен Джошуа Блох, работающий в данный момент в Google и должность которого в корпорации обозначена как Chief Java Architect at Google (при этом не лишним будет отметить то обстоятельство, что Блох восемь лет проработал в Sun, перед тем как перейти на работу в интернет-гиганте).

Доброго времени суток всем.Работаю администратором баз данных далеко не первый год, но всегда работал в больших компаниях. За это время работал с 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 все труднее убедить клиентов переплачивать за своё ПО.

Не так давно мне нужно было быстро поднять маленькую виртуалку под 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) и не будут позволять зафиксировать транзакцию, если вдруг целостность данных оказалась нарушенной. В рамках же модифицирующей транзакции ограничения могут нарушаться. С одной стороны это упрощает модификацию данных, с другой, мешает идентифицировать источник ошибки. В этой статье я хотел бы привести пару простых примеров реализации таких ограничений.

Введение

В этой небольшой статье я хочу рассказать о том, как я настраивал отправку почты из 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


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