sql server для sharepoint 2010 maxim khlupnov; [email protected]@microsoft.com...
TRANSCRIPT
Технологические Центры 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;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
Спасибо за внимание!
Вопросы…