D'accordo con Marc e Unkown sopra ... 6 indici nell'indice cluster sono troppi, specialmente su una tabella che ha solo 14 colonne. Non dovresti avere più di 3 o 4, in tal caso, direi 1 o forse 2. Potresti sapere che l'indice cluster è la tabella effettiva sul disco, quindi quando viene inserito un record, il motore di database deve ordinarlo e posizionalo nella sua posizione organizzata e ordinata sul disco. Gli indici non cluster non lo sono, supportano le "tabelle" di ricerca. I miei VLDB sono disposti sul disco (CLUSTERED INDEX) in base al punto 1 di seguito.
- Riduci il tuo indice cluster a 1 o 2. Le migliori scelte di campo sono IDENTITY (INT), se ne hai uno, o un campo data in cui i campi vengono aggiunti al database, o qualche altro campo che è un tipo naturale di come i tuoi dati vengono aggiunti al database. Il punto è che stai cercando di mantenere quei dati in fondo alla tabella ... o di averli disposti sul disco nel modo migliore (90% +) per leggere i record. Questo fa in modo che non vi sia alcuna riorganizzazione in corso o che sia necessario un solo colpo per ottenere i dati nel posto giusto per la migliore lettura. Assicurati di inserire i campi rimossi in indici non raggruppati in modo da non perdere l'efficacia della ricerca. Non ho MAI inserito più di 4 campi sui miei VLDB. Se hai campi che vengono aggiornati frequentemente e sono inclusi nel tuo indice cluster, OUCH, ciò riorganizzerà il record sul disco e causerà una frammentazione COSTOSA.
- Controlla il fattore di riempimento sui tuoi indici. Maggiore è il numero del fattore di riempimento (100), più piene saranno le pagine dati e le pagine indice. In relazione a quanti record hai e quanti record stai inserendo, cambierai il fattore di riempimento # (+ o -) dei tuoi indici non cluster per consentire lo spazio di riempimento quando viene inserito un record. Se modifichi il tuo indice cluster in un campo dati sequenziale, questo non avrà molta importanza su un indice cluster. Regola pratica (IMO), fattore di riempimento 60-70 per scritture elevate, 70-90 per scritture medie e 90-100 per letture elevate/scritture basse. Riducendo il fattore di riempimento a 70, significa che per ogni 100 record in una pagina, vengono scritti 70 record, che lasceranno spazio libero di 30 record per record nuovi o riorganizzati. Mangia più spazio, ma è sicuramente meglio dover DEFRAG ogni notte (vedi 4 sotto)
- Assicurati che le statistiche siano presenti sul tavolo. Se si desidera eseguire lo sweep del database per creare statistiche utilizzando "sp_createstats 'indexonly'", SQL Server creerà tutte le statistiche su tutti gli indici che il motore ha accumulato per richiedere statistiche. Tuttavia, non tralasciare l'attributo 'indexonly' o aggiungerai statistiche per ogni campo, il che non sarebbe buono.
- Controlla la tabella/gli indici utilizzando DBCC SHOWCONTIG per vedere quali indici vengono frammentati di più. Non entrerò nei dettagli qui, sappi solo che devi farlo. Quindi, in base a tali informazioni, modifica il fattore di riempimento verso l'alto o verso il basso in relazione alle modifiche che stanno subendo gli indici cambiano e alla velocità (nel tempo).
- Imposta una pianificazione lavoro che verrà eseguita online (DBCC INDEXDEFRAG) o offline (DBCC DBREINDEX) su singoli indici per deframmentarli. Avvertenza:non eseguire DBCC DBREINDEX su una tabella così grande senza che sia durante il periodo di manutenzione, poiché le app verranno disattivate ... specialmente su CLUSTERED INDEX. Sei stato avvisato. Prova e prova questa parte.
- Usa i piani di esecuzione per vedere quali SCANS e FAT PIPES esistono e regola gli indici, quindi deframmenta e riscrivi i proc archiviati per eliminare quei punti caldi. Se vedi un oggetto ROSSO nel tuo piano di esecuzione, è perché non ci sono statistiche su quel campo. Questo è male. Questo passaggio è più "l'arte che la scienza".
- Negli orari di punta, esegui UPDATE STATISTICS WITH FULLSCAN per fornire al motore di query quante più informazioni possibili sulle distribuzioni dei dati. Altrimenti esegui l'AGGIORNAMENTO STATISTICHE standard (con scansione standard del 10%) sulle tabelle durante i giorni feriali o più spesso come meglio credi con i tuoi osservatori per assicurarti che il motore abbia più informazioni sulle distribuzioni dei dati per recuperare i dati in modo efficiente.
Mi dispiace che sia così lungo, ma è estremamente importante. Ti ho dato qui solo informazioni minime, ma ti aiuterà molto. Ci sono alcune sensazioni viscerali e osservazioni che entrano nelle strategie utilizzate da questi punti che richiederanno il tuo tempo e le tue prove.
Non è necessario passare all'edizione Enterprise. Tuttavia, l'ho fatto per ottenere le funzionalità di cui si è parlato in precedenza con il partizionamento. Ma l'ho fatto SOPRATTUTTO per avere capacità di multithreading molto migliori con la ricerca e la DEFRAGAZIONE e la manutenzione online ... Nell'edizione Enterprise, è molto meglio e più amichevole con i VLDB. L'edizione standard non gestisce l'esecuzione di DBCC INDEXDEFRAG anche con i database online.
