Аудит Oracle

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

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

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

Этот вопрос также является наиважнейшим почти во всех случаях, особенно если у вас в настоящее время есть ULA (Unlimited License Agreement), поскольку это, безусловно, отразится на том, как Oracle будет считать Ваши лицензии, кроме тех случаев, когда у подобные реорганизации бизнеса предусмотрены Вашим соглашением. Учтите, что с точки зрения Oracle изменение размера организации - всегда хороший повод для проверки.

Это вряд ли автоматически повлечёт за собой аудит, но важно понимать, не используете ли Вы устаревшие метрики лицензирования, как, например, Concurrent Devices. Oracle захочет перевести Вас с данных метрик на современные, и аудит может быть простым способом вынудить Вас сделать это. Таким образом, это вопрос второй очереди, и его вы должны задать себе сами.

Это вопрос третьей очереди, если только у Вас нет соглашения, покрывающего возможности работы с вашей инфраструктурой сторонних фирм, особенно если Вы предоставляете коммерческие услуги на базе этой платформы (в этом случае данный вопрос быстро становится приоритетом №1!). В последнем случае это считается частным хостингом (proprietary hosting) и это уже не то, что Oracle мог бы легко допустить. Если у вас нет соответствующего соглашения (PHA, Proprietary Hosted Agreement) и этот сценарий относится к вам, Вас, наверняка проверят. Кроме того, убедитесь, что должным образом лицензированы все Ваши подлежащие лицензированию разработки, и Вы не подпадаете под OTN (Oracle Technology Network Free Developer License).

Проверьте, правильный ли у Вас используется тип лицензирования. Например, стандартные контракты предназначены только для внутреннего использования. От вышеупомянутых контрактов отличаются договоры, в которых описываются типы лицензирования «хостинг» ("hosting") или «встроенные лицензии» ("embedded") . Таким образом, ваши контракты (даже ULA) могут не распространяться на некоторые из приложений, с которыми работают ваши заказчики.

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

Этому вопросу можно присвоить приоритетом №3. Хотя могут возникнуть трудности, Oracle весьма сложно получить всю необходимую им информацию, а для третьей стороны очень легко сменить окружение Oracle, которое могло бы вызвать вопросы. О чем-то подобном Oracle, вероятно, спросит, но, скорее всего, это ничем страшным Вам не грозит. Тем не менее, во многих случаях Вы несёте ответственность за платформу, которую Вы используете с участием третьей стороны или с Oracle On-Demand; если аутсорсинг-провайдер привносит изменения, которые влияют на лицензирование, Вы должны об этом знать.

Это ещё один вопрос с приоритетом №5. Это стандартная метрика, и в абсолютном большинстве случаев организации используют её должным образом. Это незначительный риск, если только вы не управляете средой, которая открыта в Интернет, и которая лицензирована только с использованием метрики NUPs.

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

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