Debug di procedure memorizzate SQL sicuro per la produzione

5

Abbiamo un numero enorme di stored procedure SQL annidate e una serie di metodi diversi di debugging (che variano da sviluppatore a sviluppatore).

Finora, i nostri metodi includono:

  1. Un parametro @debug facoltativo, quello causa la procedura a print messaggi mentre viene eseguito (passando la variabile down to call procedure).

  2. Verifica @@servername contro a tabella dei nomi dei server di prova e print ing come sopra

  3. Scrivi tutto il procedimento fa a una tabella di registro (in produzione e test)

Quale di questi è preferibile (e perché), o c'è un metodo migliore che abbiamo trascurato?

    
posta Stu Pegg 14.10.2010 - 13:07
fonte

3 risposte

4

Dovresti anche prendere in considerazione SQL Server Profiler . In SQL Server Management Studio, seleziona Strumenti - > SQL Server Profiler. Quando si apre la finestra del profiler, seleziona File - > Nuova traccia ... (Non conosco le specifiche di altri RDBMS, ma devono avere strumenti con funzionalità simili.)

Come soluzione a lungo termine, dovresti ovviamente spostare la logica aziendale dalle stored procedure.

    
risposta data 14.10.2010 - 15:06
fonte
2

Preferisco il # 1 personalmente. Con un flag @debug puoi specificare se il codice di produzione viene eseguito o meno, e trovo che i messaggi di print sono una delle cose più utili da utilizzare quando cerchi di capire cosa sta succedendo.

    
risposta data 14.10.2010 - 14:40
fonte
1

Uso un flag @debug o @test come variabile di input per tutti i proc stored complessi.

Quello che faccio con esso dipende quindi dal proc. Normalmente, emetto un rollback se in modalità test. Potrei anche mostrare i risultati di vari inserti prima del rollback per vedere se quello che mi aspettavo fosse quello che ho ottenuto.

Se ho SQL dinamico che quando uso @debug e in questo caso stampo lo sql invece di eseguirlo, così posso controllare l'istruzione SQL prodotta.

Naturalmente posso avere un @ test (usato solo quando sto influenzando i dati e voglio essere sicuro di poterlo ripristinare) e un @debug (per stampare l'SQl dinamico) nello stesso proc anche se di solito non lo faccio t eseguire in entrambe le modalità contemporaneamente.

Ho anche usato un @print per stampare i passaggi mentre vado se eseguo il debug (aiuta molto a vedere dove la cosa fallisce!) o in alternativa, puoi usare una variabile table per contenere i passaggi elaborati o qualsiasi codice di errore e quindi selezionare dalla variabile table dopo il rollback quando si è in modalità test per vedere cosa è realmente successo. È anche possibile inserire i valori dalla variabile table in una tabella permanente se è necessario vedere i dati nel tempo (lo facciamo per le importazioni complesse in modo da poter mostrare al client quanto spesso i loro dati di crappy hanno rotto l'importazione e ci hanno costretto a dover fare il lavoro per risolvere il problema). È importante utilizzare una variabile table e non una tabella temporanea perché ciò rimane nell'ambito dopo il rollback, una tabella temporanea viene ripristinata.

(Nota che la tabella delle variabili temporanee della tabella è specifica per SQL Server, non so se funzionerà con altri database.)

Un profiler può anche provvedere allo sql reale che è stato inviato al database e dovrebbe essere usato specialmente se non si stanno utilizzando proc memorizzati.

    
risposta data 14.10.2010 - 16:51
fonte

Leggi altre domande sui tag