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

11.5.4  Поради щодо організації роботи серверу Oracle.

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

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

Спираючись на завантаженість та інтенсивність роботи користувачів з базою даних, оберіть для себе термін, через який Ви будете зупиняти сервер Oracle і робити повну копію бази даних. Це гарантує Вам наявність повністю погодженого актуального набору даних. В разі краху носіїв інформації на сервері СКБД, Ви будете спроможні, використовуючи архівні журнали повторень, відтворити систему на момент краху з найменшими зусиллями.

11.6  Підтримка прикладної системи в робочому стані

Для підтримки застосовної системи у робочому стані необхідно:

·  Забезпечити наявність вільного дискового простору на тому диску, де встановлено сервер застосувань;

·  Виконувати моніторинг сесій користувачів на сервері застосувань (див. Розділ 3);

·  Виконувати поточне адміністрування користувачів системи:створення, видалення, розподіл прав (див. Розділ 8);

·  Очищення тимчасових таблиць, що пов’язані зі звітністю.

11.6.1  Очищення тимчасових таблиць в схемі БД

Коли користувачі формують звіти в АСЕДО, в базі даних Oracle створюються особливі тимчасові таблиці. Ці таблиці використовуються для зберігання результатів проміжних обчислень. Чим більше звітів користувачі формують, тим більше зростає об’єм даних у тимчасових таблицях. Таким чином, встає питання про регулярне очищення цих таблиць.

В СКБД реалізоване циклічне завдання (JOB), основною функцією цього завдання є очистка тимчасових таблиць від даних, що скопилися за робочий день. Це завдання виконується у нічний час, що не заважає роботі користувачів системи. Завдання запускається в автоматичному режимі і не потребує будь-якого налагодження. Єдина проблема, яка може статися, це зупинка сервісу на час виконання завдання. Треба час від часу переглядати на відсутність в базі таблиць на ім’я TTRPT_xxx – де xxx – унікальне ім’я таблиці. Відсутність таких таблиць перед початком робочого дня є ознака нормального функціонування даного завдання.

11.6.2  Виконання процесу збору статистики по таблицях БД

Для оптимізації функціонування СКБД існує такий метод, який дозволяє значно покращити (мінімізувати) час виконання запитів. Він базується на тому, що час від часу необхідно збирати статистичні дані про таблиці. Ці дані в подальшому використовуються оптимізатором запитів для побудови найоптимальніших запитів до таблиць. Збір статистики, ще деяка процедура, яка повинна виконуватись за певним розкладом. Вона оформлена у вигляді завдання системи Oracle (JOB) і виконується в кінці робочого дня та не заважає роботі користувачів. Адміністратор повинен передивлятись VIEW DBA_JOBS час від часу щоб бути впевненим у тому, що завдання виконується.

11.7  Проведення оновлень прикладної системи

При отриманні від розробника оновлень прикладної системи необхідно провести її оновлення як описано у Розділах 7.2.1 та 7.2.2.

11.8  Повсякденні обов’язки адміністратора системи

До повсякденних обов’язків адміністратора системи входить:

·  Забезпечення вільного дискового простору на серверах застосувань та БД;

·  Впровадження всіх необхідних заходів по запобіганню втрати інформації (регулярне повне архування бази даних, постійне архування журналів БД);

·  Виконування поточного адміністрування користувачів системи;

·  По необхідності виконувати адміністрацію користувацьких сесій не сервері застосувань;

·  Проводити моніторинг та якщо потрібно оптимізацію БД;

·  Вживати всіх необхідних заходів для попередження критичних ситуацій. У разі виявлення помилок у роботі системи АСЕДО необхідно вжити заходів щодо усунення проблеми самостійно за допомогою даної інструкції. В разі неможливості вирішення проблеми власними зусиллями – звернутись за допомогою до служби технічної підтримки, надавши повну та достовірну інформацію щодо даної проблеми.

Розділ 12.  Вирішення можливих проблем

12.1  Проблеми при інсталяції чи оновленні ПЗ

12.1.1.1  При встановленні базової версії чи оновлень за допомогою SDS агент оновлень видав повідомлення “Не можу встановити версію”

Для з’ясування подробиць даної помилки, необхідно переглянути інформацію, що формується у файлах config\globalinstall. log та config\install. log.

12.1.1.2  Повідомлення про помилку отримання даних:

·  Перевірте зв’язок з сервером, на якому розташований FTP. Це можна зробити з командного рядка командою ping ім’я серверу. Якщо зв’язку нема, усуньте причину пошкодження зв’язку;

·  Якщо зв’язок є, перевірте чи не могла статися така ситуація, що одночасно до FTP-сервера намагалося під’єднатись користувачів більше, ніж вказано в параметрах FTP-сервера;

·  В іншому випадку перевірте чи правильно у файлі installer. conf написаний шлях до сховища версій. Це параметри FTPSDS та FTPVERSIONS. Перевірте, чи не могли Ви помилитись, коли формували інсталяційний пакет для користувача: чи правильно ввели ім’я користувача SDS та його пароль. Якщо Ви не впевнені – переформуйте інсталяційний пакет. Для перевірки вірності параметрів зв’язку можна використати будь який файловий менеджер який має внутрішнього FTP клієнта.

12.1.1.3  Повідомлення про помилку відсутності інформації о ПЗ у файлі "Versions":

·  Перевірте параметр SOFT та VERSION. Якщо АСЕДО встановлюється вперше, необхідно, щоб SOFT=asedo, а номер версії в VERSION обов’язково вказував на базову інсталяцію, а не на оновлення;

·  Перевірте, що надано дозвіл на інсталяцію пакету. Це можна перевірити на сервери та прямо на клієнті. Для цього потрібно переглянути файл “versions” у папці “config” яка повинна бути у папці з SDS клієнтом;

·  Перевірте щоб у файлі “versions”, що знаходиться в сховище версій на FTP-сервері, був запис про версію, що встановлюється. Якщо цей запис відсутній, сховище якимось чином пошкоджено. Відновіть його з дистрибутивного диску та додаткових оновлень, якщо вони Вам були надані.

12.2  Інші проблеми

12.2.1.1  Якщо в сховищі версій є оновлення, а при запуску системи, агент оновлень говорить “Версія вже встановлена” і, не встановлюючи оновлення, запускає АСЕДО, перевірте наступне:

·  На серверній частині SDS запустіть SDSServer. exe і перевірте чи дали Ви права користувачу сховища на використання даної версії.

12.2.1.2  Якщо при інсталяції оновлень були критичні помилки, чи після оновлень програма не працює:

·  Перевірте яка версія насправді стоїть у користувача. Перегляньте файл installed_versions. Можливо Вам доведеться виправити версію встановленого компонента на попередню. Таким чином, агент оновлень переустановить оновлення начебто у користувача була встановлена попередня версія;

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

12.2.1.3  Агент оновлень знайшов нову версію, почав її встановлювати, але довгий час не видає ніяких повідомлень про хід роботи. Можливо, що при спробі завантажити версію з FTP-сховища виникнули проблеми в мережі і агент оновлень, не отримавши цілісну копію версії "завис"

·  В цьому випадку потрібно перезавантажити комп’ютер та повторити процедуру оновлення.

12.3  Проблеми при роботі з комплексом

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

12.3.1  Крах системи

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

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

12.3.1.1  Система працює нестабільно і це носить тотальний характер

1. Зробіть наступне:

·  Сповістіть всіх користувачів, щоб вони вийшли із системи;

·  Ті користувачі, у яких система “зависла” і вони не можуть коректно її покинути, повинні зробити наступне:

·  Викликати Менеджер Задач. Для цього одночасно натиснути клавіші “Ctrl”+”Shift”+”Esc”;

·  Перейти на вкладку “Processes”, знайти процес під назвою “devs_cli. exe”, та виділити його.

·  Натиснути кнопку “End Process”;

·  В діалозі підтвердження натиснути кнопку “Yes”.

2.  Зайдіть на комп’ютер, де розташований сервер DEVS під логіном адміністратора;

3.  Викличте консоль керування службами. Для цього натисніть кнопку “Start”, потім оберіть “Settings” і нарешті “Control Panel”. У панелі керування, що відкриється, оберіть “Administrative Tools”, а потім двічі клацніть на “Services”;