Управлінські інформаційні системи в аналізі та аудит

12

Контрольна робота

Управлінські інформаційні системи в аналізі та аудиті

Зміст

• 1. Вимоги до технічних засобів, що підтримують 1С
• 2. Оброблення інформації, управління, підтримки рішення
• 3. Заснована на знаннях (інтелектуальна) технологія
• 4. Перспективи розвитку інформаційних систем управління економікою
• 5. Показати на прикладі аналізу балансу розрахунок основних показників
• Список використаної літератури
• Додаток

Розглянемо проблеми, стосовно баз даних з "вмістом 1С: Предприятие".

Найчастіше недооцінюється вплив дискової підсистеми сервера. Бажання економити зрозуміло тут на кількості і вартості жорстких дисків. Проте при великій кількості користувачів, наприклад, "1С: Предприятие 8" можна навіть відразу починати моніторинг із звернень до диску.

Причин (на думку фахівців 1С) тут декілька:

1) Активно використовується tempdb. Складні запити 1С, транслюючись сервером додатків „1С: Предприятие" в sql-запит, розбиваються на частини і їх результати записуються в тимчасові таблиці службової бази даних tempdb. Останніми роками в конфігураціях „1С: Предприятие" стали часто використовуватися конструкції з використання об'єкту "Менеджер тимчасових таблиць". Якщо такі конструкції в явному вигляді присутні в запиті, то ще до принципу з трансляцією запиту в sql-запит до бази даних зрозуміло, що це гарантована тимчасова таблиця в tempdb.

Взагалі, таке використання даних само по собі не є чимось поганим. Завжди раніше приділялось tempdb уваги менше, ніж потрібно було.

По умовчанню tempdb створюється на системному диску, куди встановлюється примірник MS| SQL| Server| 2005. Тут слід турбуватися цим моментом (і з погляду продуктивності, і з погляду контролю вільного місця на диску). Перенесіть файл бази даних на "швидкі" диски. Є така практика створювати додаткові файли tempdb, щоб їх загальна кількість відповідала кількості ядер.

СУБД краще за все розпоралелює звернення до I/O чим RAID. Журнал транзакцій бажано винести в окремий диск/масив.

2) Запити без відборів провокують інтенсивне читання диска. І не тільки це можуть бути звіти, але помилки в будь-яких запитах, які читають надмірні дані замість тільки необхідних. Кількість баз 1С на сервері впливає на вибір дискової підсистеми - розміщувати активне використовувані бази на різних дисках/масивах, не допускаючи надмірних черг до дисків. Потрібно пам'ятати, що кращий спосіб підвищити продуктивність звернень до дискової підсистеми - це "розвести" дискові операції по об'єктах звернень.

Так помірявши лічильниками Performance |Monitor| відсоток часу на читання і відсоток часу на запис (і з'ясувавши що їх співвідношення не є 99% до 1%, а наприклад 70% до 30%), ми перш за все повинні звернути увагу на файл журналу транзакцій (операції запису) і винести на окремий диск/масив.

Тут є одне но. Але, ця дія ефективна, коли у властивостях бази даних Recovery| Model| в значенні Full (таке значення зазвичай задається за умовчанням при створенні бази, ще точніше "успадковується" з властивостей системної бази model).

3) Недолік пам'яті примушує СУБД виконувати "підвантаження" з диску. Один з основних способів прискорення запитів - це розміщення даних в кеші, тобто в оперативній пам'яті. Але кеш не виключає повністю читання з диску. Але, по-перше, перше звернення до даних все одно викликає підвантаження, "підіймаючи" їх в кеш. По-друге, наступає момент, коли в кеші "одночасно всім тісно", і залишаються "потрібніші", а "неугодні" знову потім можуть бути лічені з диску.

Краще всього проводити моніторинг картини що відбувається в кеші СУБД такими лічильниками Performance |Monitor| як "Частота попадань в кеш" (SQLServer| Buffer| Manager| \ Buffer| Cash| Hit| Ratio|) і "Час життя сторінки" (SQLServer| Buffer| Manager| \ Page| life| expectancy|). Значення першого приблизно >=92%|, другого > 300 секунд.

Тобто, якщо спостерігається проблема з кешем, то виникає три варіанти:

додати пам'ять (зазвичай найдешевше буває);

поліпшити дискову підсистему (до речі, наприклад використовуючи сучасний RAID-контролер, який теж здатний частину операцій кеширувати в своїй пам'яті);

поліпшити код.

На останньому способі хочеться зупиниться. Це сфера діяльності програмістів. Це часто найдорожчий варіант. Але самий кращий спосіб вирішення проблеми.

Приклад. Виникають проблеми з 100% завантаженим сервером. Були загружены повністю процесори, що досить нехарактерне для „1С: Предприятие" (4 ядра обслуговувало 50 користувачів). Щоб зрозуміти, що відбувається був використаний продукт фірми 1С - Центр Управління Продуктивністю. Хоча в даному випадки за допомогою якої програми вирішувати задачу не принципово. Ви можете скористатися будь-яким продуктом, який може Вам розібратися, "хто вантажить" MS SQL Server. Зробив запис логів і потім піддав їх автоматичній обробці. З'ясувалося, що на сервері виконується не дуже довгий за часом запит (декілька десятків секунд), але його частота виклику кожним користувачем дуже велика (тисячами). Як же було здивування, коли проаналізоване структуру коду - звичайне "ліве з'єднання" і пара "відборів" - нічого особливого. Запит був "переформульований". Тепер він повертав той же результат, але вже за одну секунду. Наступного дня відбулося "диво", сервер СУБД мав завантаження менше ніж 15%.

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

Страницы: 1, 2, 3, 4