Oracle database плюсы и минусы: В чем преимущества СУБД Oracle перед MySQL, PosgreSQL? — Хабр Q&A

В чем преимущество Oracle перед другими СУБД? — Хабр Q&A

На ваш вопрос невозможно корректно ответить. Каждая СУБД обладает своими архитектурными особенностями и по сути является платформой, т.е. многие полезные вещи уже реализованы. Т.е. можно сравнивать две конкретные СУБД и рамках решения конкретной задачи. Как СУБД для ИС уровня предприятия, Oracle очень хороший выбор, т.к. обычно в таких системах нагрузка 50 на 50(50 запись\50 чтение). И в силу архитектурных особенностей Oracle(реализация транзакций и блокировок) справляется с такой эксплуатацией на ура. Плюс БД еще надо администрировать, заботиться о сохранности данных после сбоя(бэкапирование), туча функций и объектов для реализации бизнес-логики …. короче много всего что нужно делать, и это уже реализовано в Oracle. И как бонус, Oracle более лоялен к рукожопости разработчиков, которые считают, что все БД одинаково работают и устроены. Если данных много и надо быстро их обрабатывать, можно посмотреть в сторону Exadata. Более подробно об особенностях можно почитать в документации. А во всем остальном нужно смотреть под конкретную задачу. Самый большой минус- это стоимость.
З.Ы.: И от себя лично добавлю, на заре карьеры я работал с MS SQL и возненавидел эту СУБД, как раз из-за реализаций транзакций и блокировок, и помогли мне в этом прежние разработчики. В MS SQL блокировки на уровне строк, но реализованы в общем пуле- общий пулл блокировок- это минус скорость(общий пулл надо блокировать, для записи или чтения этих блокировок) и плюс память. И чтобы не загружать особо сервер, прежние разрабы реализовали логику так, что процесс проходил мелкими транзакциями, конечно с коммитами. И были такие прецеденты, что данные удалились, а в другую таблицу не встали из-за ошибки в приложении. Потом дедлоки, это вообще отдельная тема, и приходилось разруливать изменением структуры данных, чтобы пользователи работали, только со своими данными. Короче вспоминаю, как страшный сон. Зато при разработке другой ИС где было решение взять Oracle как СУБД, через призму прошлого опыта, для меня было большое открытие, что там не будет такого гемороя, как с MS SQL. Конечно, может быть MS SQL сейчас сильно изменился в лучшую сторону, но осадочек у меня остался.

Oracle vs PostgreSQL. Почему выбор Oracle может быть разумным решением / Хабр

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

Цель статьи зародить зерно сомнения в душе читателя, который пытается сделать выбор между реляционными БД которые работают в режиме версионника. Почему именно режиме версионника? Здесь выбор не большой, а в блокировщиках есть достойные соперники и выбор еще сложнее.( Чего только стоит бесплатная версия DB2 для небольших БД).

Я не являюсь экспертом БД Oracle хотя и проработал с этой БД много лет и не только с ней. Все что я умею — использовать ее преимущества и добиться оптимального быстродействия. Я тем более не являюсь экспертом PostgreSQL (я не разу не использовал его в продакшене).

Читая статьи об успешной миграции — я понимаю что этим компаниям и не нужен был Oracle или БД была выбрана изначально не верно. Они использовали только малую долю возможностей этой БД. Только поэтому они могли принять решение об миграции, и его осуществить. Просто если использовать всю мощь этой БД — у вас никогда не возникнет желания мигрировать ибо это сродни написать ваше приложение почти с нуля.

Давайте, наконец, поговорим о тех преимуществах для быстродействия, которые дает Oracle и на основании этой информации Вы найдете ответ для себя сами.

1. Partition(8i). Partition — дает возможность роста объема данных практически без влияния на общее быстродействие. Приятный и немаловажный бонус — партицирование индексов. У PostgreSQL партиции появятся только в 10 версии. До этого наследование (INHERITS) — грязный хак. Да и возможности партицирования в Oracle возрастают с каждой версией.
2. Merge(8i). Да да, тот самый Merge который есть уже в MSSQL много лет(2008) и которого не будет даже в PostgreSQL 11. Он дает прирост в быстродействии в десятки раз по сравнению с одиночными операциями. Да я знаю что PostgreSQL поддерживает подзапросы и можно все реализовать через Insert select и хитрый update. Но это далеко не тоже самое.
3. RESULT_CACHE (Select) (11g). У Oracle эта технология появилась относительно недавно. Если использовать эту технологию с умом — дает выигрыш в некоторых вещах в десятки и сотни раз. Главное научиться “умно” ее использовать.
4. Опция INMEMORY (12с) Нет аналога у PostgreSQL. Реальный прирост на некоторых запросах сотни раз.
5. Оптимизатор + тюнинг запросов. Начиная с 11g превратился чуть ли не в клик next->next в EM. PostgreSQL с этим посложнее да и отсутствие в целом аналога EM достаточно некомфортно.

   PL/SQL. Да я знаю про многообразие языков в PostgreSQL. Но Oracle постоянно улучшает язык с прицелом на быстродействие.

Ну и как говорится, дьявол кроется в деталях, а у Oracle эти детали проработаны намного лучше. Oracle не перестаёт удивлять с каждой версией. И не важно на какую БД вы пересядете после Oracle — у Вас всегда останется ощущение: Ну блин, в Oracle это уже давно есть, или в Oracle это сделано лучше.

Я почти уверен что при одинаковом железе и использовании всех возможностей PostgreSQL и Oracle можно получить лучшее быстродействие, при меньших усилиях на ORACLE.

P.S. Ни в коем случае не рассматривайте эту статью как пиар БД Oracle.

Я хорошо понимаю, что обязательно есть вещи которые в PostgreSQL сделаны лучше. Но в целом Oracle в этом сегменте БД №1.

Я специально не затрагивал вещи связанные с администрированием. Просто представьте что вы можете перенести дата файл с диска на диск или восстановить «битый блок» в состоянии Online. И можете осуществить переход на новые сервера без остановки работы БД. И это не новые фичи. У Oracle там все намного лучше, да и я не являюсь админом БД.

Раньше, где то до 10 версии, админ был нужен практически всегда. Сейчас потребность в админе сильно упала, правда и квалификация админа сейчас нужна повыше. Возможно, в версии эдак 15, понятие “admin” БД уйдет в прошлое 🙂

Да и Pl/SQL продуманнее других, хотя конечно это и не C# :). Правда, это сугубо индивидуально.

Ну и я не затрагивал вещи, которые слабо помогают в быстродействии.

P.S.S. И да, я навряд ли я вспомнил все возможности. Только те которые были на “поверхности” Так что дописывайте в комментах. Я включу в upd.

PostgreSQL vs Oracle / Хабр

Сравнение с точки зрения разработчика

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

C Oracle у меня старые и тесные взаимоотношения. Видел много отличных архитектур и кода, и много ужасных «залеп». Oracle предоставляет разработчику неисчерпаемую бездну возможностей, и практически всегда находится нужная именно сейчас «фишка».

В целом, Oracle — удивительный инструмент, и я не устаю удивляться тому, как всё это богатство может работать в принципе и работать стабильно.

Около двух лет назад я перешёл из Enterprise мира в свободное плавание, где махина Oracle с её $47k за ядро — вне досягаемости.

Одним из первых freelance проектов был небольшой биллинг для суб-оператора спутниковой связи. Встал вопрос выбора РСУБД. MySQL сразу отпал по причине недоразвитости процедурного языка, выбор пал на PostgreSQL.

По мере работы над этим и следующими проектами я составлял список субъективных плюсов и минусов PostgreSQL по сравнению с Oracle с точки зрения разработчика БД. Его и представляю вашему вниманию:

PostgreSQL vs Oracle

PRO:

• Псевдо тип serial — объединяет лучшие черты auto_increment из MySQL и sequence из Oracle.
• Можно писать функции на чистом SQL. Например функция, состоящая из одного update c returning, возвращающая идентификатор только что добавленного значения. Позволяет избавится от явного объявления переменных, в которые выбираются данные и которые затем возвращаются в return.
• Замечательный with в котором можно в качестве запроса использовать не только select, но и insert, update, delete returning и который можно делать рекурсивным (заменяет оракловский connect by). Кроме того заменяет собой оракловский мультитабличный insert all.
• Generate_series вместо извращений типа select level from dual connect by level < n
• Очень мощный механизм контроля целостности данных aka CONSTRAINTS — например EXCLUDE позволяет делать хитрые проверки ДРУГИХ строк при вставке новой (иначе пришлось бы писать триггер), REFERENCES (foreign key) c действиями при удалении или изменении записей, на которые ссылается таблица. Например constraint constname references tablename on delete cascade удалит связанные записи при удалении родительской.
• Замечательная, но потенциально опасная (как триггеры) система правил (RULES) позволяющая подменять текст запроса отправляемый серверу. Через неё, например, реализованы VIEW.
• Удобный раздел WHERE в определении индекса, позволяет уменьшить размер индекса не прибегая к созданию функциональных индексов и нечитабельных условий типа where decode(status,1,1,null)=1
• LIMIT с OFFSET, позволяющие избежать геморроя с rownum, сортировкой и подзапросами.
• Приятная документация, лишённая сухости и монструозности (но и дотошности) оракловской.

CONS:

Заключение

Хорошим дополнением этому списку было бы сравнение с точки зрения DBA, но тут, как говорится, я не вполне копенгаген. Было бы очень интересно в будущем увидеть такое сравнение на Хабре.

Выводы? PostgreSQL есть куда расти, но уже сейчас при разработке проектов не сверхбольших масштабов он выглядит очень достойно рядом с чего уж таить — эталоном рынка РСУБД.

Безумие и успех кода Oracle Database / Хабр

На этой неделе пользователи Hacker News решили обсудить вопрос «Каков максимальный объем плохого — но при этом работающего — кода вам доводилось видеть?» (позже к ним присоединились и пользователи Reddit). В комментариях было рассказано немало «веселых» историй про то, с чем мы все время от времени сталкиваемся; но больше всего внимания привлек рассказ про код «передовой СУБД, которую используют большинство компаний, входящих в список Fortune 100».

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

За прошедшие годы над кодом успело потрудиться несколько поколений программистов, которых регулярно преследовали жесткие дедлайны — и благодаря этому код смог превратиться в настоящий кошмар. Сегодня он состоит из сложных «кусков» кода, отвечающих за логику, управление памятью, переключение контекстов и многое другое; они связаны друг с другом при помощи тысяч различных флагов. Весь код связан между собой загадочным макросом, который невозможно расшифровать, не прибегая к помощи тетради, в которую приходится записывать, чем занимаются релевантные части макроса. В итоге, у разработчика может уйти день или два только на то, чтобы разобраться, чем же в действительности занимается макрос.

Для того, чтобы предсказать поведение кода в том или ином случае, приходится разбираться и запоминать, какие значения и последствия могут иметь 20 (а то и сотня) флагов. Ситуацию ухудшает тот факт, что различные разработчики использовали свои собственные типы, которые по своей сути представляли собой одно и то же (например, int32) — и едва ли кто-то рискнет тронуть подобное легаси (можно точно сказать, что это имело место быть в кодовой базе Oracle 8i).

Возникает вопрос: каким же образом при всем этом Oracle Database до сих пор удается держаться на ногах? Секрет — в миллионах тестов. Их полное выполнение может занимать от 20 до 30 часов (при этом выполняются они распределенно на тестовом кластере из 100-200 серверов).

В команде, которая работала над продуктом в конце 90-ых и придерживалась идей TDD (test-driven development), бытовало следующее мнение: «автоматизированные тесты означают то, что вы не обязаны писать код, который можно будет понять – вместо этого за вас должны думать тесты». В дальнейшем разработчики были вынуждены придерживаться заложенных ими принципами, и теперь мы на практике наблюдаем, чем обернулась эта идея в долгосрочной перспективе — со всеми ее плюсами и минусами.

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

Затем он отправляет код на тестирование, и на следующий день спокойно переключается на другую задачу, ожидая, пока тестовый кластер соберет новую сборку Oracle DB и прогонит на ней все тесты. Если разработчику повезло, «покраснеет» примерно 100 тестов; если нет (и этот вариант случается чаще) — около 1000, и ему придется проверять, какое из его предположений о работе существующего кода оказалось неверным; вполне возможно, что он обнаружит, что ему требуется изучить еще десяток различных флагов, которые неочевидным образом принимали участие в работе кода, который он изменил.

Этот процесс ему придется повторять в течении пары недель, прежде чем ему наконец не улыбнется удача и все тесты наконец-то пройдут. После чего он сам должен будет написать несколько десятков тестов — для того, чтобы убедиться, что разработчик, который потревожит его код в будущем, не поломает его «фикс». Затем доработки отправятся на ревью, которое может занимать от нескольких недель до пары месяцев, после чего баг наконец-то будет смержен в главную рабочую ветку.

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

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

В описанном случае, TDD позволяет не рассыпаться «спагетти»-коду, в котором уже крайне сложно что-то понять, и иметь на выходе рабочий продукт. При этом, издержки продолжают расти, и качество нового кода часто оставляет желать лучшего. Над СУБД работает не только команда разработчиков из США, но и команда из Индии, поэтому некоторые разработчики Oracle по сложившейся традиции сваливают вину за качество кода на них. Другие с ними не согласны, и основываясь на changelog заявляют, что качество кода не зависит от географии команды, и плохой код периодически «прилетает» от обеих команд. По-настоящему серьезная проблема для продукта — это разработчики, которые воспринимают проект как «вход в индустрию», и работают над СУБД не дольше 1-2 года; за это время существенно разобраться в тонкостях работы проекта невозможно.

По свидетельствам другого разработчика, который занимался портированием кодовой базы Oracle 8i на одну из версий Unix в конце 90-ых, код уже на тот момент представлял собой клубок «спагетти», который понять целиком было решительно невозможно. Еще один разработчик, который работал с кодом СУБД в конце 80-ых, утверждает, что тогда кодовая база представляла собой огромную кучу из исходников на C и набора makefile для сборки — многие из которых были устроены гораздо сложнее, чем код самого ядра. Конечно, стоит быть реалистами — едва ли ситуация обстоит лучше в аналогичных продуктах-лидерах индустрии, разработка которых велась в течение нескольких десятков лет.

Преимущества СУБД Oracle

Oracle Database Appliance – обзор после опыта использования / Хабр

Сначала пару слов про ODA. Это инженерная система, представляющая собой готовый стек – СХД, серверов и софта, которые подобраны друг под друга для обеспечения максимальной производительности. Аналогов у других производителей нет, т.к. весь стек тестировался производителем оборудования и ПО для выявления «узких» мест в производительности. В результате в ОДЕ нет веера разных конфигураций и все что можно сделать — это добавить дополнительную полку с дисками. В системе стандартный объем памяти, стандартный объем дисков, стандартные процессоры – никаких особых дополнений или вариантов конфигураций нет.

В нашем обзоре использована ОДА первого поколения, которая в габаритах 4 юнита, включает в себя 2 сервера, каждый с:

2x Intel Xeon X5675

96 Gb RAM

3 USB 2.0

2x 1GbE

1x 4-port 1GbE NIC

1×2-port 10GbE NIC

И систему хранения данных:

24х 3,5 600Gb 15K SAS

4x 3,5 73 Gb SSD

Фото – ОДА сзади, виден двойной БП, обе серверные ноды (хот плаг).

Развертывание

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

К вам приезжает новое оборудование, распаковав его, подключив кабели и вставив в стойку, можно сразу включать и разворачивать систему. Ода приезжает с уже установленной ОС и последними патчами на момент покупки, все что остается сделать это скачать себе бандл на несколько ГБ из интернета. Называется он End-User GI/RDBMS Clone files и содержит последнюю версию базы данных с патчами, собранную для Оды. Далее нужно его закачать на одну из нод инженерной системы, запустить простейший визард и за 1-1,5 часа вы будете иметь 2 сервера + СХД с настроенной и готовой к работе БД Oracle в одном из режимов: RAC, RAC one node или Fail-over. В случае, если будет использоваться 1С, либо нужны какие-то нестандартные настройки самой БД, их нужно будет создать посредством консоли dbca.

Можно взять доступные аналоги: сервера одни, СХД другие, ОС третья, БД четвертая из компонент, скорее всего разных производителей. Нужно будет потратить достаточно много времени, чтобы настроить ОС и базу на 2 серверах в виде кластера, потратить время на настройку системы хранения, а также на сопряжение и тестирование всей системы целиком. Здесь же общая трата времени 3 часа и в результате полностью рабочая машина БД. Также немаловажную роль играет количество человек нужных для настройки. В обычных случаях необходим специалист по железу + специалист по БД + возможно тестированию, тут — 1 человек и пара-тройка часов времени. Ну и максимум помощник, чтобы в стойку засунуть, вес то немаленький:).

Фото 2 и 3 – сзади со стороны БП и доступных портов.

Лицензирование

В БД Oracle все лицензирование идет по ядрам – которые как ни странно называются процессорными лицензиями. Если взять даже не самый современный сервер на 2 процессора по 4 ядра – всего 8 ядер, то по политике лицензирования это 8 процессорных лицензий каждая из которых стоит немало. Если запускать виртуальную машину для экономии на лицензиях, то для этого подойдет очень ограниченное количество продуктов (подробнее тут)

У ОДА есть одно большое и уникальное преимущество – она позволяет «из коробки» лицензировать базу данных только по необходимым ядрам, что называется capacity on demand. Это позволяет начинать лицензирование от 2 ядер и далее расти до 16. Основной смысл такого подхода – экономия на лицензиях, с возможностью простого роста.

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

Фото 4,5, 6 – внутри системы.

Варианты разворачивания

Начиная с версии 2.5, ОДА стало возможно развернуть уже двумя способами: виртуальная и «железная» конфигурации.

Первый вариант — «Железная» это установленный линукс и БД прямо на сервера, это не очень выгодно с точки зрения использования ресурсов, если у вас не максимальная нагрузка. В результате, если у вас используется 2 ядра под БД, остальные не заняты и соответственно простаивают.

Второй вариант –виртуальная. Для этого на обоих серверах установлены гипервизоры Oracle VM и на них загружается темплейт в виде ОДА (т.е. ОС + БД), которая после разворачивания начинает использовать СХД. Разворачивание виртуальной системы практически ничем не отличается разворачивания железной, зато в результате можно использовать оставшиеся ресурсы под другие виртуальные машины. Но и тут есть свои минусы, а именно поддержка исключительно темплейтов определенного формата, с расширением tgz. Для интересующихся — их можно скачать тут.

Если постараться, можно создать и собственный темплейт. Также небольшую ложку дегтя добавляет ограничение дискового пространства доступное серверам, т.к. под виртуальные машины используются внутренние диски, а не СХД.

Прочитав много обзоров и официальных, и неофициальных о этом инженерном решении, решил, что стоит акцентировать внимание на том, о чем там иногда не говорят.

1. Бандл нужно качать отдельно

2. Оракл всегда старается, чтобы при получении была самая последняя версия ПО, но иногда за время доставки, может выйти более новая версия.

3. Отсутствие разных конфигураций железа.

4. Невозможность использования встроенного СХД под виртуализацию.

5. Не самый удобный менеджмент виртуальных машин

6. Последняя версия БД на данный момент 11.2.0.4.0

Мои личные и субъективные выводы после опыта использования ОДЫ:

1. Экономия на времени развертывания. Легкая и быстрая установка. Настроить кластер обычно занимает очень много времени. Здесь после запуска небольшого визарда на 15 шагов — кластер готов.

2. Для обслуживания всей системы нужен 1 человек, не нужны отдельные админы по железу, БД, и СХД.

3. Экономия места для установки. Ода занимает всего 4 юнита в стойке. Что может очень положительно сказаться на размещении, например, в дата центре.

4.Так как все от одного вендора не будет всем знакомых и неприятных сюрпризов в виде несовместимости, так как все оборудование протестировано заранее.

5. Нет морального устаревания оборудования. Даже на старую ОДУ, даже если она уже не продается, до сих пор выходят обновления с функционалом не уступающим современной версии.

6. Экономия на лицензиях с возможностью моментального роста (было сказано выше).

7. Очень удобный мониторинг и управление самим оборудованием. ОДУ довольно просто перенастроить, перезагрузить, и даже переустановить целиком.

8. Отказоустойчивость, т.к. в ней все продублировано вдвойне и даже втройне.

9. ОДУ можно развернуть до достаточно большого количества ядер, близкому к таковым у минимально доступной Экзадаты, но это уже решение гораздо более серьезного уровня и тема совсем другой статьи.

И последнее — версия ОДЫ на данный момент это Х4-2. Просмотреть основные характеристики можно тут.

Контактная инфа

Все вопросы можно направлять: [email protected]

Спонсор поста: Cosmonova: data centers & telecom & software developer

Oracle Database: основные характеристики СУБД Oracle

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

Решением рассматриваемой задачи стало создание баз данных (БД) как средства хранения информации и систем управления базами данных (СУБД) как способа обработки.

Что такое СУБД

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

На сегодняшний день доступно несколько вариантов систем управления базами данных, отличающих как функционалом, так и требованиями к компьютеру. В качестве примеров современных СУБД можно привести Oracle Database, о которой пойдёт речь далее, MySQL, Access, SQL Server, Fox Pro.

Несмотря на разнообразие СУБД, все они делятся на два вида: многопользовательские и персональные.

Многопользовательские системы

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

• ядра, находящегося в памяти;
• сервера;
• неограниченного количества программ клиентов, выполняющих поставленные пользователями задачи.

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

Персональные системы

Данный тип предназначен для выполнения менее масштабных задач. Рассматриваемые системы размещаются на персональных компьютерах и взаимодействуют с одним пользователем. База данных и сама программа хранятся в памяти одного диска.

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

Подробнее об Oracle

Что собой представляет Oracle Database? Многие годы СУБД от компании Oracle предоставляет пользователям максимальный комфорт, безопасность, высокую скорость работы и надёжность. Система прекрасно показывает себя, и каждая её особенность важна для клиента. Большинство масштабных информационных систем не обходятся без использования данной СУБД.

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

Основные особенности системы

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

Важной особенностью также выступает многоплатформенность Oracle. Linux, Windows и любые другие операционные системы позволят эффективно организовать БД. Стоит упомянуть и миграционную политику. Переход на обновлённые версии организован крайне удобно, специальная программа поможет перенести данные с других систем.

Какие существуют варианты СУБД?

Разработчики предоставляют пользователям четыре варианта системы:

• Standard Edition;
• Lite;
• Enterprise Edition;
• Personal Edition.

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

Standard Edition

Крайне популярная версия, функционал которой несколько ограничен. Чаще всего она используется при создании систем для небольшого количества клиентов. Это лучший вариант для рабочей группы, небольшой компании и т. д. Но в больших организациях также есть место для Standard Edition, когда речь идёт об удалённых филиалах. Цена такой версии Oracle Database снижена, при этом имеющихся возможностей будет достаточно для эффективной работы.

Oracle Lite

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

Enterprise Edition

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

Personal Edition

Данный Oracle Database client прекрасно подойдёт для личного использования или обучения. Функционала будет достаточно для создания программ и их дальнейшего использования на нескольких версиях Windows. Они играют важную роль, т. к. в NT или «2000» доступны все возможности, а в 95/98/ME опции ограничены из-за особенностей операционной системы.

Особенности версии 11g

У пользователей часто возникали проблемы с установкой данной СУБД, и в версии 11g этот процесс был значительно упрощен. Кроме этого, стало удобнее проводить не только первоначальную, но и специализированную настройку. Система станет эффективнее, если её оптимизировать под требуемую задачу, и в Oracle Database 11g этот аспект грамотно проработан.

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

Как получить СУБД?

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

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

Установка Oracle 11g

Как установить Oracle Database 11g на Windows 7? СУБД упакована в архив, который после скачивания потребуется разархивировать.

Далее необходимо сделать следующее:

1. В папке DISK1 открыть установочный файл под названием Setup.exe.
2. Пройти окно приветствия.
3. Согласиться с лицензией.
4. Выбрать место для установки программы (но лучше всего оставить путь стандартным).
5. Создать учётную запись системного администратора.
6. Проверить указанные данные и подтвердить их.

Установка максимально проста, и все действия интуитивно понятны. Стоит заметить, что не только на Windows так легко установить СУБД от Oracle. Linux и все остальные операционные системы также не вызовут проблем, так как в большей мере процесс развертывания идентичен.

Краткий список нововведений в Oracle 12c / Хабр

Час назад прошла он-лайн презентация 12-й версии РСУБД Oracle.
На YouTube грохнули В хорошем качестве

Кому лень смотреть и переводить — кратко выжимка в посте.

Концепция 12й версии:
Вообще 12с означает CLOUD — суть в том, что предлагает объединять все свои БД (PluggableDB = PDB) в единое облако (CloudDB = CDB)
Сама технология называется Multitenant Database.
Важно — все PDB д.б. обновлены до версии 12c.
К одной CDB можно подключить до 255 PDB.

Фишки DBA:

1. Патч накатывается 1 раз на всё CDB — далее он реплицируется на все PDB автоматом.
2. 2 PDB объединенные в CDB можно MERGE-ить.
3. На все PDB пишется ТОЛЬКО 1 общий бэкап. Накатывается тоже 1 раз сразу на все.
4. Утилита Privileges Analysis — позволяет контролировать выданные права и роли, предотвращать «лишние» права.
5. Служебный процесс DataOptimization — сжимает «холодные» блоки таблиц.

Основные фишки кодера (их более 500):

1. Новый тип данных для PK — Identity. Сам создается сиквенс, который (видимо) создает триггер Before Insert и дергает его.
   Подобная вещь давно есть в PostgreSQL — называется SERIAL.
2. NOT NULL полю теперь можно присвоить ЗНАЧЕНИЕ ПО УМОЛЧАНИЮ даже если в нем есть данные. NULL-ячейки моментально обновляются на DEFAULT
3. БД-шный тип VARCHAR расширили с 4000 символов до 32000 символов (как в PL / SQL)
4. В запросах можно выбирать любые строки по номерам — выберите… ТОП 10 или выбрать 3,5 и 10 строки
5. Новый формат синтаксиса ф-ии в регулярных выражениях (можно делать гибкий поиск).
6. Он-лайн перемещение партиций таблиц (больше не надо останавливать экземпляр, все далает на лету).
7. Объясните план оптимизирован, учитиывает статистику, и горячие блоки (см. Фичу HeatMap).
8. Новые типы гистограмм при сборе статистики таблиц.
9. В UNDO и REDO логи больше не пишутся записи из TEMPORARY-таблиц. Теперь эти логи пишутся в САМИ временные таблицы.
10. Фича HeatMap (Карта обращений) — собирает статистику обращений к каждому блоку.Есть 3 типа: ГОРЯЧЕЕ, ТЕПЛО, ХОЛОДНОЕ.
    Перемещает «горячие» блоки перед «холодными» и «теплыми». Помещает эти данные в статистику таблицы. Далее учитывает при чтении.
11. Фича Transaction Guard — предотвращает повторные транзакции типа «дрогнул палец, нажал 2 раза».

Подробнее на офиц.сайте: Здесь

P.S.
Новые возможности Oracle Database 12c — часть 1
Новые возможности Oracle Database 12c — часть 2
P.P.S.
Новые возможности Oracle Database 12c — часть 3
Новые возможности Oracle Database 12c — часть 4

.

Особенности лицензирования и стандартной технической поддержки Oracle / Хабр

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

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

Форма заказа и стоимость стандартной технической поддержки

При покупке лицензий Oracle обеими сторонами подписывается документ, называемый «Форма заказа», который содержит перечисление лицензий, дату начала их действия и стоимость.

За все свои продукты и техподдержку Oracle требует 100% предоплату. Исключение из этого правила могут получить только бюджетные организации, попросив это официальным письмом.

При покупке программных продуктов сразу в обязательном порядке продается и стандартный техподдержка для нихомом на 1 год.

Сущность стандартной техподдержки (далее — СТП) состоит в том, что купивший ее имеет право бесплатного перехода на соответствующую версию ПО, а также получает поддержку доступа на сайт.oracle.com, на котором можно регистрировать свои багрепорты, читать решения по чужим, скачивать патчи.

Разумеется, по программе СТП Oracle решает только массовые проблемы. Необходимо получить расширенную техподдержку Oracle, чтобы получить расширенную техподдержку (менеджер Oracle прикинет, умножит на 3,14 и т.д.). Разумеется, необходима 100% предоплата, и по окончании периода неизрасходованные средства не возвращаются.

Стоимость СТП на 1-й год составляет 22% от стоимости лицензий, который имеет в Форме заказа. Каждый последующий год стоимость СТП увеличивается на 3% от своей величины (не от стоимости лицензий, а на 3% от своего предыдущего значения).
Эту надбавку Oracle называет «уровень инфляции». В лицензионном соглашении [1] Oracle обещает не повышать стоимость стандартной техподдержки более чем на 4% в год (Пункт H на стр. 4).

Последствия отказа от техподдержки

От стандартной техподдержки со второго года и далее можно отказаться, и продолжать легально использовать купленные продукты, но есть два нюанса:

1.Oracle потребует заплатить штраф — в 1,5 раза больше, чем стоила бы стандартная ТП за пропущенный период.

Понятно, таким образом Oracle страхуется от вариантов «раз в 3 года купил СТПом на 1 год и обновил версию ПО». По-моему некоторую сумму за возобновление ТП можно требовать, но наличие повышающего коэффициента при этом совершенно выходит за границы добра. Мало того, что по сути Oracle предоставляет выплату за неоказанную услугу (в России это незаконно), так еще и в 1,5 раза больше.

2. Свои программные продукты Oracle разделяет на «комплекты лицензий» (подмножество лицензий) — группы лицензий по их назначению (База данных, промежуточное ПО, приложения и пр.), Причем не важно, что они куплены в разное время по разным формам заказа .

Например, все купленные Вами базы данных Oracle отнесет к одному «комплекту лицензий», сервер WebLogic попадает уже в другую. Подробнее, какое ПО входит в какой «комплект» можно посмотреть в Политике технической поддержки Oracle Software [2].

Oracle требует, чтобы у Пользователя все лицензии из одного «комплекта» находились на одном уровне стандартных техподдержки. Уровней целых два — «есть СТП» и «нет СТП».

Теперь предположим, у Вас есть давно купленный Стандарт базы данных, на котором Вас крутится какая-то вспомогательная система, и Вам не нужна была СТП на ней. Сообщество Вам потребовалось докупить на бизнес-критичную задачу Database Enterprise. Вот Вы и попали на штраф за пропущенный период СТП для DB Standard.

Oracle предлагает замечательный выход такой из ситуации — отказаться от «лишних» лицензий, по которому вы не хотите платить штраф за пропущенный период СТП.

Тут некоторые задумаются, нельзя ли передать ли стандартному юрлицу БД перед покупкой DBE. Не углубляясь, замечу, что совместно использовать Oracle разными «своими» юрлицами тоже не просто, например, нельзя запускать пользователей из другого юрлица в DB, ​​если она лицензирована по NUP, а не по CPU.

Особенности политики скидок Oracle

Один из положительных моментов сотрудничества с Oracle в том числе, вы можете получить большие скидки, более 50% от GPL (стандартного прайс-листа) [3]. При этом пропорционально регулируется и стоимость стандартной техподдержки.

Но и тут не обошлось без пары половников дегтя:

1. Скидка c конкретными Форма заказа, и покупка лицензий никак не влияет на стоимость СТП для лицензий, купленных ранее.Т.е. у Вас СТП на один и тот же продукт, купленный по разным бланкам заказа, может стоить по-разному. Если компания у Вас росла, уменьшите объем закупок, скидка увеличивалась, и захотели меньше платить за первые лицензий, то варианты нет — пишите письмо о расторжении, отказывайтесь от них, потом покупайте их повторно, но уже с большей скидкой.

2. В то же время, отказ от части лицензий внутри одной Бланк заказа включает к перерасчету скидки на все продукты, купленные по этой Бланке заказа.Алгоритм пересчета, если он вообще есть, известен только Oracle. Из опыта мне известно, что хотя стоимость СТП и не увеличивается, но может совсем не уменьшиться, сделанным бессмысленным отказ от небольшой части лицензий из одной формы заказа ради уменьшения СТП.

Прощай, ВС

После покупки SUN Oracle начала распространять свою отработанную политику техподдержки на оборудование:

1. Сокращено количество вариантов техподдержки.
2. Введен штраф за пропущенный период техподдержки — как обычно, в полтора раза выше, чем стоимость ТП за тот же период.
3. Чтобы принудить всех купить техподдержку, сервисным центрам вообще запретили ремонтировать железо не проходящее по контракту техподдержки.

Заключение

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

Ссылки

1. Договор о лицензировании и услугах Оракл (на английском и английском).
2. Политика технической поддержки программного обеспечения Oracle.
3. Прайс-листы Oracle. .