Sizing Your Content Databases- Understanding The Limits

583 views

Published on

Pre

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
583
On SlideShare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
11
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide
  • Introduce concept of documents being stored as BLOBs in CDBBUILD: Diagram of architectureDiscuss storage growthBUILD: Bloat of data, mostly inactiveBUILD: Burden on CDBsDiscuss need to thin about storage holistically: lifecycle, compliance, SLAs, cost
  • v4iMMm
  • Sizing Your Content Databases- Understanding The Limits

    1. 1. Sizing your content databases Understanding the limits
    2. 2. Randy Williams • Enterprise Trainer & Evangelist • Based in San Diego, CA • SharePoint MVP alum (2009 – 2011) • Speaker at many global conferences• 20+ years in IT ● Developer, consultant, trainer, author• Columnist: SharePoint Pro magazine• randy.williams@avepoint.com• @tweetraw
    3. 3. Agenda Understanding Remote BLOB new limits storage (RBS) 1 2 Achieving 3 4 Summary larger Q&A capacities
    4. 4. Agenda Understanding new limits 1
    5. 5. The SharePoint storage dilemma• Documents, databases, and BLOBs• Storage growth SharePoint SQL Server 2008/R2 Content Database Content Content Database Database Active Content Actual Content
    6. 6. Previously supported limits Large, single -site repositories 1 TB and archives General use (records 200 GB scenarios center) 100 GB site collection ** A larger site collection is supported if itis the only site collection in the database
    7. 7. Revised limits (July ‘11) Document No archive explicit scenario: All scenarios: limit caveats 4 TB caveats apply General use apply200 GB scenarios Site collection No explicit size – limit by scenario, database size, item count
    8. 8. Understanding scenarios• SharePoint is multi-purpose• Scenario primarily refers to needs and usage patterns ● Read/write centric ● Concurrent users ● Average/peak loads ● Recovery objectives• Isolate different usage patterns to separate databases
    9. 9. Common scenariosRecord Center Team Site• Long term retention • Day to day collaboration• Low volatility – few write w/ shorter retention operations • Heavy read and write• Very limited reads operationsLarger databases Smaller databases
    10. 10. What are the 4TB-level caveats? • A larger db requires faster storage ● Between 0.25 – 2.0 IOPS/GB ● 4TB DB : 1000 IOPS minimum • Plans developed for DR/HA • Capacity planning/perf testing • Recognize added complexity ● Skilled architects and proactive admins • 60M total item limit per dbhttp://technet.microsoft.com/en-us/library/cc262787.aspx
    11. 11. What are the >4TB caveats? • All 4TB caveats, plus • Document Center or Record Center only • In any given month ● <5% of content accessed ● <1% of content modified • No alerts, user workflow, item-level security, et alhttp://technet.microsoft.com/en-us/library/cc262787.aspx
    12. 12. Why is 200GB still a good target?• Support operations are much easier• Better performance ● The larger the db, the slower it gets• Easier to meet backup and recovery objectives ● Most recoveries begin with a db restore ● Can you meet your recovery objectives?• Patching / upgrading is faster 200 GB
    13. 13. Book giveaway• What is the maximum number of items that can be stored in a single content database?
    14. 14. Why are larger DBs slower?• Read queries take longer ● More rows to filter, group and sort• Write queries take longer• Increased lock contention ● Causes more blocking• More data, but data cache same size• DB maintenance takes longer ● reindex ● dbcc checkdb
    15. 15. What happens as size increases?http://technet.microsoft.com/en-us/library/hh395916.aspx
    16. 16. DemoSIZE AFFECTS PERFORMANCE
    17. 17. Agenda 2 Achieving larger capacities
    18. 18. Achieving storage performance• Storage array (RAID 1+0) ● 10 300GB SAS drives, 15k RPM ● 1.5 TB effective space ● ~1500 IOPS = 1.0 IOPS/GB• Set of drives (RAID 1+0) ● 4 750GB SATA drives, 10k RPM ● 1.5 TB effective space ● ~300 IOPS = 0.2 IOPS/GB• Go with higher quality storage ● SAS > SATA ; SAN > DAS
    19. 19. Scaling storage• Multiple storage arrays (RAID 1+0)• Break out into multiple LUNs• Add additional data files to DB, one per array F:SP_DocCenter_1.mdf• Advice G: SP_DocCenter_2.ndf Data ● Many smaller drives > H: SP_DocCenter_3.ndf I: SP_DocCenter_4.ndf fewer larger ones J: SP_DocCenter.ldf Log ● RAID 1+0 > RAID 5
    20. 20. Additional performance guidance • How many data files? ● Advice varies – between 0.25 to 1 per physical CPU ● Each on a different spindle/LUN • Adjust database growth settings ● Use 50-100MB for each data file ● Use 20-40MB for log • Enable instant file initialization • Optimize tempdb ● Use multiple data files ● Pre-size to 25% of largest db ● RAID 1+0http://slidesha.re/pwVlJM
    21. 21. Demo (if time permits)DB SETTINGS AFFECTPERFORMANCE
    22. 22. Achieving Recovery Objectives • Built-in SharePoint backup is incapable of working with large capacities ● Site collection backup limit : 15GB ● Practical database backup limit : 200GB • Look at your backup/recovery objectives ● Most recoveries involve a database restore • Deploy SP1 – site recycle bin • Look for third-party solutionshttp://slidesha.re/rlv3u1
    23. 23. Agenda Remote BLOB storage (RBS) 3
    24. 24. Remote BLOB Storage (RBS)• Storing document (BLOB) outside database• Cannot be used to scale beyond database limits ● Effective size = DB size + BLOB store• Can externalize based on document size• Built in RBS support with SQL Server 2008 (FILESTREAM provider)
    25. 25. Overview of BLOB externalization Pointer (stub) RBS Upload SQL Server Web Front-endExternalized BLOB istransparent to both File SystemSharePoint and its users
    26. 26. Advantages of externalizing BLOBs• Reduce storage costs• Increase performance ● Read & write of BLOBs ● All other database activities• Access to features of BLOB storage platform• Efficient content restructure ● Shallow copy in SP1
    27. 27. Advantages of keeping BLOBs inSQL• One storage container to ● Maintain ● Monitor ● Recover• Tier I storage ● Performance relative to lower tiers of storage benefits all content access• SQL caching ● Performance of reads/writes of small documents ● SQL caching benefits reads
    28. 28. RBS Guidance • Consider using in document-heavy databases • Trade off ● Storage cost & performance benefits versus ● More complex architecture (support, DR, HA) • Consider third party providers ● More full-featured solutions • In general ● Do not externalize documents <1MB ● Ideal number varies widelyFor more, see bit.ly/v4iMMm
    29. 29. Book giveaway• What is the SQL Server command that checks for database corruption?
    30. 30. Agenda 4 Summary Q&A
    31. 31. In review• 4TB is the new supported limit for all scenarios• No limit for record/document centers• Keys to achieving larger sizes ● Storage performance planning/testing ● DR/HA planning/testing• RBS offers benefits but does not extend these limits
    32. 32. Questions? randy.williams@avepoint.com http://linkd.in/plEEb1 @tweetraw
    33. 33. Victory Lap- social event "SharePoint Victory Lap" Social Event for SPSLA will be at: 5:30pm to 8pm atDi Piazzas (5205 E. Pacific Coast Hwy, 90804)
    34. 34. We want your feedback! Use this QR code or visit: http://sps.la/feedback Silver Sponsors:

    ×