Quali sono i rischi di cambiare il modello di recupero di SharePoint_Config DB in modo semplice?

Question

Il mio file di registro del database SharePoint_config cresce nella misura in cui si riserva molto spazio su disco per apparentemente nessuna buona ragione. Nel mio ambiente di sviluppo ho cambiato il suo modello di ripristino su semplice per abilitare il rilascio dello spazio su disco ed evitare il rischio del file di registro per crescere allo stesso ritmo di nuovo.

Il passo successivo era quello di ridurre il file di registro con l'attributo file vuoto migrando i dati su altri file nello stesso gruppo di file .

Quando è stato fatto, è stato rilasciato un terzo del disco (33 GB) e il mio ambiente di sviluppo sembra OK. La mia ipotesi è che questo è perfettamente ok in un ambiente di sviluppo, dove una registrazione di recupero e database non è così critica.

Tuttavia, potrebbe essere fatto anche su un ambiente di produzione? Capisco che tutti i miei tronchi sono spariti, ma quali sono i rischi di procedere nel modo in cui faccio in produzione? Quali sono i rischi di cambiare il modello di recupero di SharePoint_Config DB in modo semplice?

Answer 1

Ci sono due modi per guardare questa preoccupazione.

Prima è letteralmente prendere ciò che Microsoft dice in valore nominale, perché sono la maggior parte del tempo corretto sulle migliori pratiche operative per i propri prodotti.

ha detto così, se segui la linea guida menzionata qui http://technet.microsoft.com/en-us/library/cc678868. (v= ufficio.14) .aspx

dice

.

Note aggiuntive File di registro delle transazioni. Si consiglia di eseguire il backup del registro delle transazioni per il database di configurazione regolarmente per forzare il troncamento, o - se non si rispetta il sistema, modificare il database da eseguire in modalità di ripristino semplice. Per ulteriori informazioni, vedere Trenazione Tranciation Troncation ( http://go.microsoft.com/fwlink/p/?linkid= 186687 ).

Quindi la modalità di recupero è il modo in cui il mirroring è disabilitato.

Secondo modo è quello di guardare come vengono definite le strategie di backup e recupero. Qual è il tuo approccio di restauro?

PowerShell Driven Completion Farm Backup e Central Admin Driven Farm Restores o SQL Driven Restore tramite il database Attachissimo gli stessi alias e hardware del server. Il semplice recupero sarebbe la modalità preferibile per il primo caso e per il secondo caso è preferito mantenere il DB di SharePoint Config DB in una modalità di ripristino completo solo per garantire una replica "così come" dello stato precedente dal punto in cui la fattoria non è riuscita. < / P >.

MS delinea questo come indicato qui sotto

.

Il database di configurazione viene eseguito il backup quando si esegue un SharePoint Configurazione aziendale e backup dei contenuti e alcune impostazioni di configurazione Dal database vengono esportati e memorizzati come file XML. Quando è una fattoria Restaurato, il database di configurazione non viene ripristinato. Invece, il. Le impostazioni di configurazione salvate sono importate. Il database di configurazione può essere eseguito il backup con successo e ripristinato utilizzando SQL Server o Altri strumenti Se la farm di SharePoint viene prelevata per la prima volta.

Letteralmente, l'IFS e MAUS della tua preoccupazione sono altamente soggettivi sulla base della scelta dei piani di backup e recupero poiché SharePoint supporta alcuni di essi. Pertanto, è possibile scegliere di andare per un semplice modello di recupero per il database di configurazione e ridursi i registri in produzione solo se soddisfa le condizioni menzionate sopra in modo che le precauzioni siano prese di conseguenza.

Answer 2

Per impostazione predefinita, il database SharePoint_Config è impostato sul modello di ripristino completo. Ma, la raccomandazione Microsoft è quella di impostare il modello di ripristino per il tuo database SharePoint_Config su semplice in produzione (riferimento: http://technet.microsoft.com/en-us/library/cc678868.aspx ). È possibile modificare il modello di recupero per SharePoint_Config dopo aver creato il DB SharePoint_Config.

Non restringere mai i tuoi database è lo sviluppo, la produzione o lo scopo. Perché quando si riduce i tuoi DBS aumenta la frammentazione che riduce le prestazioni. Non vale la pena depositare l'importo della conservazione (Riferimento: http://www.microsoftvirtualacademy.com/training-courses/tuning-sql-server-2012-for-SharePoint-2013-Jump-Start#fbid=onaemo8b3b7 ( In uno di quei video ha menzionato questo, non ricordo quale) e http://blog.sqlauthority.com/2011/01/19/sql-server-shrinking-database-is-bad-increase-framentazione- indiscuti- prestazioni / ).