Mehta - SharePoint Data And Database Management
Download as PPT, PDF0 likes495 views
This document summarizes best practices for managing large SharePoint implementations, including organizing content databases, configuring SQL server drives, moving sites and databases, and avoiding corruption issues. The key recommendations are to plan database organization and growth needs in advance, distribute content across multiple databases for flexibility, and use proper commands like STSADM and renamesite to move sites and avoid reference issues that can lead to corruption.
![Questions? Thank you & best regards Nilesh Mehta NGenious Solutions, Inc. 1075 Easton Ave., Tower1, Suite #6 Somerset, NJ 08873 Ph: (732) 873-3385 Cell: (201) 230-7922 Fax: (413) 803-8749 E-mail: [email_address] URL: www.ngenioussolutions.com](https://image.slidesharecdn.com/mehtadataanddatabasemanagement-12554970361983-phpapp01/85/Mehta-SharePoint-Data-And-Database-Management-28-320.jpg)
Mehta - SharePoint Data And Database Management
- 1. Data & Database Management January 7 th , 2009 NYC SharePoint User Group Presenter: Nilesh Mehta – Sr. SharePoint Architect – NGenious Solutions, Inc.
- 2. SharePoint Training Project Server Training
- 3. Challenge: Managing Unexpected data Issues with SharePoint Number of SharePoint Sites Size of your SharePoint farm SharePoint Site Backup / Restores SharePoint Site Corruptions - especially with host header sites
- 4. Target Audience Mid-scale to large-scale SharePoint implementations Business / Platform Owners SharePoint Administrators SharePoint Developers Need to understand Production limitations
- 5. Agenda
- 6. Key messages to remember: Think and plan upfront: How big could your SharePoint environment be in the next two years? Organize your content databases for easy management, moving and restoring sites Prepare for potential site corruption: Don’t put too many eggs in one basket
- 7. Understanding your SharePoint Sites
- 8. SQL Server Configuration Deciding on the SQL Cluster Configuration Number of nodes in the Cluster Number of instances in the cluster Deciding drives per instance and drive size
- 9. SQL Server Configuration - Example Total data size = 1 TB 2 nodes in the Cluster Number of instances in the cluster = 1 Deciding drives per instance and drive size Drives: C: = OS D: = 250 GB (Data) E: = 250 GB (Data) F: = 250 GB (Data) G: = 250 GB (Data) H: = 500 GB (Log) I: = 1 TB (Backup) Drives: C: = OS D: = 500 GB (Data) E: = 500GB (Data) F: = 500 GB (Log) G: = 1 TB (Backup) Drives: C: = OS D: = 1 TB (Data) E: = 500 GB (Log) F: = 1 TB (Backup)
- 10. Organizing Content Databases at SharePoint Level Where is my site collection? How many sites in a content database?
- 11. Organizing Content Databases at SharePoint Level Number of sites in a content database Size of content databases Best Practices: Naming conventions for Content Database Setting maximum site count in Content Database Setting site quota on content database
- 12. Organizing Content Databases at SharePoint Level Collaboration Web Application: Target Content DB sizes around 100 GB for easier management @ 1 GB Quota = 100 Sites / Content DB. Lock Site Max @ 100 Sites Custom Content Databases for larger sites above 20 GB. Lock site maximum to single site Assigning Site Quota 500 Mb, 1 GB, 2GB, 5 GB or larger
- 13. Managing Corresponding Databases on SQL Server Sites increase, so does database Size Too many databases Usage increases, CPU & Memory Usage increases Get better performance by upgrading to 64-bit
- 14. Managing Corresponding Databases on SQL Server Consider 1 st Scenario in Drive Configuration: @ 1 GB quota & 100 sites, you can have a maximum of two Content DB’s / Drive Highly possible that some sites will need more than 1GB from these sites Drives: C: = OS D: = 250 GB (Data) – Collaboration Team sites E: = 250 GB (Data) – Collaboration Team sites F: = 250 GB (Data) – Portal sites G: = 250 GB (Data) – Application sites H: = 500 GB (Log) I: = 1 TB (Backup)
- 15. Managing Corresponding Databases on SQL Server Options: 1. Add extra drives to the SQL Server 2. Moving Databases between Drives: Detach database from SQL Server. Move database files as necessary on the same server Attach database back to SQL Server No issues from the SharePoint side. SharePoint auto-detects the databases Cons: You can only add so many drives and will soon run out of drives
- 16. Managing Corresponding Databases on SQL Server Consider 2 nd Scenario in Drive Configuration: @ 1 GB quota & 100 sites, you can have a maximum of four Content DB’s / Drive. Here you do have room to grow in some manner Tape backup of these drives take more time Drives: C: = OS D: = 500 GB (Data) – Collaboration Team Sites E: = 500GB (Data) – Portal and Application Team Sites F: = 500 GB (Log) G: = 1 TB (Backup)
- 17. Managing Corresponding Databases on SQL Server Data grows more than 1 TB: Add more drives to the same cluster instance Based on SQL Server performance, create another SQL Instance on passive node and add drives there Create a brand new Cluster and add drives there Restore sites from SQL backups: Need space to restore SQL backups – twice the size of the database
- 18. Managing Corresponding Databases on SQL Server Moving Databases across SQL Cluster: Perform full SQL Backups Perform stsadm –o preparetomove Perform stsadm –o detachcontentdb Copy SQL backup files to new cluster Attach content db’s to the new SQL Cluster Perform stsadm –o addcontentdb
- 19. Moving Sites across Web Applications / Content Databases : STSADM Backup Number of site collections increase Site collections need more space Options: STSADM Backup / restore – Best Solution for moving sites. Create a batch file for backups, deletes and restore. Dependency on local file system for backups. NOTE: Do not delete large sites from central administration. Always use STSADM utility
- 20. Moving Sites across Web Applications / Content Databases : Merge Content DB Merge Content Database Command good option for moving large number of sites, but has issues with Multi-Valued columns . It does not keep the values. Does not work across SQL Instances. Can move sites only in the same SQL Server Instance.
- 21. Moving Sites : Batch Site Manager Batch Site Manager – Another option to move sites from the Central Administration. Pros: Allows you to select which database to restore sites in. Works across clusters Cons – I have had very little success with this. Moved 5 sites and ended up with about 3 corrupt sites. Dependency on local file system disk space for backups and can cause corruption when you run out of disk space either on local server or SQL Server
- 22. Moving Sites: Batch Site Manager
- 23. Moving Sites: Batch Site Manager
- 24. Moving Sites: Batch Site Manager
- 25. Special – Managing Host Header Sites Syntax for creating Host Header Sites: Stsadm –o createsite –url http://abc.mycompany.com –ownerlogin –owneremail –sitetemplate –hhurl Possible corruption caused when moving host header sites from development to staging to production Example: Host Header Site in Development: http://devabc.mycompany.com Restore site in QA as http://qaabc.mycompany.com (Database keeps reference to devabc.mycompany.com) Restore site in Production as http://abc.mycompany.com (Database keeps reference to http://devabc.mycompany.com ) Imagine creating multiple sites based on same backup because you want to keep template. They all will have reference to http://devabc.mycompany.com When you perform content database detach / attach , configuration database does not know which site was which because they all have same Host Header column value
- 26. Special – Managing Host Header Sites, Avoiding Corruptions Avoiding corruption with Host Header Sites: When you restore site from Development to QA or Prod, restore with the same URL http://devabc.mycompany.com Once restored, perform stsadm –o renamesite command on this URL and it modifies the host header information in database properly Perform similar action if you have multiple sites coming in from same template
- 27. Key messages to remember: Think and plan upfront: How big could your SharePoint environment be in the next two years? Organize your content databases for easy moving, management and restoring Prepare for potential site corruption: Don’t put too many eggs in one basket
- 28. Questions? Thank you & best regards Nilesh Mehta NGenious Solutions, Inc. 1075 Easton Ave., Tower1, Suite #6 Somerset, NJ 08873 Ph: (732) 873-3385 Cell: (201) 230-7922 Fax: (413) 803-8749 E-mail: [email_address] URL: www.ngenioussolutions.com
Editor's Notes
- #7: Talk about our current environment issues – Number of sites in 2007 vs. sites in 2008, Data size, about having to clean up disk space weekly, shrink database, having to move sites from one database to another. Downtime for end users while we perform maintenance.
- #8: Collaboration Sites - # Team sites with regular site quota – Possibly in the 1000’s Portal Sites - Sites with Host Header URL or Large Content Size – Possibly about 25+ sites Application Sites - Custom Applications built on SharePoint or Dedicated web applications for specific client requirements
- #9: SQL Cluster Configuration – Deciding on the Server Hardware, Number of CPU’s, Memory, OS – 32-bit vs. 64-bit, Number of drives, Drive sizes, Number of nodes in the cluster, Active / Passive vs. Active / Active
- #12: Microsoft states keep content db’s around 25-30 GB. How real world is that? If you environment grows up to 1500 Sites at 1 GB / site, you can host about 25 – 30 sites per database. That means you will be hosting about 50 databases. When it comes to finding out which sites belonged to which content Database, you are going to have a really tough time finding that out. Especially if the site is deleted and needs to be restore, because SharePoint keeps no trace of the same, or if the site was moved from one DB to another and you need to restore a version from when it was in the original DB.
- #13: Talk about end user impact when you have to perform maintenance. Due to moving sites, corrupt sites? If you have more sites in the same database, when you bring it down you impact everyone. At less number of sites per content database, you can perform maintenance by impacting a smaller audience. Talk about pros and cons of setting really small site quota.
- #14: SQL Cluster Configuration – Deciding on the Server Hardware, Number of CPU’s, Memory, OS – 32-bit vs. 64-bit, Number of drives, Drive sizes, Number of nodes in the cluster, Active / Passive vs. Active / Active
- #20: CON: Only CON is you cannot select which database to restore site in. If you use CreateInDatabase argument, it creates a brand new database. NOTE: Do not delete large sites from Central administration. Often we have seen the Microsoft Wheel spinning when it tells us that it is doing something (and not showing verbose progress ) and then the process times out. With large sites, if the process times out, there are possibilities that it will leave corrupt sites behind.