Ви можете підтримувати бази даних SharePoint в належному стані за допомогою стандартних заходів технічного обслуговування. Для адміністраторів SharePoint важливо зрозуміти, що представляють собою завдання технічного обслуговування, і дізнатися, в яких ситуаціях і як виконувати ці завдання
ARUBA INSTANT WI-FI: ПРОСТІ, ПОТУЖНІ, ДОСТУПНІ
Адміністратори SharePoint стоять на варті порядку при кожному розгортанні SharePoint. Цілісність даних SharePoint походить від належної організації сайтів, колекцій сайтів, типів контенту і тегів метаданих. Керуючі настройками і функціями SharePoint адміністратори несуть відповідальність за загальну продуктивність і стабільність всієї платформи SharePoint. І хоча оптимальна продуктивність ферми SharePoint - це щось більше, ніж хороший набір баз даних, без сумніву, що цей набір повинен забезпечувати роботу компонентів нижчого рівня настільки гладко, наскільки це можливо.
Бази даних
Ручне або автоматичне розгортання баз даних?
- гарантовану перевірку всіх імен баз даних (а не ідентифікаторів GUID в іменах баз даних);
- гарантовану перевірку розмірів баз даних;
- процедурне поділ управління середовищами додатків і даних.
Якщо необхідно створити бази даних вручну, а не автоматично, вам потрібно задіяти відповідні команди PowerShell для створення баз даних і реєстрації їх в SharePoint. Наприклад, ви можете використовувати таку команду PowerShell для створення нової конфігурації бази даних:
Цілісність даних
Ніщо не може зруйнувати репутацію сховища бізнес-даних швидше, ніж порушення цілісності даних. Оскільки адміністратор баз даних або системний адміністратор відповідальні за надійність платформи, необхідно розуміти процес порушення цілісності даних і знати, як ви можете виправити становище.
Захист даних - процес складний, особливо якщо безладні скачки напруги і відключення живлення викликають порушення роботи підсистеми вводу-виводу SQL Server в момент запису на диск. Руйнування даних часто є результатом саме цього, а без належних перевірок помилки прокрадутся в базу даних і будуть залишатися непоміченими, поки відповідно до закону Мерфі керівництву не знадобляться важливі дані.
Збій в базі даних може відбуватися в момент, коли на диску, на якому міститься файл журналу або файл даних, відбувається зміна даних. Такий тип збою проявляється в порушенні фізичної цілісності секторів диска через проблеми в підсистемах вводу-виводу пристроїв, таких як фізичний мережевий адаптер або дисковий накопичувач сам по собі.
Порушення фізичної цілісності даних, які відстежуються DBCC CHECKDB, вбудованою функцією SQL, зазвичай викликаються проблемами з обладнанням.
Порушення логічної цілісності викликаються даними, які були змінені некоректним способом, що призводить до порушення взаємозв'язку даних. Цей тип порушення зазвичай буває викликаний помилкою додатки або помилкою користувача і призводить до проблем з обробкою даних, але не впливає на фізичну структуру бази даних.
Практика показує, що команду DBCC CHECKDB слід запускати так само часто, як створювати повну копію бази даних. Команда DBCC CHECKDB виведе звіт про помилки, який ви зможете згодом вивчити.
Важливо відзначити, що команда DBCC CHECKDB не виконує перевірку на логічні порушення цілісності. Однак вона може викликати таке порушення, якщо використовується установка REPAIR_ALLOW_DATA_LOSS, оскільки в цьому випадку при відновленні після порушення фізичної цілісності не враховуються ніякі обмеження.
Що ж робити адміністратору баз даних? Коли команда DBCC CHECKDB повертається з повідомленнями про помилку, найкраще звернутися до резервних копій баз даних.
Однак це рішення вимагає наявності регулярно створюваних копій, які не повинні бути пошкоджені. Як згадувалося раніше, команда DBCC CHECKDB потенційно може викликати помилки, коли вона використовується для вирішення проблем цілісності. Без резервних копій не існує способу «вилікувати» дані в пошкодженій базі даних.
SharePoint - це складний додаток, яке покладається на багато інших інфраструктури, компоненти і серверні додатки. Неналежне обслуговування одного з цих рівнів може викликати проблеми і, можливо, навіть простий. На щастя, настройка SQL Server для оптимальної продуктивності не так вже складна. Покращення продуктивності SQL Server включають пару налаштувань конфігурації, належне розміщення файлів даних і журналів і перебудову табличних індексів час від часу.
Управління файлами бази даних
Коли справа доходить до управління файлами даних SQL Server, досвід показує, що файли даних і журнали повинні знаходитися кожен на своєму фізичному диску. Це більше ніж розміщення на різних томах диска. Рекомендація тут зводиться до наступного: помістити файли журналу та файли даних на різні диски і переконатися, що ніяке інше додаток не використовує їх. Дана схема мінімізує доступ на запис до дисків і зменшує можливості фрагментації файлу.
Вимірювання і зменшення фрагментації
Фрагментація даних всередині SQL Server може пояснюватися звичайними маніпуляціями з даними, включаючи вставку, зміна і видалення. Базовим симптомом фрагментації даних є збільшення вільного простору, відповідного обсягу даних. Справа в тому, що SQL Server зберігає дані як сторінку бази даних, яка містить деталі заголовка, деталі запису і індекс. Однак сторінка бази даних також налаштована відповідно до заповненням SQL Server так, щоб вона мала мінімальний розмір. Записи менші, ніж результат такого заповнення, призводять до великої кількості порожнього простору в таблиці. Системи SharePoint покладаються на ключі індексу, засновані на GUID, і внаслідок цього посилюють проблему, безладно вставляючи дані по всьому діапазону записів.
Підтримка поточної статистики
Коли SQL Server виконує запит, він обчислює і компілює план виконання. План виконання створюється Query Processor в SQL Server, і він визначає, які таблиці і індекси використовуються для досягнення оптимальної продуктивності. Метрики для визначення продуктивності запиту виводяться з статистики, яка допомагає SQL Server зрозуміти, як дані розподіляються всередині таблиці або індексу. Статистика збирається при різноманітних операціях читання, включаючи повне і зразкове сканування даних. Якщо ця статистика не актуальна в силу фрагментованих індексів, план виконання не буде таким ефективним, яким він міг би бути.
- аналіз індексів і визначення тих індексів, над якими потрібно працювати; як проводити усунення фрагментації;
- для всіх індексів, що не були перебудовані, оновити статистику;
- оновити статистику для всіх неіндексованих стовпців.
Визначення розмірів даних
Правильне визначення розмірів даних є важливою частиною впровадження SharePoint, оскільки розмір впливає на витрати, продуктивність і масштабованість всього програми. Для того щоб зрозуміти, як багато даних повинна вміщати в себе ваша середу SharePoint, потрібно подумати над загальною кількістю документів, кількістю версій кожного документа і середнім розміром кожного документа. Більш того, необхідно подумати над кількістю елементів списків, які будуть зберігатися в додатку. Microsoft пропонує формулу для визначення розмірів даних.
Хоча це обчислення дасть лише грубу оцінку обсягу зберігання, можна дещо зробити для того, щоб уточнити результат. Як згадувалося раніше, контент бази даних зберігається в сторінках бази даних, які мають постійний розмір завдяки заповненню. Регулювання коефіцієнта заповнення може вплинути на фрагментацію і загальний обсяг даних на диску. Зменшити розмір бази даних можна за допомогою DBCC SHRINKDATABASE, хоча Microsoft зараз дає деякі застереження щодо використання цієї функції. Нарешті, якщо перекладання обов'язків по зберіганню всіх даних в SQL Server призводить до великих витрат і перевантаження, ви можете наказати SharePoint використовувати файлову систему для зберігання великих бінарних об'єктів, BLOB.
Установка коефіцієнта заповнення на сервер
Змінюючи початкове значення FILLFACTOR за замовчуванням, адміністратор баз даних може зменшити фрагментацію і розбиття сторінок (симптом фрагментації, який впливає на продуктивність). Однак побічний ефект полягає в тому, що зайнято більше простору на диску, оскільки сторінки бази даних будуть об'ємніше. Під час регулярних операцій новий контент може бути вставлений в це вільний простір без запиту кластерного індексу для приєднання великої кількості даних. Кімберлі Тріпп ділиться досвідом обслуговування баз даних в своєму блозі на сайті www.sqlskills.com/BLOGS/KIMBERLY/post/Database-Maintenance-Best-Practices-Part-II-e28093-the-most-important-setting-FILLFACTOR.aspx.
Зменшення обсягу бази даних
Всі версії SQL Server, які підтримуються SharePoint, мають здатність зменшувати файли даних, що звільняє простір на диску. Жодна з баз даних в SharePoint не настроєна на автоматичне зменшення обсягу файлів даних. Наполеглива рекомендація від Microsoft і фахівців SQL Server полягає в тому, щоб не робити автоматичне зменшення бази даних або не виконувати планових операцій стиснення баз даних. Причина в тому, що зменшення бази даних ігнорує фактор заповнення і робить все індекси фрагментованими. Потім, коли ви запускаєте команду відновлення індексів, база даних досягає свого початкового розміру. Замість того щоб покладатися на команди DBCC_SHRINKDATABASE, які є в SQL Server, буде більш безпечно розбити бази даних чи знищити дані з існуючих баз даних. Нижче представлений список дій, які слід виконати для отримання вільного простору в середовищі SharePoint:
- використовувати STSADM MERGCONTENTSDB;
- видалити документи;
- видалити бібліотеки;
- видалити списки;
- видалити елементи списку;
- видалити сайти.
Віддалене сховище BLOB
Отже, оцініть свій контент для того щоб визначити, чи потрібно вам впроваджувати RBS. Рекомендація: ваші бази даних контенту повинні бути більше 500 Гбайт, а файли даних BLOB - більше 256 Кбайт. RBS покращують продуктивність систем, де є дуже об'ємні файли, але до них звертаються нечасто. Додавання RBS до вашого SharePoint може насправді уповільнити роботу користувачів.
Плани обслуговування бази даних
Майже всі завдання, які ви виконуєте за допомогою SQL Server, можуть бути автоматизовані. Ключовий пункт для будь-яких реалізацій SharePoint - це автоматизований план, який допоможе здійснювати обслуговування вашого сайту. Прослідкуйте, коли запускаються ці автоматизовані завдання, оскільки можна сповістити користувачів і спланувати більш повільну роботу системи в потрібний час, щоб підтримувати все в відмінному стані.
План обслуговування бази даних схожий на техобслуговування машини. Слід здійснювати цей процес за певною програмою для того, щоб SQL Server працював на оптимальному рівні, а веб-сайт - на максимумі продуктивності.
- Видалити зайву фрагментацію файлу журналу транзакцій за допомогою створення відповідної моделі відновлення і розкладу резервування.
- Виключіть будь-які планові операції по зменшенню обсягу бази даних, щоб знизити ризик непотрібної фрагментації індексу.
- Встановіть автоматичне збільшення бази даних коректно, використовуючи призначення розміру файлу, а не процентне співвідношення. Дотримуйтесь цього шляху, періодично перевіряючи розміри бази даних і визначаючи, чи потрібно задавати розмір вручну для досягнення оптимальної продуктивності.
- Увімкніть постійну ініціалізацію файлів, так щоб автоматичне збільшення бази даних виконувалось як миттєва операція, а не повільна операція, яка вимагає заповнення нулями вільного простору.
- Налагодьте регулярний процес для виявлення і видалення фрагментації індексу.
- Увімкніть налаштування AUTO_CREATE_STATISTICS і AUTO_UPDATE_STATISTICS і налагодьте регулярний процес оновлення статистики.
- Увімкніть контрольні суми сторінок.
- Запустіть регулярний процес DBCC CHECKDB.
Будь-адміністратор SharePoint повинен розуміти, що витратити деякий час на створення базового плану обслуговування означає гарантувати, що система запрацює добре. Це час окупиться продуктивністю, швидкістю і резервними копіями, якщо вони коли-небудь будуть потрібні.
Метт Ранлет ([email protected]) - консультант в компанії Intellinet з Атланти, має звання Microsoft MVP
Брендон Шварц ([email protected]) - старший консультант з Атланти, має звання Microsoft MVP
Поділіться матеріалом з колегами і друзями