Showing posts with label database. Show all posts
Showing posts with label database. Show all posts

Tuesday 15 June 2010

SQL Server for SharePoint 2010 notes

  • SharePoint Server 2010 needs 64-bit SQL Server 2008 SP 1 CU2 (Cumulative Update) or 64-bit SQL Server 2005 SP3 CU3.
  • Determine you storage requirements
  • SQL is I/O intensive, to improve this get fast disks and use multiple disks & disk controllers.
  • Use a SAN if possible, the physical hardware with multiple disks that are RAID 10 (Stripped & mirrored) preferable with C:\ drive for programs, d:\ for data and e:\ for logs.
  • Don't virtualise SQL Server unless you are a virtualisation expert and can get extremely high IOPS.
  • Search db's can also be broken into their own drive/disks.
  • Build the database with hardware redundancy (NIC, controllers, RAID).
  • Use SQL Server 2008 R2 Enterprise edition if possible.
  • Index's will be about 25% of the size of your database storage.
  • 8 GB is the minimum amount of RAM for a DB in production, 16 GB is more comfortable and for large farms or big site collections 64GB is a good guideline. SQL Enterprise Edition (EE) can support up to 2 Terabytes of RAM.
  • Don't install any other software on the database as you want maximum I/Oa nd the DB server/s should be locked down.
  • SQL guideline is 4 SP2010 server for each SQL machine.
  • Use multiple Data files for Content databases (Distribute data across disks, faster backup and restore). Try keep data files roughly similar in size & usage.
  • Large files can be store in Remote Blob storage (RBS), saves db and can be cheaper on disk space. Cheaper storage can be used to hold large blob data such as cloud storage. Blobs can be stored locally using the files stream using all versions of SQL, for remote storage EE is needed (Not sure what this means).
  • Pre-grow data & log files, faster than doing it on the fly when the system is over utilised.
  • Try keep 25% of db space free for growth in peak times.
  • Monitor SQL Servers including hardware counters.
  • SQL Database Mirroring is greatly improved.
  • Use backup compression on SQL 2008 (2005 not supported) is backup size is an issue. I/O is improved for the backup process.
  • SQL 2008 offers improved clustering.
  • Mirroring or Clustering is a good resilience option.  Review for HA.
  • Use Windows authentication not mixed mode authentication.
  • Use throttling if SQL is under load.
  • Transparent Data Encryption is supported in SQL 2008 EE & SP2010, there are costs but security is much better.
  • Failover clustering is still available is you use Standard or EE of SQL 2008.
  • Clustering and mirroring are good options for High Availability (HA) select appropriately for your network and knowledge.
  • Install SQL Server using a domain account.  The windows service account needs no permissions but is needed for advance SQL features as opposed to using built in accounts or local accounts.
  • I tend to use IP adrs for point to SQL Server, the netbios name also works and can be easier in the event of a SQL Server disaster.  For really good availability use a SQL Alias, it takes more setup time but if you loose your SQL box you will be glad you did it as you can switch over to another SQL box quickly.
  • Mirroring is a good option for HA.  Backups can be performed in various ways ensure you select the appropriate backup strategy. 
  • Max Degree of Parallelism (MAXDOP) should be set to 1. This can be found on the SQL Server instance properties > Advanced > Parallelism > Max Degree of Parallelism. Or run the T-SQL SELECT value FROM sys.configurations WHERE name = 'max degree of parallelism' SP2013 tries to reset MAXDOP during installation. 
  • AUTO_UPDATE_STATISTICS & AUTO_CREATE_STATISTICS should be disabled in SP2010.  More Info.
  • Use the default SQL Collation (Latin1_General_CI_AS_KS_WS), a good reason why SharePoint farms should have their own SQL Server instance.
  • Full backups should clear down the transaction log, if the transaction log is not cleaned up, perform it manually after you have checked the SQL backup of the db is valid.
  • Incremental backups are cumulative i.e. they go back to the last Fullback up not the last incremental backup.
  • Don't let transaction logs grow continuously, perform full backups periodically followed by taking a transaction log backup that truncates the log to remove/zero unused transactions.
  • SQL 2008 Developer Edition is the equivalent of SQL 2008 Enterprise Edition.
  • SQL Server 2008 R2 is the best option if you can choose.
  • To determine SQL edition in SQL Management Studio run
SELECT SERVERPROPERTY('productversion'), SERVERPROPERTY ('productlevel'), SERVERPROPERTY ('edition')
  • SQL Server 2008 = 10.0.1600.22 needs cumulative update 2 for SP1. Update - 12/10/2010 or SP2
  • SQL Server 2008 SP1  = 10.0.2531.0 needs cumulative update 2 for SP1.
  • SQL Server 2008 SP1 + CU2 = 10.0.2714.0
  • SQL Server 2008 + SP2 = 10.0.4000.0 Update - 12/10/2010
  • SQL Server 2008 R2  =  10.50.1600.1 Update - 12/10/2010
  • SQL Server 2008 R2 SP1 = 10.50.2500.0 Updated - 26/07/2011
I also telnet from each of my SharePoint servers to SLQ Server before I install to ensure networking is working and that SQL Server is available.

SharePoint DB's create:
SPF2010: 1) Configuration database (DB), 2) CA, Content DB's (multiple for site collections, 3) 1 content db stores 1 or more site collections data, Best Practice is to limit content db's to 200GB), 4) Usage and Health Data Collection database (farm health & usage info), 5) Business Data Connectivity database, Application Registry database(BDC in MOSS used for historic reason) & 6) Subscription Settings database.
SPS2010 Std Ed: 1) Secure Store database (stores & masps credentials), 2) State database (State info used by forms server, info path & visio services), 3) Web Analytics Staging database, 4) Web Analytics Reporting database, 5) Search service application Administration database, 6) Search service application Crawl database, 7) Search service application Property database, 8) User Profile service application Profile database, 9) User Profile service application Synchronization database, 10) User Profile service application Social Tagging database, 11) Managed Metadata database, 12) Word Automation Services database
SPS2010 Ent Ed: 1) PerformancePoint service application database, 2) Project Server 2010 databases, 3) Published database, 4) Archive database, 5) Reporting database, 6) ...
More info:
http://technet.microsoft.com/en-us/library/cc990273.aspx
Determine the SQL Server version installed
SQL Version no's
SQL DB info for SP 2010 - db's created
Updated 15 Dec 2010 - Database Maintenance for SharePoint 2010 by Matt Ranlett, Brendon Schwartz
Updated 11 May 2011 - Nice simple article on the SP2010 database's by Bert Jan van der Steeg
Updated 24 May 2011 - SQL Server mirror is either Synconous (hot standby for HA) or Asynconous (for DR).  Mirroring requires Enterprise edition and standard edition support is limited.  Clustering is normally done in the same server room whereas Mirroring is done on a remote site, the distance is dictated by the speed of the connection.
Update 11 Aug 2011 - Set the appropriate recovery model for your SP2010 databases.
Updated 28 May 2012 - SQL Best Practices for SharePoint 2010
Update 13 August 2013 - Best Practices for SQL Server in a SharePoint 2013 Farm - In SP2013 still ensure MAXDOP is set to 1.  Note:  During the SPInstall SQL will make this change if it has permissions to do this.

Sunday 6 June 2010

Application Architecture in SharePoint 2010

Problem: I have a client that needs a composite built using 2010. The application is used to manage digital assets for suppliers. Key questions are where to store data and how to access the data.
Hypothesis: Where to store data, previously in MOSS I would of used SQL Server and accessed it via the BDC or custom web parts. In SP 2010 lists have been vastly improved and are now a good option for storing data. The new External Content Type can be used on SQL but goes beyond my requirement.
The key improvements to SharePoint lists are:

  1. Lookup lists are improved and easier to implement;
  2. Query joins and LINQ improve retrieving data;
  3. LINQ gives you strongly typed lists which using the old "Server Object Model" were weakly typed;
  4. LINQ querries are converted to CAML querries and therefore more performant than using the Server object model method and alot cleaner than using CAML to query data;
  5. Formula based validation on fields;
  6. Store level enforcement (MOSS enforce requirements such as null values only at the UI level);
  7. Improved referential integrity between lookup lists.
My choice was between using SQL Server to store the application data and SharePoint lists. SQL tables have the following key advanatages of they are more performant, and are transactionable. The easy of use and adavantages meant that SharePoint lists are the prefered option for storage.
Application for the suppliers and users also has several options however SharePoint provides most of the admin screens. The actual app can be built using application pages or web parts or the method i prefer, the client object model.

Accessing SharePoint Data options to consider are: Client Object Model (Weakly typed), however REST API's are Strongly typed for SP lists only. New in SP2010
Server Object Model (OM) is weakly type lists but offers the most flexibility. The Server OM existed on MOSS but is improved in SP2010. LINQ gives strongly type SP lists that can be read-write (new in SP2010)
Resolution:
Used SP lists to store the digital assets, the ordering data is also stored in SharePoint lists. For speed of development in the prototype I built using application pages using web parts that accessed the lists using LINQ to SharePoint. The final application will be built using the Client OM.