Di chi fidarsi?

Stiamo risolvendo un problema di vecchia data con un fornitore. Il loro software ha la tendenza a bloccarsi e smettere di funzionare una o due volte alla settimana causando gravi interruzioni del nostro funzionamento. Non sono stati in grado di determinare la causa nonostante abbiamo inviato loro molti GB di registri e backup del DB. Ultimamente hanno iniziato a suggerire che i problemi sono dovuti alla nostra manutenzione e forse non al loro software (nonostante non ci siano query a lungo in esecuzione, pressione della CPU / RAM / IO o persino deadlock quando si verificano i problemi). In particolare stanno dicendo che i nostri indici sono un problema.

Il loro strumento preferito da usare è DBCC showcontig nonostante io sostenga che la cosa sia deprecata da MS. Ossessionano soprattutto la densità di scansione e l'estensione della frammentazione. Per togliere la scusa ho istituito una manutenzione notturna aggressiva che ricostruisce gli indici con una densità di scansione <90% o una frammentazione> 10%. Ciò li ha in qualche modo allontanati dal treno della densità di scansione, ma rimangono fissi sulla frammentazione dell'estensione. DBCC showcontig mostra un'elevata frammentazione anche su un indice ricostruito ore prima. Di seguito sono riportati i risultati di dbcc_showcontig e sys.dm_db_index_physical_stats per una tabella che hanno indicato come "possibile problema".

DBCC SHOWCONTIG

• Pagine scansionate ................................: 1222108
• Estensioni scansionate ..............................: 152964
• Interruttori di estensione ..............................: 180904
• Avg. Pagine per estensione ........................: 8.0
• Densità di scansione [Migliore conteggio: conteggio effettivo] .......: 84,44% [152764: 180905]
• Frammentazione della scansione logica ..................: 3,24%
• Estesa frammentazione della scansione ...................: 35,97%
• Avg. Byte gratuiti per pagina .....................: 692.5
• Avg. Densità pagina (pieno) .....................: 91,44%

sys.dm_db_index_physical_stats

index_type_desc      alloc_unit_type_desc     Avg_fragmentation_in_percent  page_count

CLUSTERED INDEX       IN_ROW_DATA          3.236803129  1222070

NONCLUSTERED INDEX    IN_ROW_DATA          0.680074642  48230

NONCLUSTERED INDEX    IN_ROW_DATA          0.093237195  48264

NONCLUSTERED INDEX    IN_ROW_DATA          0.03315856   48253

NONCLUSTERED INDEX    IN_ROW_DATA          0.194653248  48291

NONCLUSTERED INDEX    IN_ROW_DATA          0.393480436  58961

NONCLUSTERED INDEX    IN_ROW_DATA          0.23622292   64346

NONCLUSTERED INDEX    IN_ROW_DATA          0.041445623  48256

NONCLUSTERED INDEX    IN_ROW_DATA          0.701172007  59044

NONCLUSTERED INDEX    IN_ROW_DATA          0.216397724  53605

Dovrei preoccuparmi dei miei indici? Quello sopra non è atipico. Il DMV MS preferito sembra mostrare che va bene, ma il fornitore è bloccato su quella frammentazione del 35,97%. Sospetto che siano solo loro a cercare disperatamente qualcosa su cui incolpare i loro problemi di software, ma se ho un problema reale, voglio provare a risolverlo.

Il loro software ha la tendenza a bloccarsi e smettere di funzionare una o due volte alla settimana causando gravi interruzioni del nostro funzionamento. Non sono stati in grado di determinare la causa nonostante abbiamo inviato loro molti GB di registri e backup del DB. ... In particolare stanno dicendo che i nostri indici sono un problema.

Oh, giusto, penso di aver già sentito questa battuta. Non va qualcosa del tipo:

Un'anatra entra in un bar e dice "Ahi!" (sto solo scherzando ;-) e il barista dice "Che cosa hai?"

L'anatra dice "Dammi 3 dita della tua vodka più forte".

Il barista dice, quasi come se stesse scherzando, "Non vuoi dire 3 'piume'?"

L'anatra dice: "Senti, mi dispiace che tu non sia più lo sceneggiatore di Tutti amano Raymond , ma è stata una giornata difficile quindi potresti essere un amico e fare con la vodka?"

Il barista dice "Certo, amico. Aspetta."

Torna un momento dopo, visibilmente leggermente meno felice di quando se ne andò, e dice all'anatra: "Sembra che siamo tutti fuori dalle cose buone. Tutto ciò che ci rimane è Skyy. Funzionerà?"

L'anatra salta sul bancone, afferra il barista per il colletto con un'ala (in qualche modo), estrae un coltello, beh, da qualche parte con l'altra ala, e dice, piuttosto lentamente, piano, ma chiaramente, "I. Will . Taglia. Tu. "

Il barista, in preda al panico, dice "Ehi amico, è il database. È lento. Non risponde."

L'anatra, un po 'confusa sul fatto che dovesse o meno finire il barista - proprio qui, proprio ora - lo abbaia rabbiosamente, "Il database? Di che diavolo stai parlando?"

Il barista, ora singhiozzando, sbuffa, "Non lo so ... C'è qualche blocco in corso? .. È proprio quello che diciamo ... Puoi provare a ricostruire gli indici o qualcosa del genere? ... sai, quando non sappiamo cos'altro dire .... forse dovremmo aggiungere più memoria al server ... pensi che possa aiutare? ... tutti sanno che il codice dell'app è veloce e i database sono il collo di bottiglia .. ..Ehi, ho sentito parlare di questi database NoSQL che sono <air-quotes> web-scale </air-quotes> e di solito sono Open Source, quindi sono gratuiti e simili, Twitter, Google e il Facebook tutti usano quella roba poiché i database relazionali sono praticamente in procinto di uscire ".

E con ciò, l'anatra aveva deciso ...........

Hmm. Bene, fidati di me, è molto più divertente nell'originale ungherese.

Ma ancora, perché la reazione iniziale di così tante persone, quando un sistema rallenta, suppone che si tratti del database? Come se il codice dell'app non potesse essere scritto in modo orribile o avesse semplicemente dei bug? Le cose che rallentano potrebbero sicuramente essere il database. Ma semplicemente bloccare / congelare? Questo non mi sembra un problema specifico del database.

Quello che sembra è forse un codice app che non rilascia correttamente risorse esterne (socket di rete, handle di file system, ecc.). Se stiamo parlando di un'applicazione .NET, a volte gli sviluppatori dimenticano correttamente Dispose()degli oggetti che hanno risorse non gestite associate. Ad esempio: apertura di un SqlConnectionoggetto. Non ne ottieni una quantità infinita. Quindi, se vogliono cercare nel database, allora va bene. Ma forse, la prossima volta che il sistema si blocca, dai un'occhiata a:

SELECT sdec.*, '---' AS [---], sdes.*
FROM sys.dm_exec_connections sdec
INNER JOIN sys.dm_exec_sessions sdes
        ON sdes.session_id = sdec.session_id

Se il loro codice non sta rilasciando le connessioni, dovrebbe essere abbastanza ovvio se ci sono troppe connessioni, specialmente se molte hanno lunghi tempi di inattività.

E forse questa roba è già stata controllata e semplicemente non divulgata nella domanda. Ma mi sembra piuttosto strano che siano così concentrati su indici e frammentazione. Certo, ci sono problemi di sniffing dei parametri che a volte fanno sì che una o alcune procedure memorizzate richiedano un TEMPO VERAMENTE ＬＯＮＧ, ma bloccano un'intera applicazione? Non lo sto acquistando, soprattutto se non vedi una query in esecuzione e che occupa molte risorse, blocchi o tempi in cui ciò accade.

Quindi, "di cui fidarsi?" Certamente non questo venditore ;-).

Una cosa che puoi esaminare per vedere se gli indici devono essere riorganizzati o ricostruiti, è usare questa query:

declare @strBD nvarchar(50)

set @strBD = N'Tu_BD';

select table = OBJECT_NAME(object_id, database_id)
    ,index = index_id
    ,Index_Type = index_type_desc
    ,Logic_Frag = avg_fragmentation_in_percent
    ,Action = case 
        when avg_fragmentation_in_percent < 30.0
            then 'ALTER INDEX REORGANIZE'
        else 'ALTER INDEX REBUILD WITH (ONLINE = ON)'
        end
from sys.dm_db_index_physical_stats(DB_ID(@strBD), null, null, null, 'LIMITED');

Sostituisci @strBDcon your database name.

Secondo i risultati, procedere come indicato in https://msdn.microsoft.com/en-us/library/ms189858(v=sql.110).aspx . Questo collegamento è per la versione 2012 di SQL Server; selezionare la versione corretta per procedere correttamente.

Come qualcuno ha commentato, è meglio dire al proprio fornitore che rivedere e correggere, oltre il "problema di frammentazione". Forse identificando alcune query e piani di esecuzione con un'acquisizione di SQL Profiler.