СУБД - дискового простору, до меншої кількості операцій читання і, таким чином, до скороч...

Реферат - СУБД

дискового простору, до меншої кількості операцій читання і, таким чином, до скорочення часу на читання таблиці. З другого боку, оновлення таких рядків відбувається шляхом видалення старої і вставки новою, в той час, як рядки з полями фіксованої довжини можуть обновлятися "на місці", що значно швидше. Ще один приклад - використовування великого числа індексів скорочує час виконання запитів, що сполучають декілька таблиць і сортуючих одержані рядки. Але в той же час, індекси уповільнюють операцію вставки нових записів. Додатки по обробці даних можна умовно розділити на два класи: * Системи оперативної обробки транзакцій, що характеризуються великою інтенсивністю вставки і оновлення записів. * Системи підтримки ухвалення рішень, що характеризуються складною обробкою великих об'ємів даних. Ці додатки, як правило, не обновляють дані, але проводять різні підсумовування, сортування і зв'язують дані з численних таблиць. Зрозумівши, до якого класу відноситься ваш додаток, можна робити вибір з суперечливих альтернатив при проектуванні логічної структури. Правда, часто додатки повинні поєднувати якості як однієї, так і іншої системи, так що доводиться знаходити компроміси. В цьому випадку може виручити розділення додатку на дві підсистеми, кожна з яких функціонує на своєму SQL Server'е, і забезпечення інформаційного зв'язку підсистем за допомогою тиражування даних. Проектування шляхів доступу Коли створена структура бази даних, можна проектувати запити, за допомогою яких клієнтські додатки маніпулюватимуть даними на сервері, здійснюючи операції вибірки, вставки, зміни і видалення даних. Кожний запит характеризується певним шляхом доступу до даних. В поняття шляху доступу входить: * структура таблиці, до якої звертається запит; * поля, по яких відбувається пошук; * індекси, які можна використовувати для прискорення пошуку; * склад полів, які обновляються в процесі виконання запиту. Мета проектування оптимальних шляхів доступу - мінімізація кількості операцій читання/запису при виконанні клієнтських запитів. Основа для цього повинна бути закладена на етапі проектування структури бази даних. Оптимізація шляхів доступу Головне питання в оптимізації шляхів доступу - використовування індексів. Якщо якийсь запит вибирає рядки в таблиці по полю "field1", то за відсутності індексу по цьому полю сервер скануватиме всю таблицю, що може бути дуже "дороге" в термінах операцій читання. Якщо по полю "field1" побудований індекс, то кількість операцій читання може скоротитися в декілька тисяч раз. Індекси істотні також при операціях з'єднання таблиць (JOIN) і операціях сортування. Які ще моменти необхідно враховувати при проектуванні шляхів доступу? Це * звернення клієнта до серверу через SQL-запит або через виклик береженої процедури. Другий варіант працює трохи швидше, але необхідно враховувати один важливий нюанс. План виконання береженої процедури складається при її першому (після створення) виклику і потім бережеться в кеші. Цей план оптимізується для набору параметрів і індексної статистики, що мала місце саме при першому виклику. При подальших викликах цей план може виявитися неоптимальним, тобто може бути потрібно перекомпіляція процедури, наприклад, шляхом виклику з опцією "WITH RECOMPILE". * проведення операцій оновлення "на місці" або шляхом видалення з подальшою вставкою - оновлення "на місці" проходить набагато швидше. * наявність трігерів, що спрацьовують на вставку або зміну запису, може істотно уповільнити відповідні операції. Очевидно, що в процесі проектування шляхів доступу може виникнути необхідність переглянути рішення, прийняті при проектуванні структури даних. Також очевидно, що при розробці крупних додатків буває неможливо проаналізувати всі шляхи доступу. Зосередитися потрібно на критичних шляхах доступу, враховуючи розмір таблиць, частоту звернень до них і вимоги до часу виконання запиту Апаратура і продуктивність не випадково апаратура стоїть у нас на 3-м місці серед ключів до продуктивності. Цим я хотів підкреслити важливість хорошої структури і шляхів доступу. Насправді, звичайно, апаратура важлива не менше. Прошу пробачити дещо банальну аналогію, але грамотний проект бази даних, оптимальні шляхи доступу і швидкий сервер такі важливі для продуктивності системи, як досвідчені водій і штурман і могутній автомобіль для перемоги на авторалі. Процесор Процесор, як правило, достатньо інтенсивно використовується SQL Server'ом. Щоб хоча б якісно оцінити навантаження на процесор, необхідно відповісти на наступні питання: * чи Буде комп'ютер виділений для SQL Server? * Скільки клієнтів працюватимуть з сервером? * Яке очікуване число транзакцій в одиницю часу? * чи Велика частка агрегативных операцій? Кількісно оцінити завантаження процесора можна, проводячи тестові випробування і відстежуючи параметри продуктивності за допомогою Windows NT Performance Monitor. Краще, звичайно, не скупитися на процесорі і обмежити свій вибір знизу хоча б 486/50. Пам'ять

Міністерство освіти і науки України

Міжрегіональна академія управління персоналом

РЕФЕРАТ

На тему:

“Основні технічні параметри СУБД Microsoft SQL Server. Архітектура. Виконання процедур. Модель зберігання даних. Сервіси Microsoft SQL Server”

Виконав: студент гр. Ф-26-10-05-С3ПАС

Форисюк В.В.

Перевірив: Солтисяк К.Т.

м. Івано-Франківськ

2008 р.

Сторінки: 1 2 3 4 5 6 7 8 9 10