Пользователи могут также переходить с помощью System • Own Spool Requests к обзору своих собственных запросов спула.
Рис. 11.15. Обзор запросов спула
Таблица 11.1. Состояние спула и запросов вывода
| ID | Состояние |
| - | He существует запроса вывода |
| + | Генерируется запрос спула |
| waiting | Запрос вывода еще не обработан |
| in proc | Запрос форматируется |
| printing | Запрос печатается спулером хоста |
| compl | Запрос успешно напечатан или перенесен на спулер хоста |
| <F5> | Запрос спула создал несколько запросов вывода, все с различными состояниями |
| Problem | Запрос был напечатан, несмотря на незначительную проблему, но вывод, вероятно, содержит ошибки |
| Error | Запрос спула не может быть напечатан |
| Archive | Запрос был обработан и ожидает архивации |
| Time | Было спланировано специальное время для вывода запроса |
Отсутствие вывода или испорченный вывод указывает на ошибки управления выводом. В таких случаях администратор с соответствующими полномочиями может проверить журнал вывода, чтобы найти указания о причинах ошибок.
При проблемах с печатью всегда необходимо сначала проверить работоспособность устройства на уровне операционной системы. Для этого нужно использовать команды, специфические для операционной системы, такие как lpr или print. Если к устройству невозможно обратиться на уровне операционной системы, то к нему нельзя обратиться и из системы SAP R/3.
Можно вывести содержимое, выбранные для генерации настройки, журнал вывода (но только для запросов вывода) и статистические данные для каждого спула и запроса вывода, перечисленные в ►Output control.
Обзор запросов вывода в ►Spool administration включает конфигурационные функции системы спула и статистическую информацию, такую как число запросов печати на устройство, на хост назначения или на пользователя (см. рис. 11.16).
Рис. 11.16. Обзор запросов печати
Эта информация представляет интерес, когда оценивается общая структура устройств вывода. Нагрузка должна быть разделена между инстанциями SAP R/3 как можно равномернее.
Проверка установки
Немедленно после первой настройки системы или после значительных изменений в структуре спула рекомендуется проверить конфигурацию с помощью ►Installation check. Эта проверка не включает данные спула (запросы спула и вывода или TemSe).
Обслуживание объектов TemSe
Данные запроса спула (неформатированные) хранятся во временных последовательных объектах (TemSe). Эти объекты содержат данные спула и аналогичные данные, такие как журналы фоновых заданий и временные данные FI и HR. Физически TemSe является таблицей в базе данных или файлом (вне базы данных) в файловой системе сервера приложений или в глобальном каталоге системы SAP R/3. Точное расположение зависит от параметра инстанции rspo/store_location. Значением по умолчанию является «db», что означает хранение в базе данных. Задание значения параметра как «G» сохраняет данные в глобальном подкаталоге в дереве каталогов SAP (см. главу 1). Если данные хранятся в базе данных, то они подчиняются административным методам и мерам безопасности РСУБД: управлению транзакциями и журналами, а также регулярному резервному копированию. Однако это означает также, что РСУБД должна выполнять некоторую работу, поэтому доступ к TemSe в файловой системе будет быстрее. Если TemSe хранится в файловой системе, нагрузка на РСУБД снижается, но преимущества, которые предоставляет РСУБД, недоступны. Например, резервные копии данных должны создаваться отдельно, и они не включаются автоматически в системную копию.
Статистическую информацию можно найти на уровне заполнения и содержимого TemSe с помощью ►TemSe Management или ►Spool administration • Environment • TemSe administration. Выберите TemSe database • Memory allocation (или TemSe data storage • Memory Occupation с версии Basis Release 6.10) для просмотра списка всех данных, хранящихся в TemSe для пользователя и клиента, включая пространство для хранения данных, которое требуется каждому пользователю и клиенту. Когда TemSe хранится в базе данных SAP R/3, размер сегментов базы данных ограничивает размер хранилища данных TemSe. Если данные хранятся в файлах на уровне операционной системы, то максимальный размер файловой системы является максимальным размером TemSe. Однако соображения производительности предполагают поддержание базы данных TemSe как можно меньшего размера.
Реорганизация системы спула
Администратор должен обеспечить удаление запросов спула из TemSe, когда они больше не требуются. Необходимо регулярно выполнять отчет RSPO1041 (см. главу 9 и рис. 11.17). Существенные критерии выбора включают возраст запроса спула (в зависимости от его статуса) и данные о том, не устарел ли он. Запрос спула является устаревшим, когда истек его срок хранения. По умолчанию срок хранения запроса спула — восемь дней (см. рис. 11.1). Можно также автоматизировать удаление устаревших запросов спула с помощью ►Spool Administration • Settings • Spool system • Admin.
Отчет RSPO1041 удаляет только данные спула из TemSe. Для удаления других типов данных нужно использовать отчет для журналов фоновой обработки RSBTCDEL (см. главу 9).
Для применения RSTS0022 используйте путь меню ►TemSe management • TemSe database • Reorganization. Этот путь меню не запускает отчет RSPO1041 или его предшественника RSPO0041. Отчет RSTO0022 необходимо выполнять с большей осторожностью, чем это требуется для двух других отчетов, так как он удаляет все устаревшие записи из TemSe без учета зависимостей от других таблиц.
Проверка согласованности
Чтобы ответить на потенциальные проблемы в оптимальное время, необходимо спланировать проверку согласованности системы спула и хранилища данных TemSe на регулярной основе.
► Проверка согласованности системы спула