Конфигурирование службы удаленной оболочки

Для использования RSH ее демон (rshd) или служба должны быть доступны в исходной системе. Подробности о том, как это сделать, доступны в документации используемой операционной системы. Стандартная процедура использования RSH следующая:

1. Нужно правильно сконфигурировать полномочия, чтобы ID пользователя в системе назначения мог запускать Optim High Performance Unload для исходной системы. Проще всего это сделать, создав или изменив файл .rhosts в домашнем каталоге экземпляра Db2. Если эта система Db2 многораздельная, указанный файл уже должен существовать.
2. В файл .rhosts нужно добавить однострочную запись, задающую имя системы хоста, один или несколько пробелов, а затем ID пользователя, которому к этой системе нужно предоставить доступ. С этим ID он сможет запускать команды оболочки в указанной системе удаленным способом, как будто это другой пользователь.

Например, файл .rhosts в домашнем каталоге владельца экземпляра db2inst1 на хосте prodsrvr содержал бы в себе следующую запись:

bkupsite.yourcompany.com db2bkup

Здесь к имени системы хоста добавлено имя интернет-домена yourcompany.com. Это может не требоваться; посмотрите информацию в документации операционной системы или возьмите в качестве примера существующий файл .rhosts. С этой записью в файле .rhosts и при условии, что служба RSH доступна на хосте prodsrvr, пользователь db2bkup в системе bkupsite сможет вводить команды на хосте prodsrvr как пользователь db2inst1. Например, если пользователь db2bkup введет следующую команду rsh, команда pwd (print working directory - вывести на печать рабочий каталог) будет выполнена в удаленной оболочке, запускаемой на prodsrvr от имени db2inst1, а вывод введенной команды будет возвращен на терминал db2bkup:

[/home/db2bkup] $ rsh prodsrvr -l db2inst1 pwd
/home/db2inst1
[/home/db2bkup] $

Команду db2hpu можно использовать непосредственно в сеансе удаленной оболочки, указав к ней полный путь, или создать для системы prodsrvr небольшой выполняемый сценарий, вызывающий команду db2hpu. Вот пример такого сценария оболочки Korn в подкаталоге bin домашнего каталога db2inst1:

[/home/db2inst1] $ cat bin/myhpu
#!/bin/ksh
# Сценарий оболочки Korn для вызова команды db2hpu
/opt/IBM/HPU/V5.1/bin/db2hpu $*
[/home/db2inst1] $

Все параметры, заданные в вызове myhpu станут параметрами для команды db2hpu. Если в экземпляре установлена база данных SAMPLE, а ID схемы для таблиц представляет собой владельца экземпляра, вы можете извлечь содержимое таблицы DEPARTMENT с помощью следующего вызова:

[/home/db2bkup] $ rsh prodsrvr -l db2inst1 bin/myhpu -d sample -t department
INZU462I Начало шага управления HPU: 16:22:46.311.
INZU463I Окончание шага управления HPU: 16:22:46.445.
INZU464I Начало шага выполнения HPU: 16:22:46.481.
"A00","SPIFFY COMPUTER SERVICE DIV.","000010","A00",
"B01","PLANNING","000020","A00",
"D11","MANUFACTURING SYSTEMS","000060","D01",
"D21","ADMINISTRATION SYSTEMS","000070","D01",
"C01","INFORMATION CENTER","000030","A00",
"D01","DEVELOPMENT CENTER",,"A00",
"E01","SUPPORT SERVICES","000050","A00",
"E11","OPERATIONS","000090","E01",
"E21","SOFTWARE SUPPORT","000100","E01",
INZU410I Утилита HPU выгрузила 9 строк 9 на  хосте prodsrvr для
DB2INST1.DEPARTMENT in stdout.
INZU465I Окончание шага выполнения HPU: 16:22:49.132.
INZU412I Работа HPU успешно завершена: Реальное время -> 0m2.820795s
Пользовательское время -> 0m0.110000s : Родитель -> 0m0.060000s, Потомки -> 0m0.050000s
Системное время -> 0m0.090000s : Родитель -> 0m0.060000s, Потомки -> 0m0.030000s

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

• Всегда включайте опцию сообщения (-m). Будут возвращаться только данные, а статистика выгрузки - сохраняться в указанном файле в исходной системе (не будет возвращаться в систему, откуда вводилась команда rsh). Нужно изменить сценарий, задав эту опцию на постоянной основе, вместо того, чтобы изменять ее многократно как параметр сценария. Optim High Performance Unload выполняет задачу возвращения сообщений отдельно от загружаемых данных. Optim High Performance Unload всегда записывает данные в стандартный вывод (stdout), тогда как все сообщения, ошибки и остальное записываются в стандартный вывод ошибок (stderr). Например, если перенаправить stdout вывод в файл, а stderr оставить соединенным с окном терминала, по завершении операции в файл будут записаны только данные, а отчет о выгрузке останется на экране:

  [/home/db2bkup] $ rsh prodsrvr -l db2inst1 bin/myhpu -t
  department > dept.del
  INZU462I Начало шага управления HPU: 16:26:41.961.
  INZU463I Окончание шага управления HPU: 16:26:42.088.
  INZU464I Начало шага выполнения HPU: 16:26:42:115.
  INZU410I Утилита HPU выгрузила строк: 9
  на хосте prodsrvr для
  DB2INST1.DEPARTMENT in stdout.
  INZU465I Окончание шага выполнения HPU: 16:26:44.770.
  INZU412I Работа HPU успешно завершена: Реальное время -> 0m2.808720s
  Пользовательское время -> 0m0.090000s : Родитель -> 0m0.060000s,
  Потомки -> 0m0.030000s
  Системное время -> 0m0.100000s : Родитель -> 0m0.060000s,
  Потомки -> 0m0.040000s
  [/home/db2inst1] $ cat dept.del
  "A00","SPIFFY COMPUTER SERVICE DIV.","000010","A00",
  "B01","PLANNING","000020","A00",
  "D11","MANUFACTURING SYSTEMS","000060","D01",
  "D21","ADMINISTRATION SYSTEMS","000070","D01",
  "C01","INFORMATION CENTER","000030","A00",
  "D01","DEVELOPMENT CENTER",,"A00",
  "E01","SUPPORT SERVICES","000050","A00",
  "E11","OPERATIONS","000090","E01",
  "E21","SOFTWARE SUPPORT","000100","E01",  

• Отделить сообщения от данных можно также, введя символ 2 сразу перед символом переадресации файла (2>). Пример этого метода и преимущества его использования смотрите в теме "Сжатие".