SQL Server для SharePoint 2010 Maxim Khlupnov; Рекомендации по настройке

Технологические Центры Microsoft (MTC) предоставляют уникальные возможности для проведения брифингов, семинаров и совместных работ по стратегическому планированию, проектированию, развертыванию, созданию и оптимизации решений для заказчиков Однодневное мероприятие, которое начинается с анализа текущего состояния ИТ-среды организации и ее бизнес-задач с последующим переходом к созданию демонстраций и сценариев, отражающих работу продуктов и технологий Microsoft для достижения целей и решения уникальных задач организации. Результат: Понимание возможностей и путей применения технологий. Продолжительность: 1 день Семинар по выработке архитектуры решения позволяет детально погрузиться в бизнес- процессы организации и соотнести их с конкретными приложениями платформы Microsoft и решениями партнеров, что поможет не только достичь поставленных целей, но и извлечь дополнительную выгоду из них. Результаты: Понимание, как конкретные бизнес-задачи могут быть решены с использованием технологий Microsoft и партнеров. Детальное планирование используемых технологий и концепция архитектуры. План проекта проверки концепции Proof-of- Concept Project Plan. Продолжительность: 1 – 3 days Архитекторы Microsoft работают в тесном сотрудничестве с техническими специалистами заказчика, передавая им необходимые знания и принимая участие в тестировании выбранных решений. Этот семинар может также включать подробные демонстрации и учебные занятия, на которых группа разработчиков со стороны заказчика получит их собственный безопасный и полностью укомплектованный набор средств разработки приложений, который был предварительно настроен специалистами Microsoft. Результаты: Снижение рисков про реализации проекта. Продолжительность: 2 – 3 weeks Видение БРИФИНГ ПО РАЗРАБОТКЕ СТРАТЕГИИ Видение концепции и технологий. Архитектура СЕМИНАР ПО ВЫРАБОТКЕ АРХИТЕКТУРЫ Проработка деталей. Проверка СЕМИНАР ПО ПРОВЕРКЕ ПРАВИЛЬНОСТИ КОНЦЕПЦИИ Разрешение сомнений.

О чем пойдет речь Редакции SQL Server для SharePoint Архитектура и аппаратные требования Конфигурации SQL Server Развертывание баз данных SharePoint Обслуживание баз данных SharePoint

Редакции SQL Server для SharePoint SQL Server Best Practices for SharePoint

us/library/cc298801(office.14).aspx SQL 2008 R2 EESQL 2008 R2 SESQL 2008 EESQL 2008 SESQL 2005 EESQL 2005 SE SharePoint 2007 (SharePoint SP1 needed) 64bit rec. 64bit rec. SQL SP2 rec. 64bit rec. SQL SP2 rec. SharePoint bit only SQL SP2 rec. 64bit only SQL SP2 rec. 64bit only SQL SP3 CU3 required 64bit only SQL SP3 CU3 required SharePoint 2010 with Remote Blob Store X (addin from Feature Pack SQL Server 2008 R2 needed) SharePoint 2010 Filestream Provider local Storage XXXX PowerPivot in SharePoint X (for FrontEnd) Backup Compression XXX Table Compression for Search DB XX Transparent Database Encryption XX Resource Governor XX Database Auditing XX Access Services (Connected Mode) XX Access Services (local Mode) requires SSRS 2008 R2 Add-in XXXXXX Reporting Server Integration X (for Scaleout)X X X DB Server on a cluster X (faster recovery)2Nodes onlyX (faster recovery)2Nodes onlyX (faster recovery2Nodes only Faster Failover with DB Mirroring + async XXX Read Only Content DBs with SQL Server Snapshots XXX

Архитектура и аппаратные требования SQL Server Best Practices for SharePoint

Ограничения продукта Жесткие ограничения отсутствую Рекомендации и ограничения от WFEs на 1 экземпляр SQL Server до 5,000 коллекций узлов на content DB (лучше > 2,000) до 4 TB данных в content DB до 60 млн. документов (элементов списка) в content DB Отклик сети между WFE и SQL серверами не более чем 1 миллисекунда (ms.) Для RBS время получения первого байта данных файла с NAS не более 20 ms. Тесты SharePoint показали, что скорость работы не изменяется при линейном увеличении content DB;

Хранилище 5 мест на которые нужно обратить внимание HBA SQL Server HBA tempdb tempdb T-log DB T-logsContent DBsSearch DB App Server … NIC

Хранилище Рекомендуемая пропускная способность Type RAID LevelIOPSSAN Optimization tempdbRAID-102 IOPS/GBWrite optimized Transaction LogsRAID-102 IOPS/GBWrite optimized Search DatabaseRAID-10 2 IOPS/GBRead/Write optimized Content DatabasesRAID-10*0.75 IOPS/GBRead optimized * Raid-5 может использоваться только для статического содержимого Производительность дисков sec/transfer Файлы Data < 10 msec Файлы T-log < 5 msec

Хранилище Рекомендации по настройке дисковой подсистемы Обновить прошивки HBA, NIC, сервера Используйте SQLIO.exe для измерения производительности I/O Настроить правильный размер NTFS Allocation Unit Лучше 64K; по умолчанию (4K) может повлечь потерю 30% производительности) Чтобы посмотреть: chkdsk Чтобы задать: format E: /Q /FS:NTFS /A:64K /V:Data1 /Y Убедиться, что сектора выровнены Sector Alignment Неправильные настройки - потеря производительности до 50% 64K наиболее частая настройка. Windows 2008 выравнивает автоматически Whitepaper SQL CAT – Disk alignment Best Practices

Хранилище Размеры БД Если размер превышает 100 GB использовать SQL или DPM для резервного копирования Заранее увеличивайте размеры файлов SQL Server Предотвращает замедление в работе (увеличение Content db) SQL Autogrow только в случае ошибок Лучше установить значение Autogrow в фиксированное значение Для больших коллекций - выделенные БД (> 50GB) Число файлов tempdb = числу ядер процессора Размер tempdb не менее 10% от размера Content db, [MAX DB SIZE (KB)] X [.25] / [# CORES] = DATA FILE SIZE (KB)

Типовые размеры фермы MetricSmallMediumLarge Content db size< 50GB50GB> 50GB # of Content dbs< 2020> 20 # of concurrent requests to SQL< > 200 # of Users< > 1000 # of items in regularly accessed list< > 2000 # of columns in regularly accessed list < 2020> 20

Параметры конфигурации РесурсМалаяСредняяБольшая Recommended DB server memory8 GB +16 GB +32 GB + Processor L2 cache2 MB> 2 MB Bus bandwidthMediumHigh Disks latencies (msec)< 20< 10 < 10 (data) < 5 (T-log) NetworkGigabit Network latency (msec)< 1

Процессоры SQL Server 64-bit как требование для SharePoint 2010 Как рекомендация для SharePoint 2007 Минимум 8 процессорных ядер Не менее 1 ядра процессора на 20тыс. пользователей Масштабирование до 8 процессоров

Память Set Max Server Memory SQL Max Memory = TotalPhyMem - (NumOfSQLThreads * ThreadStackSize) - (1GB * CEILING(NumOfCores/4)) - (Any mem required for other apps) NumOfSQLThreads=256 + (NumOfProcessors * - 4) * 8 ThreadStackSize=1 MB on x86 2 MB on 64-bit (x64) 4 MB on 64-bit (IA64) On 64-bit use LPiM privilege for SQL Server account If using SQL Std edition need following CU + trace flag CU2 for SQL Server 2008 SP1 (KBA ) CU4 for SQL Server 2005 SP3 (KBA ) * If NumOfProcessors > 4, else 0.

SQL Server MAXDOP Set SQL Server Max Degree of Parallelism to 1

Configuring Content Databases Choosing the correct recovery model Only use Full recovery model if you: Implement a backup strategy that includes regular (e.g. hourly) backups of the transaction logs Use a High Availability configuration, such as Log Shipping or Database Mirroring There is no point in using Bulk-Logged as SharePoint code does not contain any BULK INSERT or SELECT INTO statements Otherwise use Simple to facilitate manageability Configure the model database accordingly to avoid having to change the options of each new database after it was created Do not change any Auto Setting!

Content Databases - Continued Pre-construct and pre-size Script generation of empty database objects Autogrow feature on for safety Use RAID 5 or RAID 10 logical units RAID 10 is the best choice when cost is not a concern RAID 5 will be sufficient and will save on costs, since content databases tend to be more read intensive than write intensive Multi-core computer running SQL Server Primary file group should consist one File per CPU Core Best Practices is to use an additional file group with one File per CPU Core, but its easier to manage a database with one filegroup

Search Database Pre-construct and pre-size Script generation of empty database objects Autogrow feature on for safety Use RAID 10 logical units Should be a requirement for large-scale systems Multi-core computer running SQL Server Primary file group with x Datafiles

Search Database - continued Search database is VERY read/write intensive! Do not place any other database data files on any logical unit where search database files reside Place the search database log files on an independent logical unit Place SharePoint 2007 Search crawl and query processing tables on separate spindles

SQL Server Best Practices for SharePoint

Maintenance General Considerations Database Maintenance SQL Server 2005 SP2 is needed if using the DB maintenance wizard (KB930887) SQL Server is out of mainstream support! Physical Volume File Fragmentation: IS NOT NEEDED If you work with best practices like presizing and good grow increments Read the new Guide Database Maintenance for Microsoft SharePoint 2010 Products yID=246DBCA0-F03C-4DFF-A1B9- F510F7FC8A6A&amp;amp;displaylang=ehttp:// yID=246DBCA0-F03C-4DFF-A1B9- F510F7FC8A6A&amp;amp;displaylang=e

Databases Maintenance Dos Have reliable backups for all databases before implementing maintenance operations Check for and repair consistency errors by using DBCC CHECKDB Defragment indexes by either reorganizing them or rebuilding them, or use the dbo.proc_DefragIndexes procedure Change the server-wide fill factor setting to 80 Update statistics In a managed environment use standardized scripts for all databases and disable SharePoint Health Analyzer Rules

Databases Maintenance Don'ts Drop and re-create indexes Rebuild indexes or run consistency checks during business hours Set fill factor for individual tables or indexes Shrink any databases other than content databases Auto-shrink databases Shrink databases at all unless you really need to DBCC Checkdb REPAIR_ALLOW_DATA_LOSS not supported (REPAIR_REBUILD supported, but not always possible)

Index Defrag Fragmentation occurs by design on SharePoint ;-) Clustered Indexes (PK) on GUID Columns Increase space utilization & I/O degrades performance Content and Search dbs most susceptible Rebuild / Reorganize indexes to eliminate fragmentation Reorganize index when fragmentation between 10-30% Rebuild index when fragmentation > 30% Use sys.dm_db_index_physical_stats to measure

Changes to SharePoint Databases not supported Adding database triggers Adding new indexes or changing existing indexes within tables Adding, changing, or deleting any primary or foreign key relationships Changing or deleting existing stored procedures Calling existing stored procedures directly Adding new stored procedures Adding, changing, or deleting any data in any table of any of the databases Adding, changing, or deleting any columns in any table of any of the databasesMaking any modification to the database schema Adding tables to any of the databases Changing the database collation Running DBCC_CHECKDB WITH REPAIR_ALLOW_DATA_LOSS (However, running DBCC_CHECKDB WITH REPAIR_FAST and REPAIR_REBUILD is supported, as these commands only update the indexes of the associated database.) Technet: KB:

Спасибо за внимание! Вопросы…