Shrink Datafiles for database in Avalability Group

Question

We're running SharePoint 2010 on SQL Server 2012.   We are also using Availability Groups for all databases (Primary and Secondary replica).   I'm running low on space and would like to shrink the datafiles for one of the content
databases.  The content database has 2 datafiles spread across 2 LUNS.  The SharePoint content database had a run away situation that caused the database to grow very large.  The situation has been corrected and the database now has about 98%
free space.  The database will not grow much larger than it is now.  I know shrinking datafiles is generally not a good idea, but in the case I think it's appropriate.
My question is, has anyone done this before on a database/datafiles that are in a High Availability Group?  Are there any risks?  Any recommendations?
Thanks!

Answer 1

Hi,
SharePoint content database is different than the ordinary database . You need to test the effect in the test environment before making the changes to the product environment.
There is a good article regarding Database Maintenance for SharePoint
http://technet.microsoft.com/en-us/library/cc262731(v=office.14).aspx#DBMaintenanceForSPS2010_ShrinkingDataFiles
Only perform shrink operations rarely, and only after you perform an operation that removes a lot of data from a database, and then only when you do not expect to use that free space again.
Because shrinking causes index fragmentation, do not shrink database files regularly. Instead, shrink database files only in response to large quantities of unused space that appear as a result of operations that significantly impact the
relative amount of used space in a database. If at all possible, avoid shrinking a database.
However, if you must shrink a database, use the following guidelines:
•Do not auto-shrink databases or configure a maintenance plan that programmatically shrinks your databases.
•Shrink a database only when users or administrators remove 50% or more of the content and you do not expect to reuse the unused space.
•Shrink only content databases. Users and administrators do not delete enough data from the configuration database, Central Administration content database, and various service application
databases to contain significant free space.
•Shrinking databases is an extremely resource-intensive operation. Therefore, if you absolutely must shrink a database, carefully consider when you schedule the shrink operation.
•After you shrink a database, the indexes in that database are fragmented. Use ALTER INDEX… REORGANIZE to address the fragmentation. If you are not configured to allow instant file initialization,
shrink the database to a target size that accommodates the size required for the near-term growth that you expect. For more information, see
Database File Initialization.
Thanks.
Tracy Cai
TechNet Community Support