Ho cercato query a esecuzione lenta nel nostro database e ho concluso che si tratta di un classico problema chiave crescente. Poiché le nuove righe vengono inserite quasi costantemente e un dato pezzo di SQL per estrarre gli ultimi dati dal DB viene eseguito ogni 30 minuti, la prima opzione di aggiornamento delle statistiche ogni 30 minuti sembrava che potesse essere uno spreco di risorse.
Quindi, ho esaminato Trace Flag 2389 che in linea di principio dovrebbe aiutare, tuttavia ciò richiede che la colonna Leading sia contrassegnata come Ascendente e quando ho usato Trace Flag 2388 per controllare le statistiche dell'indice (PK), vedo che la colonna principale è in realtà bollato come Stazionario - come lo è per molti degli indici PK su altre tabelle aggiornati contemporaneamente.
Non sembra esserci molta guida su cosa si traduca in un marchio di Stationary, tuttavia ho trovato KB2952101 che dice che se meno del 90% degli inserti fosse maggiore del vecchio valore massimo, sarebbe classificato come Stazionario. Tutti i nostri inserti sono nuovi invii e la colonna principale è una colonna IDENTITÀ bigint, quindi il 100% degli inserti dovrebbe essere maggiore del valore massimo precedente.
Quindi la mia domanda è: perché la colonna dovrebbe essere etichettata come Fermo, quando è ovviamente crescente?
Un precedente tentativo di risolvere questo problema per alcuni SQL in esecuzione ogni giorno (che funzionava davvero bene) ha portato alla configurazione di un lavoro per aggiornare le statistiche per questa tabella ogni notte. L'aggiornamento non esegue un FULLSCAN, quindi potrebbe essere che a volte la scansione campionata manchi le nuove righe, quindi non viene sempre visualizzata come crescente?
L'unica altra cosa a cui riesco a pensare che potrebbe influire su questo, è che abbiamo un lavoro di archivio in esecuzione dietro le quinte che elimina le righe per una certa età. Questo potrebbe influire sul marchio?
Il server è SQL Server 2012 SP1.
Aggiornamento : un altro giorno, un altro aggiornamento delle statistiche - stesso marchio fisso. Ci sono stati 28049 nuovi inserti dal precedente aggiornamento delle statistiche. Ogni riga ha un timestamp di quando è stata inserita, quindi se seleziono max (id) dalla tabella in cui timestamp <'20161102' ottengo 23313455 Allo stesso modo, se lo faccio per quando le statistiche sono state aggiornate oggi, ottengo 23341504.
La differenza tra questi è i 28049 nuovi inserti, quindi, come puoi vedere, a tutti i nuovi inserti sono state assegnate nuove chiavi ascendenti (come previsto), suggerendo che la colonna principale dovrebbe essere marcata come crescente anziché stazionaria.
Nello stesso periodo, il nostro processo di archiviazione ha eliminato 213.629 righe (stiamo lentamente cancellando i vecchi dati). C'è qualche possibilità che un conteggio delle righe ridotto possa contribuire al marchio fisso? L'ho provato prima e non sembrava aver fatto alcuna differenza.
Aggiornamento 2 : un altro giorno, un altro aggiornamento delle statistiche e la colonna è ora contrassegnata come crescente! In base alla teoria sulle eliminazioni che influiscono su questo, ho verificato la percentuale di aggiornamenti che sono inserti rispetto alle eliminazioni e ieri il 13% erano inserti, mentre i due giorni precedenti rappresentavano circa il 12%. Non penso che ci dia qualcosa di conclusivo.
È interessante notare che una tabella correlata che ottiene in media 4 righe inserite per ogni riga inserita in questa tabella principale, e ha le sue statistiche aggiornate allo stesso tempo, ha la colonna IDENTITY PK ancora come Stazionaria !?
Aggiornamento 3 : nel fine settimana riceviamo più inserti. Questa mattina la colonna principale è tornata a Fermo. Nell'ultimo aggiornamento delle statistiche, abbiamo avuto 46840 inserti e solo 34776 eliminazioni.
Ancora una volta, è interessante notare che la tabella correlata che ho menzionato sopra ora ha la colonna principale con il marchio Ascendente. Non c'è documentazione che possa spiegare questo?
Aggiornamento 4 : è passata una settimana circa, il processo di archiviazione ha cancellato il backlog, quindi stiamo eliminando costantemente circa i due terzi del numero di righe da inserire. Le statistiche mostrano risultati contrastanti attraverso le relative tabelle, con una che mostra stazionaria e due che mostrano un ordine crescente, nonostante siano state tutte aggiornate in modo simile in modo simile.