La trace par défaut est activée mais pas active

Lorsque je demande la configuration de la trace par défaut, elle montre activé:

exec sp_configure 'default trace enabled';
-->
name                    minimum  maximum  config_value  run_value
default trace enabled         0        1             1          1

Mais lorsque je demande sys.tracesle chemin, il renvoie un ensemble de lignes vide:

select * from sys.traces;

Qu'est-ce qui pourrait expliquer l'absence de la trace activée?

sql-server sql-server-2008-r2 trace

— Andomar
source

@AaronBertrand: select * from sys.tracesrenvoie un ensemble de

— lignes

J'ai également entendu parler de cas où la trace meurt parce que le lecteur sur lequel elle écrivait s'est rempli (et cela n'affectera pas nécessairement SQL Server sauf d'une manière perceptible / corrélable).

— Aaron Bertrand

@AaronBertrand: L'administrateur dit que le lecteur s'est rempli il y a quelques jours. Un redémarrage du service SQL Server redémarrerait-il également la trace par défaut?

— Andomar

La trace qui a été arrêtée était ma première mais elle EXEC sp_trace_setstatus @traceid = 1, @status = 0revient, The default trace cannot be stopped or modified.donc je ne suis pas sûr qu'elle puisse être arrêtée sauf s'il y a une erreur qui l'empêche de s'exécuter. Quelque chose dans les journaux d'erreurs?

— Martin Smith

@Martin c'est vrai, vous ne pouvez pas arrêter la trace par défaut manuellement.

— Aaron Bertrand

Réponses:

Je dirais qu'il existe une forte corrélation entre votre événement hors espace et la trace manquante. Notez que l' sp_configureoption vous indique simplement que la trace par défaut est activée, mais cela ne signifie pas qu'elle est en cours d'exécution ou qu'elle existe même. Notez que ce sys.tracesn'est pas une table mais une vue:

create view sys.traces as select * from OpenRowset(TABLE SYSTRACES)

Que fournit l' TABLE SYSTRACESensemble de lignes? Comment ça marche? Comment ses résultats sont-ils filtrés? Votre supposition est aussi bonne que la mienne. Il est possible que la trace soit toujours là, mais dans un état qui l'empêche d'être exposée par cette vue. Et il peut être dans un état qui l'empêche toujours d'être démarré même après le redémarrage du service.

Tout d'abord, assurez-vous que l'emplacement de la trace par défaut dispose d'un espace suffisant, le compte de service SQL Server dispose toujours des autorisations adéquates pour y écrire, vous n'êtes soumis à aucun quota d'espace, etc. Vous pouvez obtenir l'emplacement à partir du registre:

HKEY_LOCAL_MACHINE\Software\Microsoft\...YourInstance...\Setup\SQLDataRoot\

Une fois que vous êtes sûr que SQL Server doit pouvoir écrire dans ce dossier, vous pouvez désactiver et réactiver la trace par défaut:

EXEC sp_configure 'show advanced options', 1;
GO
RECONFIGURE WITH OVERRIDE;
GO
EXEC sp_configure 'default trace enabled', 0;
GO
RECONFIGURE WITH OVERRIDE;
GO
EXEC sp_configure 'default trace enabled', 1;
GO
RECONFIGURE WITH OVERRIDE;

Vous ne devriez pas avoir besoin de redémarrer le service SQL Server à ce stade, mais peut être un coup de pied final dans le pantalon de SQL Server si vous ne voyez toujours pas de ligne sys.traces. Notez que la valeur que trace_idvous obtenez n'est pas garantie de rester à 1.

— Aaron Bertrand
source

Merci, désactiver et réactiver travaillé. Je n'ai pas utilisé with override. Les journaux d'erreurs montraient en effet un événement hors espace.

— Andomar

@Andomar désolé, with overridec'est l'habitude.

— Aaron Bertrand

J'ai eu le même problème après que le lecteur se soit rempli. La trace par défaut a été activée mais pas en cours d'exécution. Le désactiver et le réactiver a fonctionné immédiatement sans arrêter les services.

— jclabonde
source