What SQL DBAs need to know about SharePoint

  • 13,369 views
Uploaded on

 

More in: Technology
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
No Downloads

Views

Total Views
13,369
On Slideshare
0
From Embeds
0
Number of Embeds
3

Actions

Shares
Downloads
416
Comments
0
Likes
5

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide
  • LPiM = Lock Pages in Memory
  • LPiM = Lock Pages in Memory

Transcript

  • 1. What SQL DBAs need to know about SharePoint
    JD Wade, MCITP
    SharePoint Consultant
    Horizons Consulting
    Twitter: http://twitter.com/jdwade
    Blog: http://wadingthrough.com
  • 2. Why, oh why, oh why?
  • 3. Single Platform – Power and Challenge!
    Corporate
    Web
    Presence
    Single Business Productivity Platform leading to common:
    • End-user Experience
    • 4. Rich Integrated Capabilities
    • 5. Toolset and Development
    • 6. Deployment and Management
    Employee
    Portal
    Knowledge
    Management
    Portal
    Regulatory
    Compliance
    Repository
    Users
    Sales
    Division
    Portal
    Custom
    SAP
    Front-End
    Business
    Intelligence
    Dashboard
    R&D
    Community
    Geneva
    Office
    Site
    Extranet
    Collab
    Site
    Team “ABC”
    Site
    Project
    “X” Site
    Weekly
    Issue
    Tracking
    Meeting
    Corporate
    Teams
    Departments
    Empowerment
  • 7. SQL ImplementationCommonly Perceived Gaps
    SharePoint tables are too wide, wraps rows
    SharePoint manages its own (NVP) indexes
    SharePoint adds force-order, query hints
    Missing indexes for common operations
    Excessive use of Dynamic queries
    No SQL Referential Integrity OR key constraints
    DBCC with data loss not supported
    Missing integration of Back-up/Restore
  • 8. Why are DB Changes Not Supported?
    Single data platform for all workloads
    Workloads with conflicting platform needs
    Change for one may adversely affect another
    Upgrade and Servicing expects solid DB contract
    App logic is heavily dependent on DB specifics
    App enforces constraints and integrity!
    • Mostly Read
    • 9. Article Pages
    • 10. Search and structured queries
    Corp
    Web
    Presence
    Users
    • Read Writes
    • 11. Office Documents
    • 12. Organization and ad-hoc queries
    Team
    Collab Site
    Empowerment
  • 13. Storage
  • 14. Storage5 Key Points to Consider

    App Server
    App Server
    App Server
    SQL Server
    1
    HBA
    HBA
    2
    3
    4
    5
    tempdb tempdb T-log
    DB T-logs
    Content DBs
    Search DB
  • 15. StorageOptimizing SQL Server I/O Subsystem
    Ensure correct HBA driver and firmware versions
    Use SQLIO.exe to measure I/O performance
    Configure correct NTFS Allocation Unit Size
    64K best; default (4K) can result in a 30% perf hit
    To view: chkdsk <drive_letter>
    Ensure correct Windows “Sector Alignment”
    Incorrect setting can result in up to 50% perf hit
    Use diskpart to check and set alignment
    64K most common. Windows 2008 aligns sectors by default
    Free space on NTFS partition should be > 25%
  • 16. StorageDatabase Configuration
    Recommended database file placement
    priority (fastest to slowest drive)
    tempdb data and t-log files
    Db transaction log files
    Search db data files
    Content db data files
    In a heavily read-oriented portal site, prioritize data over logs.
    Place tempdb, Content db and t-logs on separate LUNs
    Use multiple data files for Content and Search dbs
    Distribute equi-sized data files across separate disks
    # of data files should be <= # of processor cores
    Multiple data files are not supported for other dbs
    Place SharePoint Search crawl and query processing tables on separate spindles
  • 17. StorageDatabase Sizing
    Site Collections > 15GB, use SQL Backups
    Limit Content DBs to 100 GB (soft limit)
    If larger consider differential backups using
    SQL or DPM
    Size SQL Server data files appropriately
    Pre-allocate data file to cover anticipated size of Content db
    Rely on SQL ‘Autogrow’ only as a catastrophic insurance policy
    Set SQL ‘Autogrow’ to fixed value appropriate for size of db
    Use dedicated database for large Site Collections (> 50GB)
    Configure tempdb data files = No of proc cores
    Configure tempdb to be at least 10% (25% preferred) of total Content db size, or the size of the largest table - whichever is greater
  • 18. Configuration
  • 19. ConfigurationTypical Deployment Sizes
  • 20. ConfigurationRecommended Capacities
  • 21. ConfigurationProcessors
    Deploy on 64-bit, especially if >1000 users, or >100 GB of data
    Use 64-bit SQL Server if using 64-bit OS
    IA-64 only supported on db tier, not on app tier
  • 22. Configuration Memory
    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 970315)
    CU4 for SQL Server 2005 SP3 (KBA 970279)
    * If NumOfProcessors > 4, else 0.
  • 23. Configuration
    Use SQL Server connection alias
    Simplifies redirecting WFEs to a different dbinstance
    Do not modify SPT schema
    No new columns or
    indexes permitted
    Use SharePoint tools
    to index columns
  • 24. Configuration
    Test use of MAXDOP = 1
    Separate instance for SharePoint Databases
    Set Fill Factor to 70
    SharePoint ignores Model Autogrow settings
  • 25. Maintenance
  • 26. Maintenance
    Monitor SQL Server performance regularly
    Check integrity of the database routinely
    DBCC CHECKDB
    Can use REPAIR_REBUILD option to fix errors (not always possible)
    REPAIR_ALLOW_DATA_LOSS not supported
    Time consuming operation, run during non-peak hours
    For very large DBs consider using option MAXDOP=1
    Defragment physical files
    Maintain farm account as DBO for moves/restores
  • 27. MaintenanceFragmentation
    Content and Search dbs most susceptible
    Rebuild / Reorganize indexes to eliminate fragmentation
    Reorganize index when fragmentation between 10-70%
    Rebuild index when fragmentation > 70%
    Existing index options used before the rebuild operation are not restored. Issue resolved in SQL Server 2005 SP2 and higher
    Use sys.dm_db_index_physical_stats to measure
    More accurate than DBCC SHOWCONTIG, often reports higher fragmentation numbers
    Auto-defrag only available in MOSS 2007 SP2 and for Content dbs but may need manual defragmentation
    Database Maintenance for SharePoint white paper
  • 28. MaintenanceShrinking Database Size
    Only shrink Content databases, not others
    Only perform if free space > 50% (after content reorg)
    Do not perform as part of maintenance plan
    Allocate 10-20% growth allowance when determining target size
  • 29. High Availability
    High availability options supported:
    Failover Clustering (local & stretch clusters)
    Database mirroring (Sync & Async)
    Log Shipping often used in conjunction to provide disaster recovery
  • 30. High AvailabilityDatabase Mirroring Configurations
    DB Mirroring within farm
    (Synchronous)
    DB Mirroring across farms
    (Asynchronous)
  • 31. High AvailabilityDatabase Mirroring
    Needs to be individually configured for each SPT db
    Requires Full Recovery model
    Both Synchronous and Asynchronous modes supported
    Synchronous DBM mode with witness server recommended for high availability
    Transfer SPT logins from Primary to Mirror server
    Script available in KBA 918992
    DB Mirroring SQL end-points should be encrypted when channel is not secured by other means
  • 32. High AvailabilityDatabase Mirroring
    Only supported on SQL Server Standard and Enterprise editions
    Standard edition only supports Synchronous mirroring
    On Standard edition 1 redo thread per db; on enterprise edition 1 redo thread per db per 4 cores
    Witness server can run on SQL Express
    Several improvements in SQL Server 2008 DBM
    Log stream compression
    Automatic Page Repair
    Pending send buffers limit increased from 3 to 64
  • 33. High AvailabilityAsynchronous Mirroring
    Asynchronous DBM can be used to provide redundancy for Content dbs across farms
    Does not guarantee consistency
    DBs that cannot be Async mirrored
    Configuration & Central Admin Content dbs
    Contain location specific references, must be rebuild at mirror site
    SSP dbs only if using Search
    Search requires sync between SSP dbs, Search db, and index (index file cannot be mirrored)
  • 34. Upcoming Attractions
  • 35. SQL 2008 R2SharePoint Integration
    Improved Reporting Services in SharePoint integrated mode
    Easier install
    Extract data from SharePoint 2007 or 2010 lists
    SSRS is reporting engine for SharePoint Access Services reporting
    PowerPivot for SharePoint
    “SSAS in SharePoint integrated mode”
  • 36. SharePoint 2010
    Support for RBS using SQL Filestream
    Restore items directly from SQL database
    AvePoint add-on
    Support for SQL Mirroring built-in
    Access Services
    PerformancePoint built-in
  • 37. Q & A
  • 38. Sources
    Primary slide content with modifications from:
    SharePoint Conference 2009SPC319: SQL Server Best Practices for SharePoint Deployments
    BurzinPatel, Senior Program ManagerMicrosoft Corporation
    Database Maintenance for SharePoint white paperhttp://technet.microsoft.com/en-us/library/cc262731.aspx