Transcript Sql Server для SharePoint best practice

SQL Server для SharePoint 2010
Рекомендации по настройке
Maxim Khlupnov; [email protected]
Технологические Центры Microsoft (MTC)
предоставляют уникальные возможности для проведения брифингов, семинаров
и совместных работ по стратегическому планированию, проектированию,
развертыванию, созданию и оптимизации решений для заказчиков
Видение
БРИФИНГ ПО РАЗРАБОТКЕ
СТРАТЕГИИ
Видение концепции и технологий.
Однодневное мероприятие, которое
начинается с анализа текущего состояния
ИТ-среды организации и ее бизнес-задач с
последующим переходом к созданию
демонстраций и сценариев, отражающих
работу продуктов и технологий Microsoft для
достижения целей и решения уникальных
задач организации.
Результат: Понимание возможностей и
путей применения технологий.
Продолжительность: 1 день
Архитектура
СЕМИНАР ПО ВЫРАБОТКЕ
АРХИТЕКТУРЫ
Проработка деталей.
Семинар по выработке архитектуры решения
позволяет детально погрузиться в бизнеспроцессы организации и соотнести их с
конкретными приложениями платформы Microsoft
и решениями партнеров, что поможет не только
достичь поставленных целей, но и извлечь
дополнительную выгоду из них.
Результаты:
•Понимание, как конкретные бизнес-задачи могут
быть решены с использованием технологий
Microsoft и партнеров.
•Детальное планирование используемых
технологий и концепция архитектуры.
•План проекта проверки концепции Proof-ofConcept 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
SQL 2008 R2 EE
SQL 2008 R2 SE
SharePoint 2007
64bit only
SQL 2008 EE
SQL 2008 SE
SQL 2005 EE
SQL 2005 SE
(SharePoint SP1
needed) 64bit rec.
(SharePoint SP1
needed) 64bit rec.
64bit rec.
SQL SP2 rec.
64bit rec.
SQL SP2 rec.
64bit only
SQL SP2 rec.
64bit only
SQL SP2 rec.
64bit only
SQL SP3 CU3
required
64bit only
SQL SP3 CU3
required
SharePoint 2010
64bit only
SharePoint 2010 with
Remote Blob Store
X (addin from Feature
Pack SQL Server 2008
R2 needed)
SharePoint 2010
Filestream Provider
local Storage
X
PowerPivot in
SharePoint
X (for FrontEnd)
Backup Compression
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
X (addin from Feature
Pack SQL Server
2008 R2 needed)
X
X
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 мест на которые нужно обратить внимание
1
NIC
…
App Server
App Server
2
3
App Server
SQL Server
HBA
HBA
4
5
6
tempdb
tempdb T-log
DB T-logs
Content DBs
Search DB
Хранилище
Рекомендуемая пропускная способность
• Производительность дисков sec/transfer
− Файлы Data < 10 msec
− Файлы T-log < 5 msec
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 может использоваться только для статического содержимого
Хранилище
Рекомендации по настройке дисковой подсистемы
• Обновить прошивки 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
Processor L2 cache
Bus bandwidth
Disks latencies (msec)
Network
Network latency (msec)
Малая
Средняя
Большая
8 GB +
16 GB +
32 GB +
2 MB
> 2 MB
> 2MB
Medium
High
High
< 20
< 10
< 10 (data)
< 5 (T-log)
Gigabit
Gigabit
Gigabit
<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 =
ThreadStackSize
=
256 + (NumOfProcessors*- 4) * 8
1 MB on x86
2 MB on 64-bit (x64)
4 MB on 64-bit (IA64)
* If NumOfProcessors > 4, else 0.
• 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)
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
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?Famil
yID=246DBCA0-F03C-4DFF-A1B9F510F7FC8A6A&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
Спасибо за внимание!
Вопросы…