If you are an DBA or and Systems Administrator at an organisation where SharePoint has been deployed you may wonder why it needs so many databases. This session covers what these are and what you should be doing to look after them. This session will outline the SharePoint 2010 architecture and what planning you'll need to do to keep SharePoint performing by ensuring that your exsisting SQL server deployments can cope with SharePoint demands.

1. Chandima Kulathilake
MCTS/MVP (SharePoint)
www.chandima.net/blog
www.knowledgecue.com

2. Chandima – aka “Chan” @chandimak on
twitter
Solutions Architect @ Knowledge Cue
- SharePoint Consulting in New Zealand
Started with SharePoint 2001... It‟s been
a great journey 
SharePoint MVP since 2007
www.chandima.net/blog
chan@knowledgecue.com

3. Help with strategy and planning for
SharePoint
Sense making for large enterprise projects
Pre RFP stage expectation setting
SharePoint best practices/ “real world”
balancing act
Consulting and deployment support
Microsoft certified SharePoint experts
@knowledgecue on twitter
www.knowledgecue.co.nz

4. Introduction to SharePoint 2010
Introduction to how SharePoint uses SQL
Planning for the SQL databases
SP2010 Deployment Planning Guidelines

5. SharePoint Server 2010
64-bit only
Requires 64-bit Windows Server 2008 or
64-bit Windows Server 2008 R2
Requires 64-bit SQL Server 2008 SP1 or
SQL Server 2008R2
SQL Server 2005 + SP3 and CU (64bit)
http://tinyurl.com/SPSysReq

6. WFE – Some changes, mostly optimization
App Server – Many changes
SQL – Some changes, heavy optimization
Web Tier
Application Tier
SQL Tier
Sum total is:
Architecture is familiar, but there are many more
design choices now
2010 is far more flexible than 2007 (yet complex)

7. User Excel
Access Services Search
Profiles Calc
Business Data Catalog
Excel Services BDC
Managed Metadata Service Visio
People WAC
3rd
Search Service Application party
Service
Secure Store Service
State Service
Usage and Health data collection
http://itweb/
http://hrweb/
Visio Graphics Service
Web Analytics Service Application
Word Conversion Service Application

8. No longer a separate SSP web site
SA‟s managed via central admin
Pick and choose your service apps (SA)
If you don‟t need a service app, don‟t add it
Web apps can consume SAs on an
individual basis
Each web app can use any combination of all available
SA‟s
Deploy multiple instances of the same SA
Just give each one a unique name
Reuse SA instances across multiple web
apps in farm

9. User User Excel
Search Calc
Search Profiles Profiles
SSP
BCS
Excel Visio
BDC
Calc
WAC
3rd party
Service
http://itweb/
http://hrweb/ http://itweb/ http://hrweb/
Corp Farm Corp Farm
MOSS 2007 Model SP2010 Model

10. Enterprise
FAST Search Visio Graphics
Search
Performance
Word Automation Web Analytics Access Services
Point
Functional Services
Business Data
Office Web Apps Excel Services User Profiles
Connectivity
Structural Services
App Discovery
Managed
and Load Security Token Secure Store
Metadata
Balancing
Foundation Services

11. Service Applications with their own DB:
Search (3)
User Profile (3)
Managed Metadata
Secure Store
State Service (2*) aspnet_sessiondb
Business Data Connectivity
Web Analytics (2)
Performance Point
Usage and Health data collection
Word Automation

12. Service Application Database * Relative Size
Usage and Health Data Collection Service Application Usage Extra Large
Business Data Connectivity (BCS) Service Application Business Data Connectivity Small
Application Registry Service Application Application Registry Small
SharePoint Foundation Subscription Settings Service Subscription Settings Small
Search Service Application Search Administration Medium
Search Service Application Crawl Extra Large
Search Service Application Property Large > Extra
Large
Web Analytics Service Application Reporting Extra Large
Web Analytics Service Application Staging Medium
State Service Application, Visio Service Application, InfoPath State Medium > Large
Forms Services
User Profile Service Application Profile Medium > Large
User Profile Service Application Synchronization Medium > Large
User Profile Service Application Social Tagging Small > Extra
Large
Managed Metadata Service Application Managed Metadata Medium
Secure Store Service Application Secure Store Small
Word Automation Service Application Word Automation Services Small
PerformancePoint Service Application PerformancePoint Small

13. Many more databases to manage
Most service applications will have their own database
People service has 3, Search can have multiple crawl and
property store databases
Snapshot management
You can force snapshots during backup
Content Deployment will support working off snapshots
Unattached content database restore
Browse through a content database that isn‟t joined to a farm to
find content to restore
Remote Blob Storage API
Replaces External Blob Storage (EBS) from SharePoint 2007
Supports file stream providers for external storage

14. SharePoint content/configuration settings
are stored in SQL databases
A deployment may have multiple content
databases
A site collection must exist completely in a
single content database
A content database may have multiple site
collections
Service applications get their own content
databases

15. How does that GUID stuff happen?

16. Plan before you
Install...
As DBA you can
create the DB‟s
before the install
(Give proper names)

17. Service account for SQL Services
SharePoint Setup Account
SharePoint Farm Service Account
Used by the CA web site application pool

18. SharePoint Setup Account (Used to setup
SP2010)
dbcreator
public
securityadmin
Rest of it is applied per Service
Application/Managed account via
provisioning

20. Created when a new SharePoint web
application is created
Container for all site specific data
Site Collections
Lists
Libraries
etc

21. Establish target sizes
Plan to put one or more site collections in
dedicated databases
Avoid more than 250 site collections in a single
database
Max content databases per web app : 100
Number of site collections per content
database keep it less than 250*

22. Number of documents = D
Average size of documents = S
Number of List items = L
Number of versions = V (must be above
zero)
10KB = Constant for Meta data values
DB Size = ((D x V) x S) + (10KB X (L + (V x D)))

23. Input Value
Number of documents (D) 200,000
Average size of documents (S) 250KB
List items (L) 600,000
Number of non-current versions (V) 2
(Assuming most number of versions
allowed is 10)
Database size = (((200,000 x 2)) × 250) +
((10 KB × (600,000 + (200,000 x 2))) =
110,000,000 KB or 105 GB

24. Content Database Size per Database
Instance
Recommendation  50-100 GIG: It‟s all
about your SLA. If something goes down,
how long can you be offline for?
Backup and Restore take time in two ways:
Backup: The larger the database the longer the
backup.
Restore: The larger the database the longer
the restore process.

25. Quotas at Web App > Site Collection level
Autogrow at DB level
Can pregrow the content databases
http://tinyurl.com/SP2010SQLPlan

26. Make sure that your Business engages with
you for the next SharePoint deployment
Understand your storage and High
Availability solutions and what it means in
terms of $$$ and sense to provide that

27. 2005? 2008?
32 bit or 64 bit?
Standard or Enterprise
2005 > 2008 is recommended
2008 R2 is best (as they say)

28. SP3 is required when using SQL 2005
Major improvements in maintenance wizard
Data Compression
Analysis Services improvements

29. Enterprise offers the following advantages
Full SQL 2005 functionality (DB+AS+IS+RS)
Supports more than 4 CPUs
Support for up to OS Max RAM
Database Partitioning
Online restore
Active failover for mirrors
Comparison chart of all the versions at
http://www.microsoft.com/sql/prodinfo/features/co
mpare-features.mspx

30. Use a custom maintenance plan to perform
the following maintenance tasks against
SharePoint databases:
Check database integrity > DBCC CHECKDB
Impacts performance (safe to run at low load times)
Reorganize indexes
Reduce size of database files > DBCC
SHRINKFILE
Monthly or quarterly as part of maintenance

31. Don‟t include DBCC SHRINKDATABASE as
an auto step in your plans
DBCC SHRINKFILE is the way to go for
SharePoint
http://www.sqlskills.com/BLOGS/KIMBERLY
/post/Database-Maintenance-Best-
Practices-Part-I-e28093-clarifying-
ambiguous-recommendations-for-
Sharepoint.aspx
Kimberly Tripp – sqlskills.com

32. Content databases (Very Important)
Databases required for Service applications
Search databases
Consider use of System Centre Data
Protection Manager
http://www.microsoft.com/systemcenter/dpm/workloads/sharepoint.mspx

33. Backup
Can be done as part of maintenance plan.
Three types
Full
Partial
Differential
Can use built in software or third party.
Redgate, Quest software allow for database
compression and encryption.
Results in smaller backups
Could also result in faster backups, if drive speed is
the bottleneck

34. Clean up History
Cleans up old information from Maintenance
Plans, SQL Agents and Backup and Restore
Operations
Leave as many jobs as you‟d like
T-SQL is shown in properties
Maintenance plans can be altered via the UI
Set up maintenance plans for different
intervals; daily, weekly, monthly, quarterly,
etc.

35. Should you shrink databases or logs?
Database size is reduced by dropping unused space.
Uses T SQL command DBCC SHRINKFILE instead of
DBCC SHRINKDATABASE
Do not shrink databases unless something drastic has
happened
Massive site or content deletions
Removing site collections from old content databases
Abandoning databases
Has a heavy impact on the server
Databases grow, it is what they do
Grow operations can be slow in SQL and will likely result in
a fragmented database file
Create database with enough space for one year‟s worth
of growth Used Space
Size on Disk Size on Disk
120GB 100GB
Free Space

36. For example, if your SQL
server name is
„SQLSERVER1‟, use
something like „SPSQL‟ to
connect, and have DNS
point to the proper server
location. This makes it
MUCH more flexible.

37. SOURCE (32bit) FARM A DESTINATION (64bit) FARM B
Tier C – Phase 3
x86 (MOSSWEB1)
x86 (MOSSWEB2) x64 (SPWEB1) (SPWEB2)
x64
Tier B – Phase 2
x86 (MOSSAPP1) x64 (SPAPP1)
Tier A – Phase 1
x86 (SQL) x64 (SQLSERVER08)

38. Web Front End
Good
Servers (WFE) Dual/Quad Core Processors
4GB for WFE (Virtualised)
8GB for APP (Virtualised)
Application
8-12GB for SQL < Dedicated
Servers (WFE)
Suitable for typical medium size
organisation in NZ (200-500 users)
Database
Backend (Shared) • Collaboration sites
• Project Sites
• Intranet

39. Web Front End Better
Servers (WFE)
Dual/Quad Core Processors
4GB for WFE (Virtualised)
6>8GB for APP
Application 8-12GB for SQL on a cluster or log
Servers (WFE) shipping
Can support more than 1000 users
Database
Backend (Shared)

40. NLB
Best (Large high availability)
Web Front End Quad Core Processors
Servers (WFE) 8GB for WFE x 2
8>12GB for APP x 2
Application
16>32GB for SQL on a cluster with
Servers (WFE) log shipping/mirror
10k users
Database
Backend
(Dedicated)

41. Web /App
Server
Mostly like this…
Virtualised all in Slow perf
one box!
Ad-hoc backups
No planning
Mixed expectations
Database Dissatisfied users/business
Backend
(Shared with lots
of other apps)

42. Mike Watson –
www.sharepointmadscientist.com

43. SQL and SharePoint page on TechNet
http://tinyurl.com/SQLSP2010
I will put a link and do a summary of this talk
on my blog
http://www.chandima.net/Blog/