Migration SQL 2016 : L alter de vue ne fonctionne plus

Bonjour,

Sur SQL-Server 2016, un ALTER VIEW sur une vue en particulier ne fonctionne plus. Celui tourne "dans le vide". Idem pour le sp_refreshview

Je pensais la dropper et la recréer, mais je n'arrive plus non plus à la dropper.

L'on a migré de 2008 r2 à 2016 il y a deux mois environ.
Ayant des problèmes de perf sur certaines requêtes, nous sommes resté en mode de compatibilité 100.

On vient de passé en mode de compatibilité 130, avec la desactivation du nouveau moteur de cordialité.

En DEV plus de problèmes de perf, tout fonctionne correctement.

En PROD on a ce problèmes de vues qui semble «cassée»


Auriez-vous vous une idée ?


Merci d'avance

Bonsoir,

Citation:

---

Envoyé par jakdede

Je pensais la dropper et la recréer, mais je n'arrive plus non plus à la dropper.

---

Que se passe t'il lors de la tentative ? message d'erreur ?
Juste pour mon info, si on demande à SSMS de "modifier" la vue, il se passe quoi ?

Sinon, je passerais par une recréation des objets et contraintes depuis le serveur de DEV et un transfert des données depuis la PROD vers une nouvelle base.
Étrange, je n'avais jamais rencontré le cas ...

@+

bonjour,

Il y a peut-être une transaction non finalisée qui empêche la suppression.

Vous pouvez le vérifier avec sp_who2

est-ce que ça serait des vues sur des tables d'une autre bd qui n'existe plus ou bien par un Linked Server ?

ATTENTION : lorsque vous migrez de version, la première chose à faire est de :
RECALCULER TOUTES LES STATISTIQUES EN MODE FULLSCAN
Une grosse partie de vos problèmes devrait disparaître et vous pouvez réactiver le niveau 130 pour votre base ce qui autorise le nouvel estimateur de cardinalité (et no n de cordialité !!!!)

Néanmoins, pour certaines requêtes, et peut être votre vue, il est intéressant de l'étudier, si le phénomène persiste, en y ajoutant l'indicateur
OPTION (USE HINT ('FORCE_LEGACY_CARDINALITY_ESTIMATION'));

Si cela corrige votre requête, il faudrait ensuite nous en communiquer la structure et les index, afin de trouver comment la récrire et l'indexer afin que le problème ne se produise plus.

A +

PS : pourquoi faut-il recalculer les statistiques ?
Parce que, chaque version de SQL Server arrive avec des nouveaux opérateurs pour résoudre les plan d'exécution des requêtes. Les plans sont donc généralement meilleurs à de très rares exceptions près. MAIS… ces nouveaux opérateurs ont besoin de statistiques calculées différemment. Il en résulte que si vous ne faites pas ce recalcul global des statistiques en mode FULLSCAN, alors l'optimiseur va prendre des statistiques inadaptées pour réaliser un plan qu'il croit à tort optimal. Un peu comme si pour établir un plan d'investissement, le gouvernement français, prenait le recensement de la population française de 1920 pour établir le besoin en hôpitaux, maisons de retraites et école ! ….