Пятничный юмор

Сегодня немного о вопросах интеграции. :)

За картинку спасибо Александру Тельпуку.

Если у вас есть забавные иллюстрации для публикации в пятничном юморе, присылайте мне на электронную почту - shibolov@gmail.com.


Автор: Шиболов Вячеслав Анатольевич

Базовые механизмы СУБД Oracle: Redo Logs и Undo Segments

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

Поэтому этот пост прошу воспринимать не как попытку показать какой я умный, а как попытку упорядочить картину прежде всего у себя в голове. Знаете же выражение: пока объяснял, сам понял. :)

Теперь можно начинать. :)

Представим базовую часть СУБД Oracle в виде схемы, изображённой на рисунке 1. Предупреждаю сразу: тут далеко не все части и процессы Oracle. Я отобразил только те процессы и компоненты, которые важны в рамках механизмов, которые я буду описывать далее.

Рис. 1. Базовая структура базы данных Oracle.

СУБД Oracle можно разделить на две части:

• инстанция базы данных, состоящая из процессов и общих областей памяти (System Global Area или SGA), 
• файлы базы данных на уровне файловой системы.

Как вы скорее всего уже знаете, при использовании базы данных Oracle в SAP системах в качестве клиентов базы данных выступают рабочие процессы SAP инстанций (SAP WPs). Каждому такому процессу соответствует один рабочий процесс со стороны инстанции Oracle (shadow process).

Data block

Самая маленькая логическая единица, которую Oracle использует при операциях с данными - это data block. При создании базы данных его размер можно выбрать, но в SAP инсталляциях размер data block всегда 8 Кб (8 192 байт).

Database buffer cache

Все данные базы данных Oracle содержатся в дата-файлах (data files), которые хранятся на дисковом хранилище. Однако обработка данных никогда не производится напрямую в файлах. При операциях чтения соответствующий процесс базы данных (shadow process) сначала копирует данные из дата-файлов в Database buffer cache (конечно, если этих данных еще нет в кэше). И только после этого передаёт данные пользователю, то есть рабочему процессу SAP. Так как все подключенные к инстанции Oracle пользователи могут совместно использовать одни и те же, скопированные из дата-файлов в Database buffer cache, данные, то данный механизм существенно ускоряет последующие операции чтения.

Размер Database buffer cache инстанции Oracle имеет ограниченный размер, так как оперативная память сервера не безгранична. Поэтому в кэше хранятся только последние прочитанные блоки данных. А перезапись блоков кэша происходит по алгоритму LRU («наиболее давно используемый»).

Любые изменения данных в базе данных (операции INSERT, UPDATE или DELETE) также всегда производятся в Database buffer cache. При этом изменённые блоки кэша помечаются как «dirty blocks». При копировании данных в кэш такие блоки (dirty buffers) не могут быть перезаписаны shadow процессами, до тех пор пока эти изменённые блоки не будут скопированы в дата-файлы. Записью «dirty blocks» занимается не shadow процесс, а специальный фоновый процесс инстанции Oracle - DBW0 (database writer).

Процесс DBW0 активируется в следующих случаях:

• перед тем, как скопировать данные в кэш, shadow процесс сканирует области Database buffer cache на наличие не изменённых блоков, которые можно перезаписать. И если количество сканированных блоков достигает определённого порогового значения, то shadow процесс сигнализирует DBW0, чтобы он записал часть «dirty blocks» на диск. DBW0 копирует часть «dirty blocks» в дата-файлы, используя алгоритм LSU (Least Number of Stream Used). После этого эти блоки в кэше становятся доступными для shadow процессов.
• в момент Checkpoint, когда DBW0 записывает все «dirty blocks» из Database buffer cache в файлы на дисках. Событие Checkpoint инициируется фоновым процессом CKPT. Детали будут чуть ниже.

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

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

Консистентность данных

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

Как я уже рассказывал здесь, транзакция базы данных - это LUW (logical unit of work) сервера базы данных. Так как LUW всегда атомарная, то изменения из LUW должны быть или выполнены полностью, или полностью отменены. Для достижения консистентности данных (и консистентности чтения данных) в рамках концепции LUW СУБД Oracle использует Redo-записи для отката или восстановления (например, после сбоя) и Undo-записи для отката неподтверждённых (uncommitted) транзакций.

Redo-записи

Redo-записи содержат информацию необходимую и достаточную для того, чтобы реконструировать, восстановить или откатить, внесенные в базу данных с помощью SQL-запросов данные прежде всего в подтверждённых (commit) транзакциях.

Параллельно с изменением блоков данных в Database buffer cache, shadow процесс записывает Redo-записи в Redo log buffer. Это круговой буфер, находящийся в SGA, в который временно записываются все завершённые и незавершённые изменения данных. Фоновый процесс LGWR (log writer) периодически записывает порции записей из Redo log buffer последовательно на диск - в Online redo log file. 

Oracle redo log file имеет заранее заданный фиксированный размер и не растёт динамически, как обычный файл. Поэтому, когда текущий Online redo log file заполняется, процесс LGWR закрывает файл и начинает запись в следующий. В SAP инсталляциях по умолчанию используется 4 группы Online redo log files по 2 копии файлов в каждой. Online redo log file, в который LGWR пишет в данный момент, называется CURRENT. А процедура переключения файлов называется log switch.

Так как количество Online redo log files также заранее ограничено, Oracle перезаписывает старые Redo-записи новыми, используя эти файлы по кругу. 

Каждый log switch СУБД увеличивает LSN (log sequence number). С помощью LSN Oracle автоматически создаёт последовательные номера для Redo log files. 

LGWR начинает запись в следующие моменты:

• при подтверждении (commit) любой транзакции,
• каждые 3 секунды,
• когда Redo log buffer полон на одну треть,
• когда DBW0 собирается записать изменённые блоки из Database buffer cache на диск, а некоторые соответствующие Redo-записи еще не были записаны в Online redo log files. Таким образом предотвращается попытка записи с опережением журналирования (write-ahead logging).

Этого достаточно для того, чтобы всегда иметь место для новых Redo-записей в Redo log buffer. При этом по умолчанию размер этого буфера при установке в SAP системах небольшой (1 - 8 Мб).

Дополнительно когда пользователь (рабочий процесс SAP) подтверждает завершение (commit) транзакции, транзакции присваивается SCN (system change number) базы данных. Oracle записывает SCN, вместе с Redo-записями транзакции в Redo log buffer. При этом DBW0 нет необходимости записывать блоки данных в момент подтверждения (commit) транзакции. Потому что в СУБД Oracle используется журналирование с опережением записи.

Новые значения модифицированных данных, которые хранятся в Redo-записях, называются «after images».

Undo-записи

Undo-записи содержат информацию необходимую для отмены или отката любых изменений в блоках данных, которые были выполнены в результате неподтверждённых (uncommitted) транзакций.

Undo-записи содержат старые значения изменённых данных, называемые «before images».

Oracle хранит Undo-записи в специальных Undo сегментах, которые хранятся в специальном пространстве - Undo space. При этом Undo space может быть реализовано двумя способами:

• Automatic Undo Management (AUM),
• Manual Undo Management.  

При AUM администратор должен лишь создать специальное табличное пространство - Undo tablespace (PSAPUNDO) достаточного размера и настроить пару параметров Oracle. Управление Undo сегментами СУБД осуществляет сама.

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

Начиная с Oracle 9i по умолчанию используется AUM.

Таким образом Undo-записи хранят информацию для транзакций, сохраняя её в Undo space, как минимум, до завершения транзакции. Так как данные записи используются для отката транзакций, то Undo-записи могут быть перезаписаны только после того, как транзакция будет подтверждена (commit) или сброшена (rollback). 

Стоит отметить, что Oracle может использовать Undo-записи и для других целей. Например, для консистентного чтения из snapshots. В этом случае данные читаются из «before images». В то время, как происходит изменение этих же данных в ещё неподтверждённых (uncommitted) транзакциях.

Control file

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

Control file содержит записи, которые определяют физическую структуру и состояние базы данных. Например, в нём хранится информация о табличных пространствах, именах и положении дата-файлов и Online redo log files, а также текущий LSN.

Править файл напрямую нельзя. Только процессы СУБД могут вносить изменения в control files. Если физическая структура базы данных изменяется (например, добавляется новый дата-файл), СУБД автоматически обновляет control file.

Oracle control file очень важен для работы базы данных. Поэтому несколько копий могут быть сохранены в разных местах, а СУБД обновляет их одновременно. В SAP системах по умолчанию сконфигурировано 3 копии control files.

Checkpoint

Checkpoint это момент времени, в котором файлы базы данных находятся в консистентном состоянии. Достигается это состояние тем, что в этот момент DBW0 сбрасывает все текущие изменённые блоки из Database buffer cache в дата-файлы. За инициацию события Checkpoint отвечает специальный фоновый процесс CKPT, который и даёт команду процессу DBW0 начать запись блоков. Одновременно Checkpoint обозначает специальную позицию в Redo log. 

Что происходит в момент Checkpoint:

1. DBW0 активируется, получая сигнал в определённые моменты времени от фонового процесса CKTP.
2. DBW0 копирует все текущие «dirty blocks» на диск. Причём, пока DBW0 закончит выполнять запись, другие блоки в кэше могут быть изменены, но они уже не записываются.
3. Когда событие Checkpoint закончится (то есть будут записаны все выбранные блоки), самый старый буфер из «dirty blocks» в Database buffer cache будет обозначать точку в Redo log, после которой может быть начато восстановление в случае сбоя. Это позиция журнала и называется Checkpoint position.

Кроме этого процесс CKTP также выполняет следующие шаги:

• записывает информацию о Checkpoint в заголовок каждого дата-файла,
• записывает информацию о Checkpoint position в Online redo log file в контрольный файл Oracle (control file).

Информация о позиции Checkpoint в Online redo log file в контрольном файле необходима в процессе восстановления инстанции. Позиция Checkpoint сообщает инстанции Oracle, что все Redo-записи, которые были записаны до этого момента, не нуждаются в восстановлении. Так как эти данные уже записаны в дата-файлы.

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

Хотя частоту Checkpoint можно настроить через параметры Oracle, при разворачивании SAP систем эти параметры не используются. А Checkpoint всегда возникает только в моменты переключения Online redo log files (log switch).

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

Теперь основываясь на всех механизмах, которые были описаны выше, разберём как происходит восстановление базы данных.

Речь пойдёт не о восстановлении из резервной копии базы данных, которую должен выполнять администратор. А речь пойдёт об автоматическом восстановлении базы данных, которое СУБД производит в момент старта. Так называемое instance recovery. Оно необходимо, если предыдущий останов базы данных был выполнен не чисто, например, с опцией IMMEDIATE или ABORT. Или произошёл сбой работы сервера базы данных по аппаратной или программной причине.

Автоматическое восстановление при старте содержит следующие важные шаги:

1. В control file находится последний Checkpoint. После этого, начиная с позиции Checkpoint, читаются Redo-записи из Online redo log files и заново проводятся все транзакции, указанные в журнале. Происходит процесс roll forward. Заметьте, что этот шаг всегда включает и проведение изменений для Undo space, то есть восстанавливаются «before images».
2. Для всех заново применённых транзакций, которые не были подтверждены (commit) до сбоя или были отменены прямо перед сбоем (поэтому для них нет подтверждения в Redo log), выполняется откат. Для отката используется образ «before images» из Undo space. СУБД уверена, что это всегда возможно, потому что Undo-записи незавершённых транзакций из Undo space никогда не удаляются и не перезаписываются.

В результате после открытия консистентная база данных содержит только те изменения, которые были подтверждены (commit) перед сбоем.

Из процесса восстановления базы данных видно, что Online redo log files это одна из критически важных частей сервера Oracle. А если вспомнить, что в SAP установках Checkpoint наступает только в момент log switch, то при автоматическом восстановлении СУБД всегда нужен последний Online redo log file целиком. И если он будет потерян во время сбоя, то полное восстановление (complete recovery of database) будет невозможно. В результате чего данные будут потеряны, а база данных может оказаться в неконсистентном состоянии.

Поэтому-то Online redo log files должны храниться минимум в двух копиях, каждая из которых расположена на отдельном диске. Так же в продуктивной системе база данных должна работать в ARCHIVELOG режиме. В этом режиме фоновый процесс ARC0 (archiver) копирует каждый только что записанный Online redo log file в Offline redo log file. Offline redo log file в своём имени содержит LSN. Понятно, что копирование возможно начать только после переключения (log switch) и необходимо закончить до повторного возвращения процесса LGWR к этому файлу. Так как в таком режиме перезапись старых Redo-записей в Online redo log files не разрешается до тех пор, пока эти записи не скопированы в Offline redo log files.

Ну и должно соблюдаться ещё одно ограничение: могут быть перезаписаны только те Redo-записи, которые расположены до позиции Checkpoint в Redo log. То есть соответствующие им изменения уже записаны в дата-файлы. Это гарант возможности автоматического восстановления инстанции в случае сбоя.

Об Online redo log file и ARCHIVELOG режиме я подробно рассказывал в постах:

• Журнальные файлы Oracle и archivelog mode. Часть I,
• Журнальные файлы Oracle и archivelog mode. Часть II,
• Файл-пустышка.

Если хотите разобраться в вопросах администрирования базы данных Oracle на практике, то можете приобрести мой обучающий курс SAPADM 2.0. Этой теме в курсе полностью посвящён третий пакет заданий. 

Автор: Шиболов Вячеслав Анатольевич

Обучение SAP Basis. SAPADM 1.0: Разархивация

В 2014 году я опубликовал пятый пакет своего первого обучающего курса SAPADM. Курс был построен на платформе Windows/Oracle. А изучать установку и SAP администрирование надо было на базе системы SAP ERP 6.0. 

В прошлом году я обновил свой обучающий курс, переведя его на платформу Linux/Oracle и используя в качестве системы свежую версию - SAP NetWeaver 7.5. В рамках этого обучающего курса мною был недавно опубликован анонс нового пакета заданий по администрированию базы данных Oracle. Аспектов администрирования базы данных в первой версии обучения не было.

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

Сравнительная таблица обоих курсов приведена ниже (рис. 1).

Рис. 1. Сравнение обучающих курсов.

Чем может быть интересен первый курс: 

• Низкая цена. 
• Темы, которых нет во втором обучающем курсе. 
• Низкие требования к оборудованию. 
• Другая платформа.

Описание обучающего курса SAPADM 1.0 можно найти по этой ссылке.

Если кто заинтересовался, просьба писать мне на shibolov@gmail.com. 

P.S. До 15 июля возможна дополнительная скидка при покупке всех пакетов курса SAPADM 1.0 разом. 

Автор: Шиболов Вячеслав Анатольевич

Обучение SAP Basis. Новый пакет заданий - SAPADM 2.0. Пакет 3

Друзья, спешу поделиться хорошей новостью - в обновленном курсе обучения SAPADM 2.0 появился новый пакет заданий. 

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

Рис. 1. Описание заданий третьего обучающего пакета курса SAPADM 2.0.

Новый пакет продолжает дело предыдущих двух пакетов: 20% теории плюс 80% практики. Вы получите больше 280 страниц моей документации приправленной большим количеством снимков экранов, ссылок на дополнительные статьи и ресурсы. 

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

Как всегда полная поддержка с моей стороны в плане ответов на дополнительные вопросы и ссылок на материалы. 

В обучении используется SAP система, установленная в предыдущих пакетах: SAP NetWeaver 7.5 на Oracle 12.2.0.1 и SUSE Linux. Аппаратные требования идентичные предыдущим пакетам. 

Цена за SAPADM 2.0. Пакет 3 - 16 000 рублей.

Тем, кто купил предыдущие 2 пакета этого курса и хочет получить новый пакет, до 15 июля я готов отдать его со скидкой 15% - за 13 500 рублей. После 15 июля цена будет уже без скидки. 

Пишите мне на почту shibolov@gmail.com с указанием в заголовке письма названия обучающего курса - SAPADM 2.0.

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

Автор: Шиболов Вячеслав Анатольевич

Особенности работы дискового массива HPE 3PAR

В жизни специализироваться только на SAP Basis у меня получается далеко не всегда. Да и лично мне больше интересно строить и администрировать системы на всех уровнях, начиная от аппаратного обеспечения и операционных систем, и заканчивая тонкостями серверов приложений SAP. Поэтому периодически приходится сталкиваться с нюансами работы того или иного оборудования. Всю свою карьеру до текущего момента я тесно работал с оборудованием компании Hewlett Packard. В 2009 году я уже публиковал похожий пост "Особенность работы HP EVA-5000", в котором я описал нюансы работы дискового массива EVA-5K, с которыми столкнулся на практике.

Сегодня расскажу про дисковый массив HPE 3PAR StoreServ. Один из заказчиков выбрал данное решение при переносе своей SAP инфраструктуры. Об этом я упоминал в посте про миграцию. Дисковый массив обладает хорошей производительностью и отказоусточивостью. RAID массив полностью на SSD дисках, конечно же, показывает очень хорошие результаты по времени отклика и количеству IOPS. Но уже дважды сталкиваемся с одной особенностью поведения системы, о которой я и решил рассказать. 

Дисковый массив подключен к серверам через SAN сеть, что является проверенным решением Enterprise уровня. У дискового массива 2 контроллера, в каждом из которых по 6 оптических портов. В реализованном у заказчика решении дублирование оптической сети реализовано через резервирование SAN-коммутаторов. Таким образом, от дискового массива до каждого из вычислительный серверов идёт, как минимум, 4 оптических линка (задействованы не все порты контроллеров). 

На всех аппаратно-программных уровнях SAN сети используется, рекомендуемый (и со стороны 3PAR, и со стороны VMware) multipathing, когда все линки используются по кругу, распределяя нагрузку и повышая производительность.

Пока все линки живы, всё работает просто прекрасно. Но, если хотя бы один линк "погибает", то наблюдается странная картина. Дело в том, что дисковый массив не отключает оптический порт, а просто фиксирует на нём ошибки контроля чётности (CRC error), объявляя порт деградировавшим (рис. 1).

Рис. 1. Пример ошибки оптического порта на HPE 3PAR.

Со стороны метрик производительности дискового массива фиксируется увеличение показателей Service Time даже при незначительной нагрузке. Особенно в плане операций записи (средний график) (рис. 2). Здесь видны колебания до 3 мс, когда обычно (при всех работающих линках) показатели не превышают 0,5 мс.

Рис. 2. Метрики производительности на уровне HPE 3PAR при сбое SAN порта.

Со стороны виртуальной среды VMware видна идентичная картина с метриками производительности дисковой подсистемы (рис. 3). Здесь тёмная линия  это Usage в Кб/сек. А голубая линия - это более интересный показатель - Latency в мс. Стоит отметить, что когда все линки работают без сбоев, то при любой нагрузке, генерируемой всеми вычислительными системами в текущей инфраструктуре, параметр Latency никогда не превышает 0 мс. А тут периодически выстреливает аж до 600 мс.

Рис. 3. Метрики производительности дисковой подсистемы со стороны VMware.

Всё это было бы не так страшно, но реальное приложение, SAP система, ведёт себя очень странно. В своей карьере я ничего подобного не видел. Периодически возникают дикие фризы, когда в очереди диспетчеров SAP инстанций накапливаются рабочие процессы с запросами типа COMMIT и UPDATE (рис. 4). Такая картина висит несколько секунд, иногда до 30-40, потом всё проскакивает и очередь сбрасывается до 5-8 работающих процессов. Между фризами система работает нормально минуту-две.

Рис. 4. Пример зависания SAP системы.

Так как резервное копирование выполняется по той же SAN сети, то время на создание копии также вырастает более, чем в 2 раза (рис. 5).

Рис. 5. Пример увеличения времени резервного копирования базы данных при сбоях SAN порта.

Как я уже говорил, дисковый массив не отключает SAN порты, а крутит линки по кругу. Натыкаясь на сбойные, все операции подвисают (работа фризится), увеличивая задержки на всех уровнях. Затем, когда массив понимает, что через эти линки ничего не отправить, он переключается на рабочие и моментально проводит все запросы (SSD же :) ). Работать очень не комфортно, ощущения как от зубной боли.

Помогает в данном случае, ручное отключение сбойных портов. После чего производительность работы системы нормализуется. Посмотрите на графиках выше точку времени около 12:30. В этот момент порты были отключены (переведены в OFFLINE). Для наглядности детальный график Latency (рис. 6).

Рис. 6. График Latency в момент отключения портов на работающей системе.

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

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

Автор: Шиболов Вячеслав Анатольевич

SAP на базе данных Oracle: долговременное сотрудничество

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

• Статистика по ОС/СУБД с установленными SAP системами,
• Опрос: статистика по SAP платформам,
• Опрос: дистрибутив Linux и версия ORACLE.

Но потом компания Oracle попробовала создать свою систему управления предприятиями (Oracle E-Business Suite). Но в нашей стране (и возможно в других,  кроме США) данное программное обеспечение не нашло большого распространения. 

Теперь компания SAP решила попробовать себя на рынке баз данных. Под "попробовать" я, конечно же, имею ввиду SAP HANA. Все предыдущие попытки (MaxDB, Sybase ASE и т.п.) не были столь амбициозны, как эта. И вот в рамках текущего прорыва SAP решает полностью отказаться от других баз данных. И прежде всего от Oracle, как владельца наибольшего куска "финансового пирога" в базах данных в SAP инфраструктуре. Компания выставляет жесткие сроки окончания поддержки Oracle со своей стороны, ограничиваясь аж 2017 годом. Клиентов, использующих предыдущие (до SAP S/4HANA) продукты, также стимулируют быстрее перебегать на "тёмную" сторону  (шутка), пугая окончанием поддержки после 2025 года. 

Но прорыв забуксовал. Сначала Иван Иванович помирился с Иваном Никифоровичем, то есть SAP с Oracle, подписав в 2017 году новое соглашение о долгосрочном сотрудничестве. Продлив таким образом совместную поддержку Oracle до 2025 года. Потом сжалились и продлили срок жизни и для SAP ERP 6.0. 

К чему я это? Я не бизнес-аналитик и не берусь рассуждать о том какая бизнес-стратегия правильная, а какая нет. Как пел Владимир Высоцкий: "жираф большой, ему видней". Что в текущих реалиях можно перефразировать: "у SAP денег много, ему видней". Но что всё это означает для нас, простых сапёров? А то, что "SAP + Oracle" поживёт ещё. Давайте немного разберёмся с тем, что касается технической стороны вопроса жизни системы в такой связке.

Информацию о поддержке разных версий баз данных Oracle в продуктах SAP можно найти в следующих двух SAP нотах:

• 1174136 - Oracle: End of Support Dates,
• 2606828 - Oracle Database Roadmap for SAP NetWeaver.

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

Рис. 1. Версии Oracle и информация по ним.

В таблице свёл информацию по версиям, годам выпуска, датам окончания поддержки, в каких SAP продуктах может встречаться (тут только R/3, ERP системы). Далее привожу три типа SAP нот для каждой версии базы данных: центральная нота (появились с версии 11g), ноты с последними пакетами патчей и ноты с параметрами. Самая полезная это центральная техническая нота - с неё удобно начинать и в ней можно найти почти всю информацию по текущей версии, ну и получить список дополнительных SAP нот.

Обратите внимание, что начиная с 2018 года у Oracle изменилась политика в именовании продуктов - в маркетинговой версии стало фигурировать число от года выпуска. Хотя по сути, 18-й и 19-й релизы это продолжения 12-ой ветки. 

Для наглядности текущие поддерживаемые версии можно найти на рис. 2.

Рис. 2. Поддерживаемые на текущий момент версии Oracle.

Так же рекомендую пролистать несколько документов. Со стороны SAP это "SAP on Oracle Development Update" от марта 2019 (скачать можно тут). Со стороны Oracle - "Oracle for SAP. Technology Update" (декабрь 2019 года) и "Oracle for SAP Database Update" (апрель 2020 года). 

В данных документах описано какие технологии Oracle можно использовать в SAP системах. Начиная от Multitenant и заканчивая In-Memory или Oracle Exadata Database Machine, которые все сертифицированы SAP и которые можно смело использовать. Не HANA-ой единой, как говорится.

Вот такая вот картина. Надеюсь, вам пригодится.

P.S. Если у кого есть дополнения к таблице или полезные SAP ноты, то пишите в комментариях. Обязательно внесу правки.


Автор: Шиболов Вячеслав Анатольевич