¿Cuáles son los riesgos de cambiar el modelo de recuperación de SharePoint_Config DB a simple?

Question

Mi archivo de registro de la base de datos de SharePoint_Config crece en la medida en que se reserva mucho espacio en el disco para que aparentemente no hay buenas razones. En mi entorno de desarrollo cambié su modelo de recuperación a simple para habilitar la liberación del espacio en disco, y evitar el riesgo del archivo de registro para crecer al mismo ritmo nuevamente.

El siguiente paso fue reducir el archivo de registro con el archivo de atributo vacío migrando los datos a otros archivos en el mismo grupo de archivos .

Cuando se hizo, se publicó un tercio del disco (33 GB), y mi entorno de desarrollo parece estar bien. Supongo que esto está perfectamente bien en un entorno de desarrollo, donde un registro de recuperación y base de datos no es tan crítico.

Sin embargo, ¿podría hacerse esto en un entorno de producción también? Entiendo que todos mis registros se han ido, pero ¿cuáles son los riesgos de proceder de la forma en que lo hago en la producción? ¿Cuáles son los riesgos de cambiar el modelo de recuperación de SharePoint_Config DB a simple?

Answer 1

Hay dos formas para ver esta preocupación.

Primero es tomar literalmente lo que Microsoft dice en el valor nominal, porque son la mayor parte del tiempo correcto sobre las mejores prácticas operativas para sus propios productos.

lo dijo, si sigues la guía mencionada aquí
http://technet.microsoft.com/en-us/library/cc678868 (v= OFICINA.14) .ASPX

dice

Notas adicionales Archivos de registro de transacciones. Le recomendamos que realice una copia de seguridad del registro de transacciones para la base de datos de configuración regularmente para forzar el truncamiento, o - Si no está reflejando su sistema, cambie la base de datos para ejecutarse en modo de recuperación simple. Para obtener más información, consulte Truncamiento de registro de transacciones ( http://go.microsoft.com/fwlink/p/?linkid= 186687 ).

Simplemente el modo de recuperación es la forma de ir para su reflejo está deshabilitado.

Segunda forma es ver cómo se definen sus estrategias de copia de seguridad y recuperación. ¿Cuál es su enfoque de restauración?

PowerShell impulsó la respaldo de la granja de la granja y la restauración de la granja de administración central o la restauración de SQL a través de la base de datos adjunta a través de los mismos alias y hardware del servidor. La simple recuperación sería el modo preferible para el primer caso y para el segundo caso, su preferente mantener la configuración de la configuración de SharePoint en un modo de recuperación completo solo para garantizar una réplica de "AS es" de la réplica del estado anterior desde el punto. / p>

MS describe esto como se menciona a continuación

La base de datos de configuración está respaldada cuando realiza un sharePoint Configuración de la granja y copia de seguridad de contenido, y algunos ajustes de configuración De la base de datos se exportan y se almacenan como archivos XML. Cuando una granja es Restaurado, la base de datos de configuración no se restaura. En cambio, el Los ajustes de configuración guardados se importan. La base de datos de configuración se puede respaldar y restaurar con éxito utilizando SQL Server o Otras herramientas si la granja de SharePoint se toma por primera vez fuera de línea.

Literalmente, el IFS y los más de su preocupación son altamente subjetivos según su elección de los planes de copia de seguridad y recuperación, ya que SharePoint apoya a algunos de ellos. Por lo tanto, puede elegir ir a un modelo de recuperación simple para la base de datos de configuración y reducir los registros en producción solo si cumple las condiciones mencionadas anteriormente para que las precauciones se tomen en consecuencia.

Answer 2

De forma predeterminada, la base de datos SharePoint_Config se establece en el modelo de recuperación total. Pero, la Recomendación de Microsoft es configurar el modelo de recuperación para su base de datos de SharePoint_Config a simple en producción (Referencia: http://technet.microsoft.com/en-us/library/cc678868.aspx ). Puede cambiar el modelo de recuperación para SharePoint_Config después de crear el SharePoint_Config DB.

Nunca encoge sus bases de datos para el desarrollo, la producción o donde sea. Porque cuando encoge su DBS, aumenta la fragmentación que reduce el rendimiento. No vale la pena la cantidad de almacenamiento que está libre (Referencia: http://www.microsoftvirtualacademy.com/training-courses/tuning-sql-server-2012-for-sharepoint-2013-jump-startart#fbid=onaemo8b3b7 ( En uno de esos videos mencionaron esto, no recuerdo cuál) y http://blog.sqlauthority.com/2011/01/19/sql-server-shrinking-database-is-bad-ucenses-fragmentation-reduces- rendimiento / ).