Risques de passer à ARITHABORT ON

Je travaille avec un fournisseur avec l'arrangement qu'il fournit l'application principale et je peux créer mes propres extensions tant que je ne modifie pas l'application principale. Il est intégré à ColdFusion et se connecte à une base de données SQL Server 2005.

Certains des rapports que j'ai créés dépendent de vues utilisant des fonctions calculées à partir des tables de base, et les rapports deviennent très lents à mesure que les tables grossissent. Pour accélérer les rapports, je souhaite utiliser des vues indexées . Mais après avoir créé une vue indexée dans mon environnement de test, l'application principale ne pouvait plus s'insérer dans les tables principales (elle a renvoyé un message d'erreur qui ARITHABORTdoit être ONlors de l'utilisation des vues indexées).

Il semble donc que pour utiliser les vues indexées, j'ai besoin d'avoir l'application de base SET ARITHABORT ONchaque fois que vous insérez / mettez à jour les tables de base. J'ai exécuté ceci dans mon environnement de test:

ALTER DATABASE MyDatabase SET ARITHABORT ON;

et cela semble bien fonctionner. Mais mon fournisseur dit que l'application ayant des milliers de requêtes, il pourrait y avoir un risque que ce paramètre casse l'une de ces requêtes, et si nous avons un futur problème de base de données inattendu, ils insisteraient pour que je rétablisse le paramètre par défaut.

Existe-t-il des requêtes réelles qui seraient interrompues SET ARITHABORT ON? Y a-t-il une situation où il serait préférable de le conserver OFF?

TL; DR Pour que mes nouvelles vues indexées fonctionnent, je dois les définir ARITHABORT ONpour l'ensemble de la base de données, mais mon fournisseur prévient que ce sera à mes risques et périls. Y a-t-il réellement un risque?

Donc, SET ARITHABORT ON dit en gros "si une erreur de division par zéro se produit ou qu'un débordement arithmétique se produit, abandonne la requête". C'est généralement un comportement souhaitable et c'est le paramètre par défaut à l'échelle de l'instance. Si cela pose des problèmes avec les requêtes de votre fournisseur, je dirais qu'il a peut-être souffert de problèmes de codage pour commencer. Je leur demanderais plus de détails sur les raisons pour lesquelles ils sont concernés ici.

De toutes les règles des vues indexées , j'appellerais cela et la plupart des règles d'options définies sont les moins controversées.

Cela devrait être défini dans les connexions qui interagissent avec la vue. Donc, vous voudriez travailler avec le fournisseur et vraiment essayer de comprendre son raisonnement et essayer de les inciter à s'engager dans ce qu'ils pensent du grand désaccord ici.

Cela dit, les vues indexées sont un peu compliquées. Ils ont d'autres règles et peuvent avoir un impact sur l'application et les hypothèses des développeurs du fournisseur lors de la construction et des tests de performances. Vous devriez vraiment avoir une conversation avec eux sur le problème commercial que vous essayez de résoudre à travers des vues indexées et les impliquer dans la conversation sur la façon de résoudre le problème.

Le risque évident lié à cette modification est que les requêtes des fournisseurs qui s'exécutaient correctement auparavant peuvent commencer à générer des erreurs ou renvoyer des résultats incorrects. Le ARITHABORTparamètre contrôle en partie si le dépassement arithmétique et les erreurs de division par zéro retournent un NULLrésultat, terminent l'instruction avec une erreur ou terminent le lot avec une erreur. La façon dont le code du fournisseur pourrait réagir au code qui génère une erreur au lieu de le renvoyer NULLn'est pas quelque chose que vous voudriez expérimenter sur un système de production :)

Cependant, le risque est plus faible si le niveau de compatibilité de votre base de données est supérieur ou égal à 90 et que les sessions s'exécutent avec SET ANSI_WARNINGS ON. Ce paramètre doit avoir été ONlorsque vous avez testé les vues indexées, mais vous devez confirmer le paramètre effectif utilisé par les connexions de votre application fournisseur. Management Studio peut très bien être configuré pour utiliser des SEToptions différentes de celles définies par le code du fournisseur lors de la connexion (et vous ne pouvez pas remplacer celles avec les valeurs par défaut de la base de données ou de l'instance). Vérifiez auprès du fournisseur et confirmez en traçant le code du fournisseur à l'aide de SQL Server Profiler.

Sans doute, le plus grand risque est que le fournisseur refuse de prendre en charge votre installation jusqu'à ce que le paramètre soit rétabli OFF, mais vous devriez toujours essayer d'encourager votre fournisseur à mettre à jour son code pour fonctionner avec les SEToptions recommandées , vous n'avez donc pas à choisir entre les performances et l'exécution d'une installation prise en charge. Une alternative est bien sûr d'exécuter des rapports sur une copie de la base de données.

-- Recommended effective settings
SET NUMERIC_ROUNDABORT OFF;
SET ARITHABORT, 
    CONCAT_NULL_YIELDS_NULL, 
    QUOTED_IDENTIFIER, 
    ANSI_NULLS, 
    ANSI_PADDING,
    ANSI_WARNINGS ON;