Thinking of messing around with your Sharepoint database?

You better think again. If you consider doing any of the following changes:

• Adding database triggers


• Adding new indexes or changing existing indexes within tables


• Adding, changing, or deleting any primary or foreign key relationships


• Changing or deleting existing stored procedures


• Calling existing stored procedures directly, except as described in the SharePoint Protocols documentation


• Adding new stored procedures


• Adding, changing, or deleting any data in any table of any of the databases for the products that are listed in the “Applies to” section


• Adding, changing, or deleting any columns in any table of any of the databases for the products that are listed in the “Applies to” section


• Making any modification to the database schema


• Adding tables to any of the databases for the products that are listed in the “Applies to” section


• Changing the database collation


• Running DBCC_CHECKDB WITH REPAIR_ALLOW_DATA_LOSS (However, running DBCC_CHECKDB WITH REPAIR_FAST and REPAIR_REBUILD is supported, as these commands only update the indexes of the associated database.)


• Enabling SQL Server change data capture (CDC)


• Enabling SQL Server transactional replication


• Enabling SQL Server merge replication

And these unsupported database modifications are discovered during a support call then, to get support back… just perform a database restoration from the last known good backup that did not include the database modifications.

I really don’t get the implications of creating new stored procedures or indexes. It’ s perfectly common for a DBA to sometimes add non-business related objects to get some usage overview.

Hope I never get called to solve performance issues on a Sharepoint MSSQL database. I might inadvertently ruin their support eligibility.

Source: here.