Сигрид Хагеман - SAP R/3 Системное администрирование

Рис. 12.3. Перенос архивных файлов

Кроме соединения с системой архивирования, возможно также сохранение вручную архивных файлов, созданных на этапе 1 в другой среде, такой как магнитная лента.

Этап 3

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

► Удаление данных из базы данных, когда файл архивирования был создан.

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

► Удаление данных из базы данных после переноса архивного файла во внешнюю систему хранения.

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

Начиная с R/3 Enterprise, программа удаления может планироваться независимо от реального архивирования как периодическое фоновое задание.

Выбор данных для архивирования

Данные в системе R/3 могут потребовать архивирования из-за увеличения стоимости сопровождения растущей в объеме БД или из-за того, что некоторые данные больше не требуются. Но администратор системы R/3 или администратор БД не может решить, какие именно данные подлежат архивированию. Это решение нужно принимать совместно с пользователями.

Первая задача состоит в преобразовании представления приложения в техническое представление БД R/3. Необходимо определить, какой объект архивирования лучше всего отвечает этим требованиям. Иногда объекты архивирования логически и хронологически связаны друг с другом. Возьмем в качестве примера объект архивирования MM_MATNR (главная запись материала из компонента mySAP Logistics). Объект такого типа нельзя архивировать пока существуют объекты, ссылающиеся на главную запись материала, и которые еще не архивированы. Поэтому, если все еще существует документ закупки (объект ММ_ЕККО), который ссылается на главную запись материала, заданную для архивации, и который еще не был сам архивирован, то сеанс архивирования для ММ_ MATNR будет прекращен с сообщением об ошибке.

Взаимосвязь между архивированием объектов можно проиллюстрировать с помощью сетевого графика (см. рис. 12.4), который доступен через ► Archive Administration Initial screen • Goto • Network graphic.Иерархическое представление архивируемых объектов и их взаимосвязей показывает, в каком порядке они должны быть архивированы для достижения оптимального хранения данных. Каждый архивируемый объект символизируется узлом внутри сетевого графика. Цветной прямоугольник в каждом узле показывает статус архивирования объекта.

Рис. 12.4. Сетевой график для объекта MM_MATNR

Отношения между архивируемым объектом и соответствующими таблицами можно проанализировать с помощью компонента ADK ► Tables and archiving objects. Здесь перечислены все таблицы, данные из которых включаются в выбранный: объект архивирования; все архивируемые объекты, содержащие данные из выбранной таблицы, также выводятся. В принципе можно архивировать только согласованные объекты.

На рис. 12.5 показан существующий архивируемый объект для таблицы RFBLG, который называется FI_DOCUMNT — документ финансового учета. Также показаны все таблицы в объекте FI_DOCUMNT.

Объем данных, подлежащих архивированию

После выбора объекта архивирования данных нужно определить объем данных, подлежащих архивированию. Чтобы определить, даст ли архивирование какой-нибудь выигрыш, нужно получить информацию о текущем физическом и логическом размере таблиц в базе данных объекта. Физический размер — это фактическое пространство памяти, занимаемое в БД. Логический размер — это число записей в таблице. Есть два метода анализа размера, которые в сильной степени зависят от БД.