KB2958429 - Bogues corrigés dans SQL Server 2012 Service Pack 2

Prise en charge :

• Le message 35285 s’affiche sous la forme d’un message d’information comme prévu et non sous forme d’erreur.

Fonctionnalité:

• Sql Writer prend en charge la sauvegarde COPY_ONLY : la sauvegarde complète de Data Protection Manager (DPM) sur le serveur avec la base de données alwaysOn secondaire sera convertie en sauvegarde COPY_ONLY.

Ajout de la prise en charge du scénario de création de cube local :

• Lorsque vous utilisez SQL Server 2012 Analysis Services (SSAS 2012) SP2, vous pouvez créer un cube local qui se connecte à SSAS qui s’exécute sur un port statique autre que celui par défaut sur lequel sql Browser est désactivé. Cette nouvelle fonctionnalité est contrôlée par un nouveau paramètre de configuration dans msmdsrv.ini : « ConfigurationSettings\LocalCubeServerPortInConnectionString ». Pour activer cette fonctionnalité, définissez la valeur sur 1. Ce paramètre n’aura aucun effet si SSAS 2012 est configuré en tant que cluster de basculement ou s’exécute sur le port par défaut.

Ajoutez une journalisation supplémentaire :

• Ce Service Pack ajoute plus d’informations au fichier journal SSAS pour vous aider à améliorer la résolution des problèmes. Cela inclut la version SSAS, le nom de l’ordinateur, le nom netbios, le nombre de processeurs, la taille de la RAM, l’adresse IP, le port, le type de protocole, l’interblocage, le délai d’expiration de verrouillage et d’autres informations.

Interblocage et amélioration des performances de nettoyage de SSISDB

• Introduction

  • Interblocage dans la base de données SSISDB lors d’appels simultanés à SSISDB.catalog.create_execution procédure stockée

    • Un correctif a été effectué pour les problèmes d’interblocage et de concurrences SSISDB. Toutefois, cela ne résout pas tous les problèmes. La solution de contournement actuelle consiste à échelonner les travaux de quelques secondes. Toutefois, vous ne pouvez pas utiliser cette solution de contournement.

    • Performances médiocres sur le travail de maintenance SSISDB

  • Un correctif logiciel est disponible pour le travail de maintenance SSISDB.

• Architecture

  • Modèle précédent :

    • Chaque transaction crée un certificat et une clé symétrique, qui doivent également être stockés et traités dans des tâches de maintenance ou de nettoyage.

  • Nouveau modèle :

    • Introduisez une nouvelle ligne dans la table de propriétés de catalogue SERVER_OPERATION_ENCRYPTION_LEVEL et par défaut, PER_EXECUTION pour conserver la compatibilité descendante, la valeur peut être remplacée par PER_PROJECT en créant une clé ou une paire de certificats pour chaque projet. Un nettoyage complet est nécessaire avant de passer de PER_EXECUTION à PER_PROJECT. Deux nouvelles procédures de magasin sont introduites pour un nettoyage complet.

  • Résumé des modifications :

    • Introduction d’une nouvelle ligne dans la table de propriétés SSISDB SERVER_OPERATION_ENCRYPTION_LEVEL :

      • Seules deux valeurs sont valides (1 et 2).

      • Valeur « 1 » : valeur par défaut. Chiffré avec des clés symétriques et des certificats en fonction du niveau d’exécution. Haute sécurité, mais il peut présenter un problème de performances ou d’interblocage.

      • Valeur « 2 » : chiffrée avec des clés symétriques et des certificats en fonction du niveau du projet. Moins de sécurité, résoudre le problème de performances ou d’interblocage.

    • Introduire deux nouvelles procédures stockées (SPs) Cleanup_server_logs et cleanup_server_execution_keys

      • Les fournisseurs DEP sont conçus pour être utilisés lorsque vous modifiez le niveau de chiffrement de « 1 » à « 2 ». Vous pouvez exécuter Cleanup_server_logs premier qui peut être terminé très rapidement pour mettre SSISDB dans un bon état. La base de données SSISDB est prête à être remplacée par le niveau de chiffrement.

      • Cleanup_server_keys prend plus de temps que Cleanup_server_logs. Toutefois, il est exécuté une fois que le niveau de chiffrement est remplacé par « 2 » et s’exécute régulièrement aux heures creuses.

      • Cleanup_server_logs : propre uniquement tous les journaux d’activité des opérations.

      • Cleanup_server_execution_keys : propre clés symétriques et les certificats utilisés pour protéger les paramètres d’exécution sensibles.

      • @cleanup_flag int (in (1,2))

        • cleanup_flag = 1 : supprimer les clés symétriques et les certificats au niveau d’exécution

        • cleanup_flag = 2 : supprimer les clés symétriques et les certificats au niveau du projet (ne les supprime que si ce projet perticulaire a été supprimé et que tous les journaux d’activité des opérations liés à ce projet ont été nettoyés).

      • @delete_batch_size int = 1000

        • nombre de clés ou de certificats supprimés lors d’un appel de cette procédure de magasin.

    • Dans internal.cleanup_server_retention_window, passez delete_batch_size de 10 à 1 000.

Prise en charge facultative du nombre de lignes des variables de table pour améliorer les plans de requête :

• Si une variable de table est jointe à d’autres tables dans SQL Server, les performances peuvent être lentes en raison d’une sélection inefficace du plan de requête, car SQL Server ne prend pas en charge les statistiques ou ne suit pas le nombre de lignes dans une variable de table lors de la compilation d’un plan de requête.

• Dans SQL Server 2012 SP2, un nouvel indicateur de trace est introduit qui permet à l’optimiseur de requête d’utiliser des informations sur le nombre de lignes insérées dans une variable de table afin de sélectionner un plan de requête plus efficace. Activez l’indicateur de trace 2453 pour activer ce comportement.
  
  Notes:

  • Dans certains scénarios, l’activation de l’indicateur de trace 2453 peut entraîner une dégradation des performances, en raison d’une compilation supplémentaire nécessaire pour prendre en compte le nombre réel de lignes insérées dans une variable de table pendant l’exécution. En règle générale, vous bénéficiez de cet indicateur de trace si une variable de table a une quantité importante de lignes jointes à d’autres tables, ou si plusieurs lignes sont utilisées à l’extérieur d’un opérateur de jointure de boucle imbriquée avec un plan du côté interne qui traite un grand nombre de lignes.

  • Un comportement similaire peut être obtenu sur d’autres versions de SQL Server à l’aide de l’indicateur de requête OPTION (RECOMPILE). Toutefois, l’indicateur de requête nécessite la détection et la modification de toutes les requêtes qui souffrent d’un mauvais choix de plan en raison d’une grande quantité de travail pilotée par des variables de table, tandis que l’activation de l’indicateur de trace 2453 peut avoir un impact sur les charges de travail existantes.

Résolution des problèmes de performances améliorée pour les plans d’exécution de requêtes parallèles

• DMV sys.dm_exec_requests retourne désormais une valeur précise pour cpu_time pour les plans d’exécution de requête parallèles. STATISTICS IO diagnostics signale désormais des lectures logiques précises pour les plans d’exécution de requête parallèles.

Amélioration des diagnostics de déversement de hachage

• Si un opérateur de jointure de hachage ou d’agrégation de hachage déverse des données dans la base de données tempdb pendant l’exécution de la requête, les E/S correspondantes sont désormais signalées pour les diagnostics d’E/S STATISTICS.

Amélioration de la diagnostics de l’index de recherche en texte intégral

• Dans certains cas, il peut être difficile de comprendre comment les résultats de certaines requêtes de texte intégral sont retournés. Le sous-système de recherche en texte intégral interagit avec des analyseurs lexicaux et des listes de mots vides externes, et à la suite de cette interaction, les informations de position des mots clés d’un document peuvent être différentes de celles observées dans le texte réel. Cela est très pertinent lorsque vous effectuez des recherches « expression » ou « NEAR », car le delta entre les mots est utilisé dans les calculs internes pour rechercher les documents correspondants.

• Dans SQL Server 2012 SP2, une nouvelle fonction de gestion dynamique (DMF) a été ajoutée pour permettre l’accès aux informations de positionnement des mots clés indexés dans un document. La nouvelle DMF est similaire à la sys.dm_fts_index_keywords_by_document DMF existante et a la syntaxe suivante :sys.
  dm_fts_index_keywords_position_by_document (
  DB_ID('database_name'), OBJECT_ID('table_name')
  )

• Au lieu du nombre d’occurrences, il retourne des informations sur chaque occurrence et sa position dans le document indexé.

• Ces informations peuvent être utilisées pour examiner le mappage entre le texte et l’index interne qui montre la différence de delta, le cas échéant, pour l’expression de recherche. Cela peut aider à comprendre les résultats de la recherche d’expressions.

Prise en charge

• Réplication transactionnelle :

  • Message détaillé ajouté aux statistiques dans les tables d’historique et messages plus détaillés dans les journaux de l’agent :

    • Ajout d’un message texte aux statistiques <> sortie xml pour définir différents états dans les agents logreader et de distribution.

    • Ajout de statistiques au niveau de l’article pour les commandes paramétrables du serveur de distribution et du logreader.

    • Ajout du nombre de commandes ignorées au fichier de sortie dans l’agent du serveur de distribution.

    • Ajout du temps passé à apporter des modifications de schéma dans l’agent de distribution.

  • LogReader : les enregistrements de journal sont ajoutés dans .TXT fichier lorsqu’un vidage utilisateur est capturé.

  • Pair à pair : les procédures d’insertion, de mise à jour et de suppression sont mises à jour pour fournir les détails ci-dessous au message de conflit :

    • Nom de la table

    • Nom et valeurs de la colonne clé primaire

    • Version actuelle

    • Préversion

    • Post-version

• Réplication de fusion :

  • Sortie de l’indicateur de trace 101 qui est ajouté dans le fichier journal lorsque le niveau détaillé de sortie pour l’agent de fusion est défini sur 4.

Fonctionnalité

• Réplication transactionnelle :

  • La réplication d’égal à égal prend désormais en charge les mises à jour partielles apportées à la colonne de texte à l’aide de Update ou de . Sémantique d’écriture.

• Réplication de fusion :

  • La procédure stockée de nettoyage a été repensée pour éviter le chargement redondant de données.

Journalisation des messages avec des erreurs de traitement et des avertissements pour empêcher les appels courants à CSS, rapports HTML volumineux.

• Aperçu:

  • Détection de la conception de rapport pour déterminer si la conception du rapport génère un rapport HTML volumineux et peut entraîner des problèmes de performances. Cela doit être facilement détecté en examinant les paramètres Hauteur et Largeur de la page interactive.

• Scénario utilisateur :

  • Vous créez un rapport dans le Report Builder. Vous entrez la valeur « 0 » dans la propriété InteractiveSize. Vous recevez une fenêtre contextuelle qui contient l’avertissement de message suivant concernant l’impact potentiel sur les performances :

    La définition de l’heigth interactif sur 0 mat ont un impact sur les performances.

Améliorations des performances

• Plusieurs améliorations des performances dans Service Pack 2, comme décrit dans les articles suivants :

  • Des problèmes de performances se produisent lorsque l’activité de verrouillage de base de données augmente dans SQL Server 2012

  • Des problèmes de performances se produisent dans les environnements NUMA pendant le traitement des pages étrangères dans SQL Server 2012

  • Les performances diminuent après un ALTER INDEX... L’opération ONLINE est abandonnée dans SQL Server 2012

• Améliorations apportées à la vue DMV

  • sys.dm_db_session_space_usage reflète la quantité d’espace nécessaire dans la base de données tempdb par objet utilisateur par session. Lorsque le nombre de lignes supprimées dépasse 1 024 pages, l’allocation de ces pages est différée. Dans SQL Server Service Pack 2012 2012, la DMV inclut également l’utilisation de l’espace pour les unités d’allocation qui sont différées dans une nouvelle colonne appelée user_objects_deferred_dealloc_page_count.

  • sys.dm_server_services spécifiez maintenant correctement le nom du nœud dans cluster_nodename colonne si SQL Server est installé sur un cluster de basculement.

• Améliorations apportées à la mémoire tampon en anneau

  • La mémoire tampon en anneau des domaines d’application RING_BUFFER_CLRAPPDOMAIN inclut la raison pour laquelle le domaine d’application a été déchargé dans le champ> <DoomReason :

    • 1 = déchargé par les opérations DDL telles que l’assembly de suppression.

    • 2 = déchargé par une opération liée à la sécurité telle que la modification de l’autorisation.

    • 3 = déchargé en raison de la gestion de la pression de la mémoire.

    • 4 = déchargé en raison d’un échec d’initialisation.

  • Le app_domain_ring_buffer_recorded d’événement étendu correspondant inclut la raison du déchargement dans doom_reason champ de données d’événement.

  • RING_BUFFER_RESOURCE_MONITOR a des entrées lorsqu’une modification est détectée dans l’état surveillé par Resource Monitor. En outre, pour les notifications de ressources système et de processus, les notifications de pool sont également disponibles dans le nœud>> </IndicatorsPool <.

  • Resource_monitor_ring_buffer_recorded événement étendu inclut des notifications à l’échelle du pool dans le champ de données pool_indicators.

  • RING_BUFFER_NONYIELD_PROCESSTABLE inclut le nom du processus en plus d’autres informations jusqu’à 8192 threads qui s’exécutent dans le système au moment de l’enregistrement de l’entrée de mémoire tampon en anneau.

• Améliorations apportées à la sauvegarde et à la restauration

  • La sauvegarde du journal de fin du modèle avec l’option norecovery n’est plus autorisée à partir du Service Pack 2.

  • Les messages d’achèvement de la sauvegarde et de la restauration dans le journal des erreurs incluent des informations sur la durée et le débit :

    • BACKUP DATABASE a traité 298 pages en 0,026 seconde (89,261 Mo/seconde).

    • RESTORE DATABASE a traité 298 pages en 0,016 seconde (145,050 Mo/seconde).

• Événements étendus

  • Les événements étendus suivants ont été ajoutés ou modifiés dans SQL Server Service Pack 2 2012 :

    • Allocation de mémoire :

      • Les événements étendus page_allocated et page_freed peuvent être utilisés pour voir les principaux consommateurs de mémoire SQL Server. À compter du Service Pack 2, ces événements étendus signalent également la mémoire réservée qui est allouée et libérée pendant l’exécution de la requête.

    • Nettoyage des fantômes :

      • Lorsqu’un enregistrement est supprimé dans une table ou un index, une telle opération de suppression ne supprime jamais physiquement les enregistrements des pages, elle les marque uniquement comme ayant été supprimés ou fantômes. Il s’agit d’une optimisation des performances qui permet aux opérations de suppression de se terminer plus rapidement. Une tâche en arrière-plan appelée tâche de nettoyage fantôme supprime ensuite physiquement tous les enregistrements supprimés. Plusieurs événements étendus ont été ajoutés dans Service Pack 2 pour fournir des insights sur les différentes phases de cette tâche :

        • ghost_cleanup_task_start

        • ghost_cleanup_task_suspend

        • ghost_cleanup_task_packet_enqueue

        • ghost_cleanup_task_process_packet

        • ghost_cleanup_task_process_pages_for_db_packet