Quels sont les risques liés à la modification du modèle de récupération SharePoint_Config DB à Simple?

Question

Mon fichier journal de la base de données SharePoint_Config augmente dans la mesure où il se réserve un espace disque pour apparemment aucune bonne raison. Dans mon environnement de développement, j'ai changé de modèle de récupération sur simple pour activer la libération de l'espace disque et éviter le risque de croissance du fichier journal à nouveau sur le même rythme.

L'étape suivante consistait à réduire le fichier journal avec l'attribut fichier vide en migrant les données vers d'autres fichiers du même groupe de fichiers . .

Quand cela a été fait, un tiers du disque (33 Go) a été libéré et mon environnement de développement semble bien. Je suppose que cela est parfaitement correct dans un environnement de développement, où une prise de consigne de récupération et de base de données n'est pas si critique.

Cependant, cela pourrait-il être fait sur un environnement de production aussi? Je comprends que tous mes journaux sont partis, mais quels sont les risques de poursuivre la façon dont je fais en production? Quels sont les risques de modification du modèle de récupération SharePoint_Config DB sur simple?

Answer 1

Il y a deux manières pour examiner cette préoccupation.

Première est de prendre littéralement ce que Microsoft dit en valeur nominale, car ils sont la plupart du temps corrects sur les meilleures pratiques opérationnelles pour leurs propres produits.

dit donc, si vous suivez la ligne directrice mentionnée ici

http://technet.microsoft.com/en-us/library/cc678868 (v= bureau.14) .aspx

Il dit

Notes supplémentaires Fichiers journaux de transaction. Nous vous recommandons de sauvegarder régulièrement le journal de transaction de la base de données de configuration pour forcer la troncature ou - si vous ne reflétez pas votre système - modifiez la base de données pour exécuter en mode de récupération simple. Pour plus d'informations, voir Truncation du journal de transaction ( http://go.microsoft.com/fwlink/p/?LinkID= 186687 ).

Alors, le mode de récupération est simplement le moyen de choisir si la mise en miroir est désactivée.

La deuxième manière consiste à examiner la définition de vos stratégies de sauvegarde et de récupération. Quelle est votre approche de restauration?

Sauvegarde complète de la batterie complète de PowerShell et la restauration de la ferme centrale dirigée par l'administrateur ou la restauration pilotée par SQL via la base de données de la base de données sur les mêmes alias et le même matériel. La récupération simple serait le mode préférable pour le premier cas et pour le second cas, il est préférable de conserver la configuration SharePoint DB en mode de récupération complète juste pour assurer une réplique "de même que" de l'état précédent du point de l'échec de la ferme. < / p>

ms décrit cela comme mentionné ci-dessous

La base de données de configuration est sauvegardée lorsque vous effectuez un SharePoint Sauvegarde de la configuration de la ferme et du contenu, et certains paramètres de configuration De la base de données sont exportés et stockés sous forme de fichiers XML. Quand une ferme est restauré, la base de données de configuration n'est pas restaurée. Au lieu de cela, le Les paramètres de configuration enregistrés sont importés. La base de données de configuration peut être sauvegardé avec succès et restauré en utilisant SQL Server ou d'autres outils si la ferme SharePoint est d'abord découverte hors ligne.

Littéralement, les IFS et les maisons de votre préoccupation sont très subjectifs sur la base de votre choix de plans de sauvegarde et de récupération, car SharePoint supporte quelques-uns d'entre eux. Par conséquent, vous pouvez choisir d'opter pour un modèle de récupération simple pour la base de données de configuration et de réduire les journaux en production uniquement si elle répond aux conditions mentionnées ci-dessus afin que les précautions soient prises en conséquence.

Answer 2

Par défaut, la base de données SharePoint_Config est définie sur le modèle de récupération complète. Mais la recommandation Microsoft est de définir le modèle de récupération de votre base de données SharePoint_Config à une simple production (référence: http://technet.microsoft.com/en-us/library/cc678868.aspx ). Vous pouvez modifier le modèle de récupération pour SharePoint_Config après avoir créé le DB SharePoint_Config.

Ne jamais rétrécir vos bases de données Soyez le développement, la production ou l'autre. Parce que lorsque vous réduisez votre DBS, il augmente la fragmentation qui réduit la performance. Il ne vaut pas la valeur de stockage que vous libérez (référence: http://www.microsoftvirtualacademy.com/training-courses/tuning-sql-server-2012-for-sharepoint-2013-jumb-star#fbid=aaMo8b3b7 ( Dans l'une de ces vidéos, ils ont mentionné cela, je ne me souviens pas de lequel) et http://blog.sqlauthority.com/2011/01/19/sql-server-shrinking-database-is-bad-fragmentation-fragmentation- Performance / ).