Quali sono i pro e i contro degli script di Ola rispetto all'utilizzo del piano di manutenzione?

9

Potete per favore aiutarmi a capire i pro e i contro dell'utilizzo della soluzione di Ola sul piano di manutenzione? Ho preparato una presentazione basata su SQL Pass ( http://www.pass.org/DownloadFile.aspx?File=ebae1b31 ) che presenterò.

Sto anche preparando alcuni scenari che la soluzione di Ola affronta e la soluzione del piano di manutenzione no. Potete per favore aiutarmi a spiegarlo più tecnicamente?

A proposito, stiamo gestendo quasi 150+ server (mix di 2008/2012/2014/2016) con la soluzione di Ola su almeno il 75% di essi. Mi è piaciuto questo articolo di Brent Ozar. Ma in uno dei commenti, Brent ha raccomandato di utilizzare una soluzione basata su script per il numero di server che abbiamo. https://www.brentozar.com/archive/2012/04/maintenance-plans-roombas-suck-good-way/

sql-server ola-hallengren

— colpetto
fonte

Stiamo parlando di backup, manutenzione dell'indice / stat, controllo della corruzione o tutto quanto sopra?

— nkdbajoe,

Tutti loro. Intero script di soluzione di manutenzione di Ola. Ho risolto i problemi di ricostruzioni dell'indice non necessarie e aggiornamenti delle statistiche nel piano di manutenzione utilizzando gli script di Ola. Volevo solo altre munizioni tecniche da altri DBA là fuori. Grazie.

— Pat

2

Personalmente credo che la migliore soluzione sia una soluzione che soddisfi i requisiti della tua azienda e la tua capacità di risolverlo in caso di errore. La soluzione di Ola non è male in generale, ma preferisco ancora la mia soluzione personalizzata per il mio ambiente. Ad esempio, per la manutenzione dell'indice, voglio avere esecuzioni parallele per risparmiare tempo. La soluzione di Ola non funziona qui. Voglio avere un aggiornamento statistico incrementale, la soluzione di Ola non funziona neanche qui.

— jyao,

Hai dei dati per dimostrare che sono migliori o stai solo andando con ciò che ritieni sia migliore? Il modo migliore per risolvere il problema è ottenere alcuni dati sulle prestazioni per essere in grado, quindi mostra perché un metodo è migliore

— Joe W

Per la manutenzione dell'indice, molte volte il fattore limitante è la SAN e il sottosistema di archiviazione. A seconda della configurazione SAN, potresti non notare alcun miglioramento nelle ricostruzioni parallele.

— Alen,

13

Ho scritto qui

I piani di manutenzione non sono male, ma quando l'ambiente cresce, la flessibilità e la funzionalità limitate fornite dai piani di manutenzione non saranno sufficienti.

Per aggiungere altro,

La soluzione di manutenzione di Ola è ampiamente accettata nella comunità e nelle grandi organizzazioni .
La sua fonte aperta e i problemi possono essere sollevati su github / problemi con una probabilità di risolverlo molto velocemente.
È flessibile e scalabile (anche se si desidera distribuirlo su centinaia di server, basta usare Install-DbaMaintenanceSolution da dbatools.)
Microsoft ha impiegato quasi un decennio per correggere la GUI del piano di manutenzione che era stata buggy stessa :-)
ha una vasta documentazione e domande frequenti ed è costantemente aggiornato per adattarsi alle nuove versioni del server sql.
nella versione di anteprima , è anche possibile eseguire backup in parallelo.
per la soluzione di manutenzione dell'indice, è anche possibile cronometrare il processo, ad esempio se viene eseguito più di X volte, interromperlo.

— Kin Shah
fonte

5

Uno dei principali vantaggi di una soluzione basata su script è la facilità di distribuzione, qualcosa che è chiaramente rilevante nel tuo caso, poiché hai più di 150 server. Cercare di implementare diversi piani di manutenzione (vale a dire almeno 2, uno per i database di sistema e uno per i database degli utenti) su 150 server sarebbe un incubo. Mantenerli una volta sul posto è altrettanto una seccatura.

Una soluzione basata su script è molto più facile da implementare e gestire nel tempo. Gli script di Ola sono abbastanza completi e coprono la maggior parte delle esigenze. Rappresentano un ottimo punto di partenza per qualsiasi organizzazione per poi adattarsi alle proprie esigenze specifiche.

Nel nostro caso, disponiamo di circa 40 istanze SQL nel nostro ambiente DEV e utilizziamo script Ola modificati con la funzione di connessioni multiple di SSMS per essere in grado di implementare le modifiche al regime di manutenzione su tutte e 40 le istanze con un clic. Eventuali casi speciali sono gestiti dalle nostre modifiche.

— Mike
fonte

3

Non sono sicuro al 100% dei suoi script, ma gli script personalizzati sono molto meglio dei piani di manutenzione. I piani integrati ricostruiranno ogni indice su una tabella, indipendentemente dalla poca frammentazione. Se hai Always On creerà una tempesta di traffico.

Script personalizzati puoi ricostruire qualsiasi cosa oltre il 20% o qualunque sia la tua soglia. Meno indici ricostruiti alla volta. Meno dati sempre attivi da inviare ai secondari. Ricostruzione più veloce perché stai ricostruendo meno indici. È richiesta una finestra di manutenzione più breve.

L'ultima volta che ho utilizzato i piani di manutenzione, avevo una tabella di 300 milioni di righe e Always On sarebbe rimasto indietro di ore ogni volta che iniziarono le ricostruzioni dell'indice e che i problemi con il registro delle transazioni traboccavano. Sono tornato agli script e tutto è andato via.

— Alen
fonte

1

Ho originariamente scritto il mio per SQL 2005 intorno al 2007. Ho usato quello che i libri online avevano come base e l'ho cambiato un po '. Allora sembrava che la maggior parte delle persone usasse i piani e ora sembra essersi invertita. E prima di iniziare a fare cose DBA, il precedente DBA prima di me aveva script personalizzati per SQL 2000. L'unica cosa che diversamente era che avevo ricostruito tutto. È stato più veloce ricostruire qualsiasi cosa oltre il 20% o il 30% rispetto alla riorganizzazione. Per i backup abbiamo sempre utilizzato prodotti di terze parti

— Alen,

1

Oltre a quanto sopra, la mia ragione preferita è quella di poter cambiare automaticamente il tipo di backup in modo che un nuovo database disponga di un backup completo la prima volta che viene eseguito il processo di backup del registro invece di attendere fino all'esecuzione del successivo processo di backup completo.

— SQLDBAWithABeard
fonte

0

I piani di manutenzione andranno bene per la maggior parte del tempo. Gli script di Ola Hallengren andranno bene per la maggior parte del tempo.

In casi molto rari, potresti dover coltivare il tuo.

Come ha detto Jyao, si riduce a cui ti senti più a tuo agio nel lavorare. Se il tuo collega è più a suo agio con i piani di manutenzione, perché dare una svolta ai tuoi mutandoni?

Se lavora in banca dati da oltre 20 anni, ha già scritto i suoi script di manutenzione. Proprio nel periodo in cui stavi imparando a guidare, probabilmente c'era qualche giovane punk in pantaloncini cargo e infradito che è arrivato ed è stato tutto come "ehi, vecchio programmatore, i piani di manutenzione sono migliori - e tirati giù i pantaloni, sembri ridicolo! ".

Poi c'è stata probabilmente una battaglia di 4 anni in cui il giovane arrogante è entrato in un piano di manutenzione ogni volta che poteva. Ora quest'altro giovane punk con jeans attillati e un farfallino strano gli sta dicendo di tornare alle sceneggiature. Basta far diventare grigi i capelli.

Tre cose da considerare:

Questi esempi di superiorità di Hallengrenite sono effettivamente applicabili al tuo ambiente?

Ti causerà un vero problema se usa piani di manutenzione?

Se lo convincerai a usare gli script di Hallengren e c'è un problema, sarà in grado di risolverlo da solo o dovrà chiamarti?

— Giacomo
fonte

Rispondi alle prime due domande Sì. Abbiamo già riscontrato problemi con i piani di manutenzione e li ho risolti con la soluzione di Ola. Sul server di produzione era presente anche un'attività di riduzione del registro (??) che ho disabilitato immediatamente. Terza domanda, non lo so. Non sono sicuro che sarà in grado di risolvere i problemi creati dal piano di manutenzione stesso. Quando gli ho chiesto in caso di problemi, cosa dovremmo fare? La sua risposta era chiamare il supporto Microsoft. (??)

— Pat

@Pat, ahh, sembra che abbia raggiunto il suo limite secondo il Principio di Peter. Fai attenzione a cercare di renderlo migliore - probabilmente non apprezzerà l'aiuto.

— James,