Управлінські інформаційні системи в аналізі та аудиті
Контрольная работа - Компьютеры, программирование
Другие контрольные работы по предмету Компьютеры, программирование
Контрольна робота
Управлінські інформаційні системи в аналізі та аудиті
Зміст
1. Вимоги до технічних засобів, що підтримують 1С
2. Оброблення інформації, управління, підтримки рішення
3. Заснована на знаннях (інтелектуальна) технологія
4. Перспективи розвитку інформаційних систем управління економікою
5. Показати на прикладі аналізу балансу розрахунок основних показників
Список використаної літератури
Додаток
1. Вимоги до технічних засобів, що підтримують 1С
„1С: Предприятие" - це універсальна програма автоматизації діяльності підприємства, яка використовується для будь-яких розрізів економічної діяльності підприємства, в тому числі й різних ділянок бухгалтерського обліку.
Програма "1С: Предприятие 7.7" має компонентну структуру.
Програма “1С: Бухгалтерия 7.7" працює в операційних системах Windows 95/98, NT.
Відповідно до вимог до обладнання, в реальному можна використати сервер на процесорі IBM CPU 2xIntel Xeon. Але можна зробити вибір сервера від іншого виробника (HP, SUN і так далі), використовуючи за основу приведену нижче специфікацію.
Зупиняємо наш вибір на процесорі IBM CPU 2xIntel Xeon 5450 3 GHz.
Таким чином, є варіант, згідно таблиці 1.1
Таблиця 1.1
Part No. ОписКіл-тьList PriceList PriceSystem xApp1Cfor50users-Орієнтовні ціни на 201071414RUx3850 M2, CPU 2xIntel Xeon 5450 3 GHz, 8x1GB, O/Bay HS 2.5in SAS, UltraSlim Enhanced CD-RW/DVD-ROM Combo, 2x1440W p/s, Rack1USD
14 279,00USD
14 279,0044E4243CPU 2xIntel Xeon 5450 3 GHz/1066MHz/8MB L22USD
3 339,00USD
6 678,0041Y2762RAM 4x4GB DDRII-667 LP RDIMM Memory Kit2USD 169,00USD 338,0040K1052HDD 8x 73GB 15K rpm в RAID104USD 259,00USD
1 036,0010N30711 Year Onsite Repair 24x7 4 Hour Response1USD
1 800,00USD
1 800,00---Разом: USD
24 131,00
Розглянемо проблеми, стосовно баз даних з"вмістом 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-контролер, який теж здатний частину операцій кеширувати в своїй памяті);
поліпшити код.
На останньому способі хочеться зупиниться. Це сфера діяльності програмістів. Це ча