Sap индекс не существует в системе бд oracle
В первой части статьи я описал как в SAP системе рабочий процесс, используя двух этапный механизм, определяет пароль владельца ABAP схемы (SAP ) и подключается с помощью этого пользователя к базе данных Oracle.
Такой механизм использовался до версии Oracle 11g. Но с выходом базы данных Oracle 11g оказалось, что это последняя версия СУБД от Oracle, которая поддерживает OPS$-механизм для удалённого соединения с ней. В связи с этим компания SAP также внесла поправки в работу своих приложений. И начиная с SAP kernel Release 7.20 (примерно с 100 пакета поддержки) представила новый метод для хранения пароля владельца базы данных и соединения с ней. В SAP kernel Release 7.20 зашифрованный пароль для пользователя базы данных может хранится не в базе данных, а на уровне файловой системы. Такой способ называется Secure Storage in File System ( SSFS ).
И в этом случае рабочий процесс открывает соединение с базой данных в один шаг, читая контактную информацию и пароль пользователя из защищённого хранилища (рис. 1).
Одновременно должны быть установлены переменные окружения пользователя операционной системы adm (рис. 3).
Рис. 2. Параметры SAP инстанции, связанные с SSFS способом коннекта. |
Рис. 3. Переменные окружения пользователя ОС для SAP системы, связанные с SSFS способом коннекта. |
На уровне операционной системы в директории /usr/sap//SYS/global/security созданы специальные директории и файлы со строгими правами на доступ (рис. 4). В файле SSFS_.DAT хранится как раз информация необходимая для соединения с базой данных, включая зашифрованный пароль владельца схемы.
Рис. 4. Список директорий и файлов, хранящих информацию для соединения с базой данных. |
Для просмотра содержимого хранилища в SAP Kernel есть утилита rsecssfx . Набрав одноимённую команду, можно получить список всех записей (опция list ) или содержимое отдельной записи (опция get ). Содержимое записи с паролем зашифровано и не будет показано в целях безопасности (рис. 5).
Рис. 5. Пример использования команды rsecssfx. |
Вот так работает новый механизм хранения владельца схемы, включая его пароль.
Для обратной совместимости, вплоть до версий SAP Kernel 7.38 и базы данных Oracle 11.2 , поддерживается одновременно и старый, двух этапный, метод. Хотя SAP уже в этих версиях рекомендует переходить на новый метод хранения пароля на уровне файловой системы. Ведь сделать это можно даже в системах на базе SAP NetWeaver 7.0 , так как эти программные продукты поддерживают SAP Kernel 7.20 . Переход на это ядро я описывал в одноимённом посте.
- ORA-32004 : obsolete or deprecated parameter(s) specified for RDBMS instance,
- ORA-32006 : REMOTE_OS_AUTHENT initialization parameter has been deprecated.
Ну а начиная с SAP Kernel 7.40 поддерживается только SSFS механизм хранения пароля пользователя SAP .
Для смены пароля владельца схемы необходимо пользоваться SAP утилитами BR*Tools (версия не ниже 7.20 пакет поддержки 28). Команда вида:
изменит пароль и в системных таблицах Oracle, и в защищенном SSFS хранилище.
Есть правда небольшой нюанс на переходных системах, там где возможна работа обоих методов. Такая команда при выполнении проверит есть ли таблица OPS$ .SAPUSER . И если она ещё существует в базе данных, то пароль пользователя изменится в ней, а новое хранилище SSFS будет проигнорировано. Поэтому при переходе на новый метод необходимо эту таблицу удалить.
Либо в команде BRCONNECT можно использовать дополнительную опцию " -s|-secstore ", где можно указать поменять пароль для коннекта рабочими процессами ABAP инстанции. Например, командой вида:
В них детально описано как перевести систему на новый метод хранения пароля и соединения с базой данных.
Стоит ещё отметить, что SSFS механизм хранения пароля владельца схемы используется не только при разворачивании системы на Oracle, но и при работе с Sybase ASE, SAP HANA и SAP MaxDB (см. SAP note 1639578).
А если хотите погрузиться в администрирование базы данных Oracle на практике, то добро пожаловать в мой авторский курс по SAP Basis.
SAP R/3 форум ABAP консультантов
Russian ABAP Developer's Club
Russian ABAP Developer's Club Forum Index -> SQL and Database Changes |
View previous topic :: View next topic | ||
Author | Message | |
---|---|---|
admin Администратор
Как выбирать столбцы для индекса
Как выбирать составные индексы СОСТАВНОЙ ИНДЕКС - это индекс, состоящий из более чем одного столбца. Составные индексы могут предоставлять дополнительные преимущества по сравнению с одностолбцовыми индексами: 1) лучшая селективность. Иногда можно скомбинировать два или более столбцов, каждый из которых обладает низкой селективностью, в составной индекс, имеющий хорошую селективность. 2) дополнительный источник данных. Если все столбцы, выбираемые запросом, входят в составной индекс, то ORACLE может возвратить эти значения прямо из индекса, не обращаясь к таблице. SQL запрос может использовать путь доступа, включающий составной индекс, если это предложение содержит конструкты, которые используют ведущую порцию индекса. ВЕДУЩАЯ ПОРЦИЯ индекса - это один или несколько столбцов, которые были специфицированы первыми и подряд в списке столбцов предложения CREATE INDEX, с помощью которого был создан индекс. Рассмотрим следующее предложение CREATE INDEX: CREATE INDEX comp_ind ON tab1(x, y, z) Следующие комбинации столбцов являются ведущими порциями этого индекса: X, XY и XYZ. Другие комбинации столбцов, например, XZ, YZ или Z, не являются ведущими порциями этого индекса.
SELECT Выполняется примерно минуту. Добавляю и активирую индекс для поля KONNR в таблицу ekpo при наличии индекса выполяться будет быстрее в разы, причем пропорционально размеру таблицы, чем больше там записей тем большей разница будет при выполнении с индексом и без. а вообще рекомендую все таки по анализу производительности запроса посмотреть trace ST05, там все понятно что куда тратиться. по данному селекту. Это стандартная логистическая цепочка: контракт -> заказ на поставку. И тем не менее в EKKO нет индекса по KONNR. Почему? Посмотрите таблицу EKAB, там как раз к контрактам все созданные заказы. вот тут я поспорю проверено на практие еще раз повотрю проверено на практике, понимаю что в теории все должно быть краисиво., тем более если без JOIN ов вот тут я поспорю проверено на практие еще раз повотрю проверено на практике, понимаю что в теории все должно быть краисиво., тем более если без JOIN ов
- подвисает на часы. При том, что в обеих случаях выборка шла по первичному ключу, а DATUM стоял где-то в конце ключа. _________________ При внедрении информационных решений на базе SAP ERP, как правило, разворачиваются три системы: 1. Система разработки. В процессе разработки программ очень часто возникает необходимость оперативно протестировать SQL-запросы в продуктивной или тестовой системе, так как система разработки обычно содержит минимум данных и их не всегда достаточно. Давайте рассмотрим существующие для этого варианты, оценим их недостатки и в итоге разработаем свой инструмент. 1. Транзакция SE16/SE16NС помощью этой транзакции можно делать выборку только с одной таблицы. Не подходит для запросов с несколькими таблицами. 2. Транзакция ST04 (Additional functions -> SQL Command Editor)Этот инструмент позволяет выполнять SQL-запросы любой сложности, но имеет 2 недостатка:
3. Транзакция SQVIВ транзакции нельзя писать напрямую SQL-запросы, но можно с помощью конструктора строить достаточно сложные выборки из нескольких таблиц с JOIN`ами. Не умеет работать с подзапросами и к тому же в конструкторе приходится выполнять слишком много манипуляций мышкой, поэтому для тестирования запросов не подходит. 4. Написать простенькую программу с тестируемым запросом и перенести ее в тестовую системуПроцесс переноса измененного кода в тестовую (продуктивную) систему требует выполнения некоторых рутинных манипуляций и занимает в среднем 5-7 минут, поэтому данный вариант тоже не подходит, так как никакого терпения не хватит проделывать всё это после каждой правки запроса. 5. Прямой доступ к СУБДВ большинстве случаев получить разработчикам такой доступ на проектах не представляется возможным, поэтому данный вариант не подходит. ВыводПолучается, что удобного универсального инструмента, который бы позволял оперативно тестировать SQL-запросы любой сложности в SAP, не существует. Придя к такому выводу, я решил разработать такой инструмент. Приступаем к разработкеДля начала в транзакции SE80 создаем программу ZSQL, GUI-статус MAIN100 с кнопкой «Выполнить» и Экран 0100. Укрупнённо алгоритм программы выглядит так: Получение SQL-запроса SELECTДля получения SQL-запроса будем использовать текстовый редактор, который создадим на экране с помощью класса CL_GUI_TEXTEDIT. Для этого добавим на Экран 0100 пустой контейнер с именем MYEDIT, в который будем выводить редактор. Парсинг SQL-запросаИз введенного SQL-запроса нам необходимо получить список выбираемых полей и таблиц для того, чтобы в дальнейшем на основании этого списка динамически сгенерировать структуру ALV-Grid для вывода результата. Выполнение SQL-запросаЧтобы выполнить наш запрос, воспользуемся оператором generate subroutine pool, который позволяет динамически генерировать временные ABAP-программы на основании переданного в качестве параметра исходного кода, которым мы подготовим из введенного SQL-запроса. Вывод результата на экранТак как состав полей и их тип нам заранее неизвестны, то для получения результата и вывода его на экран нам необходимо динамически сгенерировать внутреннюю таблицу и структуру ALV-Grid на основании выбираемых в запросе полей. Для этого будем использовать метод create_dynamic_table класса cl_alv_table_create. Полный листинг исходного кода программы ZSQL: Разработанная программа позволяет выполнять Open SQL-запросы SELECT любой сложности. Только нужно соблюдать одно правило при написании запроса: если используется конструкция COUNT(), то после нее нужно дописывать «AS cnt», чтобы корректно сгенерировался ALV-Grid. Программу, по идее, можно немного доработать и использовать не только для тестирования запросов, но и для формирования пользовательских отчетов.
Но потом компания 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 нотах: Вот моя табличка по разным версиям базы данных Oracle, которые так или иначе поддерживались и поддерживаются в SAP продуктах. Специально не стал сжимать картинку, по клику доступен полный размер (рис. 1).
Для наглядности текущие поддерживаемые версии можно найти на рис. 2.
Так же рекомендую пролистать несколько документов. Со стороны 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 ноты, то пишите в комментариях. Обязательно внесу правки. Читайте также:
|