SQL Server для SharePoint 2010

Maxim Khlupnov; makhlu@microsoft.com

Рекомендации по настройке

Технологические Центры 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

http://technet.microsoft.com/en-us/library/cc298801(office.14).aspx

SQL 2008 R2 EE SQL 2008 R2 SE SQL 2008 EE SQL 2008 SE SQL 2005 EE SQL 2005 SE

SharePoint 2007 (SharePoint SP1 needed) 64bit rec.

(SharePoint SP1 needed) 64bit rec.

64bit rec.SQL SP2 rec.

64bit rec.SQL SP2 rec.

SharePoint 2010 64bit only 64bit only 64bit onlySQL SP2 rec.

64bit onlySQL SP2 rec.

64bit onlySQL SP3 CU3 required

64bit onlySQL SP3 CU3 required

SharePoint 2010 with Remote Blob Store

X (addin from Feature Pack SQL Server 2008 R2 needed)

X (addin from Feature Pack SQL Server 2008 R2 needed)

SharePoint 2010 Filestream Provider local Storage

X X X X

PowerPivot in SharePoint

X (for FrontEnd)

Backup Compression X X X

Table Compression for Search DB

X X

Transparent Database Encryption

X X

Resource Governor X X

Database Auditing X X

Access Services (Connected Mode)

X X

Access Services (local Mode) requires SSRS 2008 R2 Add-in

X X X X X X

Reporting Server Integration

X (for Scaleout) X X (for Scaleout) X X (for Scaleout) X

DB Server on a cluster

X (faster recovery) 2Nodes only X (faster recovery) 2Nodes only X (faster recovery 2Nodes only

Faster Failover with DB Mirroring + async

X X X

Read Only Content DBs with SQL Server Snapshots

X X X

Архитектура и аппаратные требования

SQL Server Best Practices for SharePoint

Ограничения продукта• Жесткие ограничения отсутствую• Рекомендации и ограничения от 14.07.2011

− 8 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 ServerHBA

tempdb tempdb T-log

DB T-logs Content DBs Search DB

App Server App Server App Server…NIC

1

3

4

56

2

ХранилищеРекомендуемая пропускная способность

Type RAID Level IOPS SAN Optimization

tempdb RAID-10 2 IOPS/GB Write optimized

Transaction Logs RAID-10 2 IOPS/GB Write optimized

Search Database RAID-10  2 IOPS/GB Read/Write optimized

Content Databases RAID-10* 0.75 IOPS/GB Read 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 <drive_letter>• Чтобы задать: format E: /Q /FS:NTFS /A:64K /V:Data1 /Y

• Убедиться, что сектора выровнены “Sector Alignment”• Неправильные настройки - потеря производительности до 50%• 64K наиболее частая настройка. Windows 2008 выравнивает

автоматически• Whitepaper SQL CAT – Disk alignment Best Practices

• http://msdn.microsoft.com/en-us/library/dd758814.aspx

Хранилище Размеры БД

• Если размер превышает 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)

Типовые размеры фермы

Metric Small Medium Large

Content db size < 50GB 50GB > 50GB

# of Content dbs < 20 20 > 20

# of concurrent requests to SQL < 200 200 > 200

# of Users < 1000 1000 > 1000

# of items in regularly accessed list < 2000 2000 > 2000

# of columns in regularly accessed list < 20 20 > 20

Параметры конфигурацииРесурс Малая Средняя Большая

Recommended DB server memory 8 GB + 16 GB + 32 GB +

Processor L2 cache 2 MB > 2 MB > 2MB

Bus bandwidth Medium High High

Disks latencies (msec) < 20 < 10 < 10 (data)< 5 (T-log)

Network Gigabit Gigabit Gigabit

Network latency (msec) < 1 < 1 < 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 x862 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 970315)• CU4 for SQL Server 2005 SP3 (KBA 970279)

* 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 it’s 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−http://go.microsoft.com/fwlink/?LinkId=132066

SharePoint Database Maintenance

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−http://

www.microsoft.com/downloads/details.aspx?FamilyID=246DBCA0-F03C-4DFF-A1B9-F510F7FC8A6A&amp;amp;displaylang=e

Databases Maintenance• Do’s

− 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• http://support.microsoft.com/kb/943345/

− 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: http://msdn.microsoft.com/en-us/library/dd587585(office.11).aspx• KB: http://support.microsoft.com/kb/841057

Спасибо за внимание!

Вопросы…