Upload
jewel-chase
View
217
Download
0
Tags:
Embed Size (px)
Citation preview
Victor IsakovVictor Isakov is a Database Architect / Trainer / Author who provides consulting and training services to various organizations in the public, private and NGO sectors globally. He participates in different capacities at various international events and conferences. Victor specializes in:• Designing SQL Server infrastructure solutions and upgrade
strategies• Architecting OLTP, DSS and DW database solutions• Performance troubleshooting and optimization• Customized on-premise training and mentoring
Email [email protected]
Blog www.victorisakov.com
Twitter @victorisakov
LinkedIn www.linkedin.com/in/victorisakov
Website www.sqlserversolutions.com.au
AbstractThe performance, reliability and availability of your SharePoint farm depends on SQL Server. Therefore it is important for SharePoint Administrators to understand how to best configure and administer the SQL Server instances used by SharePoint. In this session Victor Isakov (MCA, MCM, MCT, MVP) will present on what SharePoint Admins should know about SQL Server so that they can maximize performance, minimize data loss and correctly administer SQL Server within their SharePoint farm.
Random Initial Thoughts…
• SharePoint does not defy the laws of physics, best practices or common sense• I’m sorry but it’s just like any other database… badly
designed • Actually I’m wrong here, there is some “weird stuff going”• Primarily because SQL Server release cadence not aligned
with SharePoint’s
• Lots of bad and outright weird advice out there• It’s often the basics that give you the best
performance
Initial Planning• The key to any successful project• I know of so many organizations that are up to their “third attempt in
deploy a SharePoint solution”
• Design includes, but is not limited to• Requirements Gathering• Capacity Planning• Defining Service Level Agreements (SLAs)• Availability
• Scoping hardware• Proof-of-Concept (POC)
• Always a good idea to understand the technology
Capacity Planning• Capacity planning goes a long way…• Hardware: processor, memory, storage• SQL Server / Windows Versions and Editions
• For most people this means working out how much storage capacity they need• Which is a good start• But storage is cheap…
• What you really want to know is what performance capacity you require
Performance Capacity Planning• Unfortunately this is a lot easier to talk
about than it is to actually determine• SharePoint view: RPS• SQL Server View: IOPs
• SQLIO• Capacity planning tool• At a basic level SQL Server performs I/O in 8KB and 64KB
• SQLIOSim• Not a performance capacity planning tool• It’s a storage validation tool
• Creating a baseline is important
Capacity Planning: Software Considerations• From SQL Server 2012 Microsoft has gone
to core-based licensing• Consider getting CPUs with less cores but that run at faster frequencies
• From SQL Server 2008 R2, Standard Edition only supports 64GB RAM• You can install multiple instances of SQL Server Standard Edition on
same server
• From Windows Server 2012, Standard Edition has no hardware limits• Deploy it!
Configuration• Try to develop a Standard Operating
Environment (SOE) for your SQL Server infrastructure• Basically every SQL Server is installed and configured exactly the same
way• Helps with administration• Helps with performance problems• Helps with troubleshooting
• A lot of advice in this talk can be used to develop your SOE
• Documentation is important• Build guides• “Run books”
SQL Server ConfigurationUser Rights
• Perform Volume Maintenance Tasks• Allows SQL Server to take advantage of “Instant File Initialization”• Certain file operations performed substantially faster, including:• Database creation• Database automatic growth
• Does not apply to transaction log
• Lock Pages in Memory (LPIM)• Prevents SQL Server’s buffer pool (BPool) from being paged out by Windows• Especially important where you might have following scenario:• Server used by both SQL Server and SharePoint services• SQL Server Standard Edition• Lots of RAM, let’s say 128GB• Generally also have to change ‘max server memory’
Storage ConfigurationBest Practices
• Pick the right hardware (HDD vs SSD vs PCeSSD)• Pick the right redundancy (RAID 1 vs 5 vs 6 vs
10 vs 60)• Format volumes dedicates to SQL Server
databases using 64KB• Make sure partitions are aligned• If you are using Windows 2012 I would highly
recommend you format volumes dedicated to storing SQL Server backups using ReFS (ReSilient File System)• SQL Server 2012 does not support ReFS for database files (data and logs)
SQL Server ConfigurationPower Plan
• Window’s default Power Plan is “Balanced”
• Not optimal for SQL Server
• Change to “High Performance”
SQL Server ConfigurationDatabase Engine
• maximum degree of parallelism (MAXDOP)• Set MAXDOP = 1• Required in SharePoint 2013
• maximum server memory (minimum server memory)• Good idea for various use cases:• Example: server with 192GB RAM
• blocked process threshold• Consider setting this to 10 seconds (or lower)• Your mileage will vary with this one
SQL Server Configurationtempdb
• Create multiple data files• Make sure each data file has a decent initial size• Make sure each data file has same autogrowth parameters• Prefer MB over percentage
• Only one log file is required• Sequential I/O • Give it a decent size
• Small – medium environment (4-16 cores)• Create 4 data files
• Larger environment (16+ cores)• Create 8 data files
SQL Server ConfigurationErrors Logs
• Change to 99• sp_cycle_errorlog
• Periodically process the error logs
• Good idea to archive them
Database MailAlerts / Job Execution
• It is extremely easy to set up email integration with SQL Server• SQL Server can email you when errors are occurring, jobs are
completing / failing
• Have a predefined set of alerts for every SQL Server instance• Fatal errors: severity level of 17 or greater• Database full• Better still: database 75% full
• Transaction log full• Better still transaction log 75% full
• Disk subsystem errors
SQL Agent ConfigurationHistory
• Remove size limit of job history log
• You will now need to monitor msdb system database
Database Best Practices• Separate database data files from
transaction log files• Better performance• Transaction logs use sequential I/O• Data files use mix of random and sequential I/O
• Better recoverability• If only the drive that stores the database’s data file crashes you still
should be able to restore your databases with no data loss• Need to back up the log-tail• Document this process• Practise this process
• DO NOT STORE BACKUPS & LOGS ON SAME DRIVE
Database Best Practices• Best to pre-allocate data file size• Have good auto-growth settings• Even more important for transaction log• Too many Virtual Log Files (VLFs) cause a myriad of problems• Occurs when transaction log grows many times using the default
auto-growth setting of 10%• Execute DBCC LOGINFO to determine number of VLFs
• Do not let the content database grow too big• Try to set some sort of a cap on the size as a corporate limit• Move site collections as required
Database Best Practices• Make sure you understand the different
RECOVERY models:• SIMPLE• BULK LOGGED• FULL
• Recovery model has serious implications• Recoverability (data loss)• High-Availability strategy
• Make sure you understand SharePoint’s defaults• Change accordingly
Database Maintenance• Important to perform the following tasks on
a regular basis• Reindexing tables and indexes• No need to update statistics
• Database consistency checks• Backups
• Do not shrink databases• Certainly not as a regularly schedule task• This kills performance as it heavily fragments the table / indexes
Reindexing• Over a period of time
the tables and indexes will get fragmented• Records deleted• Records inserts• Records updated
• Need to rebuild periodically• Online operation in Enterprise Edition• Rebuilding index UPDATE STATISTICS
• DO NOT SHRINK DATABASE
Database Consistency Checks• DBCC CHECKDB• Checks the logical & physical integrity of all database objects• No need to run CHECKALLOC, CHECKCATALOG, CHECKTABLE
• User databases• System databases• Online operation in Enterprise Edition*• Repair options are last resort• REPAIR_REBUILD• REPAIR_ALLOW_DATA_LOSS
Disaster Recovery• Define Recovery Time Objective (RTO)• Define Recovery Point Objective (RPO)• Backup system databases• Test your disaster recovery• Restore database backups to another SQL Server instance• Restore farm to another set of servers• Document process, times, etc• Refine
• Automated tasks require SQL Agent to be running
Availability• Often overlooked by organisations• Disaster Recovery NOT EQUAL TO High
Availability• Business should drive this:• How many 9’s do we require• long can we afford to have our main SharePoint farm offline?
• What technology should you use?• Virtualization platform• SQL Server’s built-in AlwaysOn technology
• But it involves more than technology• People, processes, education, documentation, etc
SQL Server AlwaysOn Technology• Failover Clustering• SQL Server 2005+ Standard Edition
• Availability Groups• SQL Server 2012+ Enterprise Edition
• Database Mirroring• SQL Server 2005+ Standard Edition• DEPRECATED
Complete your session evaluation onMyTechEd for your chance to win a Sculpt Bluetooth Mobile or Comfort Mouse.
Win a Sculpt Mouse
• Windows button provides one touch access to start screen
• Precision 4-way scrolling • Designed for comfort
Developer Network
Resources for Developers
http://msdn.microsoft.com/en-au/
Learning
Virtual Academy
http://www.microsoftvirtualacademy.com/
TechNet
Resources
Sessions on Demand
http://channel9.msdn.com/Events/TechEd/Australia/2013
Resources for IT Professionals
http://technet.microsoft.com/en-au/
© 2013 Microsoft Corporation. All rights reserved. Microsoft, Windows and other product names are or may be registered trademarks and/or trademarks in the U.S. and/or other countries.The information herein is for informational purposes only and represents the current view of Microsoft Corporation as of the date of this presentation. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information provided after the date of this presentation. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS PRESENTATION.