Quel est le nombre maximal d'actions liées autorisées pour un événement étendu?

Si vous ajoutez "trop" d'actions à un événement dans une session d'événement, vous recevrez cette erreur:

Msg 25639, niveau 16, état 23, ligne 1 L'événement, "[nom de l'événement]", dépasse le nombre d'actions liées autorisées.

Combien d'actions sont autorisées? Cela varie-t-il selon l'événement?

La réponse, basée sur l'expérimentation, semble être 27 pour sqlserver.rpc_completed. Mais je n'ai trouvé ce numéro sur aucune documentation Microsoft . Et cela semble varier selon les événements, car j'ai pu en obtenir 30 pour sqlserver.sql_batch_completed.

Exemple de code qui échoue:

CREATE EVENT SESSION [Test] ON SERVER 
ADD EVENT sqlserver.rpc_completed(
    ACTION(
        package0.callstack,
        package0.collect_cpu_cycle_time,
        package0.collect_current_thread_id,
        package0.collect_system_time,
        package0.event_sequence,
        package0.last_error,
        package0.process_id,
        sqlos.cpu_id,
        sqlos.numa_node_id,
        sqlos.scheduler_address,
        sqlos.scheduler_id,
        sqlos.system_thread_id,
        sqlos.task_address,
        sqlos.task_elapsed_quantum,
        sqlos.task_resource_group_id,
        sqlos.task_resource_pool_id,
        sqlos.task_time,
        sqlos.worker_address,
        sqlserver.client_app_name,
        sqlserver.client_connection_id,
        sqlserver.client_hostname,
        sqlserver.client_pid,
        sqlserver.context_info,
        sqlserver.database_id,
        sqlserver.database_name,
        sqlserver.is_system,
        sqlserver.nt_username,
        sqlserver.plan_handle))
GO
DROP EVENT SESSION [Test] ON SERVER
GO

Exemple de code qui réussit (le même sauf en excluant le dernier élément):

CREATE EVENT SESSION [Test] ON SERVER 
ADD EVENT sqlserver.rpc_completed(
    ACTION(
        package0.callstack,
        package0.collect_cpu_cycle_time,
        package0.collect_current_thread_id,
        package0.collect_system_time,
        package0.event_sequence,
        package0.last_error,
        package0.process_id,
        sqlos.cpu_id,
        sqlos.numa_node_id,
        sqlos.scheduler_address,
        sqlos.scheduler_id,
        sqlos.system_thread_id,
        sqlos.task_address,
        sqlos.task_elapsed_quantum,
        sqlos.task_resource_group_id,
        sqlos.task_resource_pool_id,
        sqlos.task_time,
        sqlos.worker_address,
        sqlserver.client_app_name,
        sqlserver.client_connection_id,
        sqlserver.client_hostname,
        sqlserver.client_pid,
        sqlserver.context_info,
        sqlserver.database_id,
        sqlserver.database_name,
        sqlserver.is_system,
        sqlserver.nt_username))
GO
DROP EVENT SESSION [Test] ON SERVER
GO

(J'ai essayé quelques actions différentes et cela ne semble pas se rapporter aux actions incluses - mais c'est peut-être basé sur un nombre total de caractères de noms d'action?)

Liste complète des actions avec lesquelles je travaillais:

package0.callstack,
package0.collect_cpu_cycle_time,
package0.collect_current_thread_id,
package0.collect_system_time,
package0.event_sequence,
package0.last_error,
package0.process_id,
sqlos.cpu_id,
sqlos.numa_node_id,
sqlos.scheduler_address,
sqlos.scheduler_id,
sqlos.system_thread_id,
sqlos.task_address,
sqlos.task_elapsed_quantum,
sqlos.task_resource_group_id,
sqlos.task_resource_pool_id,
sqlos.task_time,
sqlos.worker_address,
sqlserver.client_app_name,
sqlserver.client_connection_id,
sqlserver.client_hostname,
sqlserver.client_pid,
sqlserver.context_info,
sqlserver.database_id,
sqlserver.database_name,
sqlserver.is_system,
sqlserver.nt_username,
sqlserver.plan_handle,
sqlserver.query_hash,
sqlserver.query_hash_signed,
sqlserver.query_plan_hash,
sqlserver.query_plan_hash_signed,
sqlserver.request_id,
sqlserver.server_instance_name,
sqlserver.server_principal_name,
sqlserver.server_principal_sid,
sqlserver.session_id,
sqlserver.session_nt_username,
sqlserver.session_resource_group_id,
sqlserver.session_resource_pool_id,
sqlserver.session_server_principal_name

@@ VERSION Sortie:

Microsoft SQL Server 2016 (SP1) (KB3182545) - 13.0.4001.0 (X64) 
    Oct 28 2016 18:17:30 
    Copyright (c) Microsoft Corporation
    Developer Edition (64-bit) on Windows Server 2012 R2 Standard 6.3 <X64> (Build 9600: ) (Hypervisor)

Combien d'actions sont autorisées? Cela varie-t-il selon l'événement?

J'ai fait quelques recherches et oui, il y a une limite au nombre d'actions et d'événements qui peuvent être ajoutés à une définition d'événement étendue. Ce n'est pas une valeur "dure" mais basée sur de nombreuses entrées différentes, donc une définition qui ne fonctionne pas pourrait fonctionner avec simplement la suppression d'un seul événement ou d'une seule action dans un seul événement.

Et cela semble varier selon les événements, car j'ai pu en obtenir 30 pour sqlserver.sql_batch_completed.

Vous êtes déjà tombé sur la myriade de configurations possibles, vous savez donc que ce n'est pas entièrement basé sur le nombre d'actions. Ce n'est pas non plus spécifique à chaque événement, mais une combinaison des valeurs.

Que pouvez-vous faire?

Le premier élément est que les données de longueur variable sont le plus gros problème auquel vous allez faire face. Comment savez-vous ce qui est de longueur variable et ce qui ne l'est pas? Si vous regardez sys.dm_xe_objectsspécifiquement dans le catalogue XE certaines actions, vous verrez qu'il y en a type_nameet des type_sizecolonnes qui peuvent être utiles pour voir si vous ajoutez un tas de points de données de taille variable (taille de 0 dans la capture d'écran ci-dessous).

Maintenant, vous pensez probablement - ok c'est super mais je ne connais pas la limite magique donc ce n'est vraiment pas utile. Eh bien, c'est le cas et ce n'est pas le cas. Si vous l'examinez d'un point de vue numérique, alors oui, ce n'est pas très utile ... mais c'est une façon terrible de voir les choses. Cela devrait être considéré comme: "Suis-je en train de collecter uniquement les données dont j'ai besoin?" et dans la plupart des cas, vous ne rencontrerez jamais de problème avec cette erreur.

Si nous prenons la définition dans la question qui ne fonctionne pas, certaines des informations collectées semblent ne pas être vraiment nécessaires. Avez-vous vraiment besoin de la pile d'appels, de l'ID du thread actuel, du temps de cycle du processeur, de l'adresse du travailleur et de l'adresse du planificateur? La pile d'appels est variable, les autres sont fixes, donc en éliminant simplement la pile d'appels, vous pourriez tenir dans plus de colonnes si nécessaire. Je ne dis pas que vous en avez besoin de plus, mais vous pourriez.

Le but est de limiter la définition pour qu'elle soit aussi petite que nécessaire. Tout collecter entraînera soit des erreurs (comme vous l'avez eu ici), une lenteur du système, trop de données à analyser, voire l'arrêt du système. Ce n'est pas parce que vous le pouvez que vous le devriez. Rien n'indique que ces limites changeront ou ne changeront pas entre les versions majeures ou mineures, donc garder le véritable besoin minimum est la meilleure prévention. Veuillez ne pas cocher toutes les cases (gui) ou ajouter toutes les actions possibles.