1.1 Автоматизована система електронного документообігу Атлас-док (стр. 16 )

1.  Для нормального завершення роботи БД рекомендується запустити утиліту SRVMGR в консольному режимі (svrmgrl. exe);

2.  З’явиться запрошення системи, на яке потрібно відповісти рядком "connect";

3.  На запит "username" потрібно ввести "system as sysdba" та пароль користувача "manager". Система повинна відповісти "connected", що означає вашу аутентіфікацію в системі;

4.  Виконайте команду "shutdown immediate". Система повинна відповісти про нормальну зупинку БД;

5.  Необхідно виконати "холодне" архування для можливого відновлення поточного моменту за умов некоректного відновлення (див. частину №4 Процедура архівації БД);

6.  Визначте місцезнаходження кожного файла, що складає БД, та перепишіть їх файлами з "холодного" архіву. Також необхідно знайти та відновити всі файли архівних логів, що є доступними після останнього "холодного" архівування;

7.  Не виходячи з утиліти SRVMGR виконати команду "startup mount oradb" (де oradb – це ім’я БД в Oracle). Цією дією ми відновили БД на момент "холодного" архівування;

8.  Щоб відновити інформацію, що накопичилась в БД після "холодного" архівування, необхідно скористатись командою "recover database until time '2002-11-28:12:23:00' using backup controlfile" в утиліті SRVMGR. Необхідно замінити дату та час в наведеному прикладі, на дійсну дату та час, на яку необхідно відновлення. Звісно, таке відновлення може бути виконано, тільки за умови наявності всіх непошкоджених файлів архівних логів;

9.  Після такого відновлення рекомендується виконати команду alter database open resetlogs, яка скине порядкові номера журналів повтору. Після цього нумерація журналів повтору піде заново і старі архівні логи вже не знадобляться;

10.  На цьому кроці необхідно закрити БД командою "shutdown immediate" та створити "холодний" архів, як описано вище;

11.  Для відновлення роботи БД, необхідно в консолі утиліти SVRMGR ввести команду "startup", після чого БД буде змонтована і відновить функціонування. Для виходу з консолі необхідно ввести команду "exit".

Розділ 7.  Atlas Software Distribution System

7.1  Загальні принципи SDS та обов’язки адміністратора відносно SDS

Atlas Software Distribution System (Atlas SDS) являє собою систему розповсюдження програмного забезпечення та використовується для інсталяції та оновлень схеми БД, сервера додатків та клієнтської частини програмного комплексу.

Atlas SDS складається із сервера SDS та клієнтського інсталятора. На сервері розміщується: сховище версій у вигляді спеціальної файлової структури, файли с конфігураційною інформацією, FTP сервер (за його допомогою клієнтський інсталятор отримує версії) та утиліта налагодження і моніторингу сховища версій.

Усі компоненти сервера SDS можуть бути розташовані на одному комп’ютері разом з сервером додатків.

Архітектура SDS наведена на Мал. 6-1.

Мал. 6‑1

SDS базується на наступних принципах:

·  Усі інсталяції й оновлення ПЗ АТЛАС оформлюються у вигляді пакетів, які може встановлювати SDS;

·  SDS сховища версій організовані у ієрархічну структуру. Тобто, існує центральне сховище версій розробника, версії з нього можуть автоматично передаватися у сховище версій замовника, яке, у свою чергу, може мати ієрархічну структуру (наприклад, сховища версій у різних філіях). Крім того, при відсутності зв’язку з сайтом розробника, можливо поставляти нові версії з жорстких носіїв (наприклад, компакт дисків).

·  Інсталяція ПЗ на клієнтські комп’ютери повинна проводитися автоматично без втручання адміністратора.

·  Адміністратор повинен тільки проводити конфігурування інсталяції ПЗ у сховище версій та давати дозвіл на встановлення нового ПЗ та оновлень.

SDS працює наступним чином:

Кожен пакет інсталяцій складається з файлу, який містить безпосередньо компоненти, що встановлюються на клієнтський комп’ютер та файл, що описує правила встановлення, залежності цього продукту від базових значень, параметри які необхідні для інсталяції та їх значення за умовчанням.

За допомогою утиліти моніторингу і конфігурації сховища версій адміністратор має встановити фактичні параметри кожної інсталяції та дозвіл на її встановлення на клієнтські комп’ютери.

На SDS сервері існує своя система користувачів. Це ті користувачі, під ім’ям яких клієнтській інсталятор під’єднується до серверу SDS, перевіряє оновлення ПЗ та виконує інсталяцію. Типовою конфігурацією є один користувач для зв’язку з сервером SDS більш високого рівня, по одному для зв’язку з підлеглими сховищами SDS, та спеціальний користувач для інсталяції усіх компонентів системи (наприклад, користувач asedo_install для встановлення БД, серверу додатків, та клієнтів АСЕДО).

Для кожного такого “інсталяційного” користувача можна задати дозвіл на встановлення кожного пакету ПЗ та встановити фактичні параметри інсталяції. Якщо ці параметри не проставлені у сховищі версій, вони будуть запитуватись під час інсталяції на клієнтському комп’ютері.

Клієнтське ПЗ запускається на клієнтських комп’ютерах не безпосередньо, а через клієнтський інсталятор. Він в свою чергу під’єднується до сховища версій, перевіряє наявність нових версій і при їх наявності проводить оновлення.

Якщо у сховищі версій розмістити нову версію якогось ПЗ, вона не стає автоматично доступною для інсталяції, спочатку потрібно встановити її параметри та видати спеціальному інсталяційному користувачу дозвіл на інсталяції. Типова система складається з трьох компонент БД (тобто її структури і конфігураційних довідників), серверу додатків та клієнта. Для коректної роботи системи потрібно, щоб усі ці компоненти знаходились у відповідних версіях одна до одної. Якщо провести оновлення якоїсь одної компоненти, система не буде коректно працювати. У системах, розроблених на базі ДЕВС, існує автоматична перевірка версій. В описаному випадку буде видано повідомлення о неможливості роботи у зв’язку з невідповідністю версій. Таким чином, необхідно проводити оновлення ПЗ у наступному порядку: оновлення БД, оновлення серверу додатків, оновлення клієнтського ПЗ. Перші два оновлення адміністратор повинен ініціювати самостійно, оновлення клієнтського ПЗ буде виконано автоматично. Типовий сценарій оновлення системи:

·  Помістити в сховище нові версії, що отримані від розробника;

·  Сконфігурувати параметри інсталяції (оновлення БД);

·  Видати дозвіл на цю інсталяцію інсталяційному користувачу;

·  Ініціювати інсталяцію;

·  Попередні три пункти виконати для серверу додатків;

·  Сконфігурувати клієнтське ПЗ;

·  Видати дозвіл на його інсталяцію (вона буде проведена автоматично).

Клієнтській інсталятор після проведення інсталяції передає в сховище версій звіт про проведення інсталяції. Таким чином, за допомогою утиліти моніторингу сховища версій можна визначити, що встановлено, якої версії та на яких комп’ютерах.

Також для кожної інсталяції можливо створити пакет клієнтської інсталяції, який буде автоматично проводити інсталяцію “по єдиному дотику мишею”. Такі пакети необхідно створити для інсталяції та оновлення усіх компонент системи, тобто БД, серверу додатків, клієнтського ПЗ.

7.1.1  Обов’язки адміністратора:

·  Налагодити сервер SDS (сховище версій, FTP);

·  Розмістити у сховищі версій пакети відповідних інсталяцій та оновлень;

·  Створити інсталяційного користувача;

·  Для кожної компоненти системи встановити фактичні параметри, створити клієнтські інсталяційні пакети і видати дозвіл на проведення інсталяції створеному користувачу;

·  На комп’ютери, де буде встановлено відповідне ПЗ перенести інсталяційні пакети та ініціювати їх виконання для інсталяції цього ПЗ;

·  При отриманні оновлень ПЗ поміщати їх у сховище версій;

·  Відслідковувати появу нових параметрів і встановлювати їх фактичні значення;

·  Видавати дозвіл на інсталяцію кожної компоненти та ініціювати інсталяцію БД та серверу додатків.

7.1.2  Загальні відомості про сховище версій Atlas SDS

На дистрибутивному диску в папці SDS знаходиться серверна частина.

Табл 6‑1 Структура паки SDS на дистрибутивному диску, та її вміст

Папка	Файли	Призначення
SDS\	installer. exe	Клієнтський інсталятор
installer_console. exe	Додатковий модуль клієнтського інсталятора
rar. exe	Програма-архіватор
sdsserver. exe	Програма для адміністрування серверу SDS
Wget. exe	Транспорт для файлів інсталяції
readme. txt	Опис версій
Ncftpput. exe	Програма для відсилки повідомлень до серверу
Ncftpget. exe	Альтернативний транспорт для файлів інсталяції
_reboot. pif	Службовий файл
SDS\Tools\	Addinstall. exe	Програма-творець інсталяцій
SDS\config\	Versions	Файл-опис присутніх інсталяцій
SDS\versions\	rar-файли	Містять компоненти, що мають встановлюватися
conf-файли	Конфігураційні файли, містять правила інсталяції

Весь склад папки SDS викладається в папку на сервері, яка далі буде використовуватися як FTP-папка.

В процесі роботи SDS сервер буде створювати додаткові, необхідні для функціонування папки та файли всередині папки SDS.

Усі інсталяції поділяються на базові та оновлення. Кожна інсталяція складається з двох файлів, однакових за назвою та різних за розширенням: rar-файла, що містить компоненти для встановлення, та conf-файл, що описує правила встановлення. Базові інсталяції мають суфікс ic для клієнтських частин та is для серверних. Оновлення – відповідно uc та us.