Discussion :

[zinzineti]

Hello,
Je souhaite partager ma réflexion avec vous sur un des nombreux problèmes que l'on rencontre quand on fait un Upgrade de SQL 2000 vers SQL 2005 (SP1, SP2, SP3, ...). La question est donc celle-ci :
Qu'est ce qui justifie le fait que Microsoft décide de laisser par défaut la base master au niveau de compatibilité SQL Server 2000 (80) lorqu'on fait un Upgrade de SQL 2000 vers SQL 2005, alors que les autres bases systèmes( msdb, tempdb et model) passent bien au niveau SQL Server 2005 (COMPATIBILITY_LEVEL = 90) ?

Merci d'avance

[dbaffaleuf]

http://blogs.msdn.com/b/psssql/archi...-features.aspx

"The behavior presented in the upgrade from SQL Server 2000 to SQL Server 2005 is based on a conscious decision taken by the SQL Server product group. . The main motivation behind this is to provide a smooth upgrade process and to ensure existing applications work without encountering a problem after the upgrade. You would question why this decision applies to master database as well. Even though the best practice is not to keep user objects in the master database, many internal features and several applications in the market keep some vital information in the master database. To ensure none of this encounter a problem, the master database is also left at compatibility level 80 after an upgrade. This obviously now poses a problem for application and scripts that wants to execute in the context of the master database as well as use some of the new keywords or operators. They will now run into the problems and errors that we discussed early on."

David B.

[mikedavem]

En fait je me suis toujours demandé s'ils s'étaient basés sur des statistiques clients ou autres pour prendre cette décision ... Est ce que c'est parce que le plus grand nombre d'objets utilisateurs est trouvé dans cette base plutôt que dans msdb par exemple ?

C'est vrai que par défaut, un utilisateur se voit affecter la base master à la connexion mais bon je reste quand même certain qu'une bonne pratique est de jamais utiliser les bases systèmes pour des objets utilisateurs .. autant créer une base dédiée à cela ..

++

[dbaffaleuf]

Dans le post de Suresh il est surtout question des 3rd-parties. Je n'ai pas d'exemple en tête mais ils ont dû voir ça avec tous leurs partenaires lors des premières CTP ou en phase de dév de la 2005.

David B.

[zinzineti]

Merci dbaffaleuf pour le lien.

je trouve que leur logique (argument) est sélective. Parce que
ce qu'ils disent à propos des objets utilisateurs qui se trouvent dans la base master, peut s'appliquer aussi à la base msdb ? base msdb où des utilisateurs créent des script de maintenance !
Pourquoi ils ne sont pas aller jusqu'au bout de leur logique ?
Sur ce point je pense que MS :
1) encourage les mauvaises pratiques
2) pénalise les utilisateurs exemplaires

Je vais publier un billet à ce sujet sur mon blog ;-)

A+

[mikedavem]

1) MS encourage les mauvaises pratiques
2) Pénalise les utilisateurs exemplaires

1)
Encourager les mauvais pratiques non je ne pense pas. C'est à l'utilisateur de faire attention pas à MS à mon sens. Ils veulent surtout rendre plus facile les mises à jour de versions. (eh oui le business)

2)
Je ne vois pas de pénalité là .. c'est juste une question d'appréciation je crois

++

[dbaffaleuf]

Ils veulent surtout rendre plus facile les mises à jour de versions. (eh oui le business)

C'est exactement ça.

David B.

[zinzineti]

1)
Encourager les mauvais pratiques non je ne pense pas. C'est à l'utilisateur de faire attention pas à MS à mon sens. Ils veulent surtout rendre plus facile les mises à jour de versions. (eh oui le business)
2)
Je ne vois pas de pénalité là .. c'est juste une question d'appréciation je crois
++

Parce que quand je fais un Upgrade je me dis que je suis sous SQL 2005 et quand j'éxécute cette commande

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
SELECT TOP 20 
SUM(total_logical_reads + total_logical_writes) AS [Total ES] 
,SUM(total_logical_reads + total_logical_writes)/SUM(qs.execution_count) AS [Moyenne ES]
,DB_NAME(qt.dbid) AS [DatabaseName]
FROM sys.dm_exec_query_stats qs
CROSS APPLY sys.dm_exec_sql_text(qs.sql_handle) as qt
GROUP BY DB_NAME(qt.dbid)
ORDER BY [Total ES]  DESC;

ça me crache un message d'erreur incompréhensible !

donc c'est pénalisant car il faut encore chercher la source de l'erreur et après modifier le niveau de compatibilité. ça fait perdre du temps. Quand on fait un Upgrade, c'est évident de mettre les bases utilisateurs à niveau, ça c'est un réflexe. mais aller vérifier le compatibilité de la base master ça ce n'est pas évident !
et ça fait perdre du temps !

[dbaffaleuf]

Dans ton blog, tu peux mettre plutôt la méthode pour changer le mode de compatibilité de master, comme c'est un peu en dehors des sentiers battus.

David B.

[zinzineti]

Pourquoi ne peuvent-il pas proposer lors du Upgrade un écran du style :

Voulez-vous mettre à niveau SQL 2005 les bases :
v master
v msdb
v model
v tempdb

avec des checkbox afin de donner la possibilité à celui qui fait le upgrade de décider de ce qu'il veut !
Je préfère ça que de laisser Sql server faire tout ce qu'il veut dans mon dos ;-)

[zinzineti]

Dans ton blog, tu peux mettre plutôt la méthode pour changer le mode de compatibilité de master, comme c'est un peu en dehors des sentiers battus.
David B.

j'y ai pensé. Merci pour l'idée.

[mikedavem]

ça me crache un message d'erreur incompréhensible !

Je suis tout à fait d'accord avec toi sur ce point. C'est aller disons le : CHIANT.

c'est évident de mettre les bases utilisateurs à niveau, ça c'est un réflexe.

Là je ne suis pas d'accord avec toi ... J'ai un cas justement d'un client où le fait de passer au niveau de compatibilité par défaut de la version en cours n'était pas appropriée. Eh oui il employait encore des anciennes syntaxes de requêtes qui n'étaient pas compatibles avec le niveau 90 par exemple ... Le processus de mise à niveau a été pris en compte dans les ROAD MAP du client et la mise à niveau s'est effectuée un an après la mise à jour vers SQL Server 2005 !!

mais aller vérifier le compatibilité de la base master ça ce n'est pas évident ! et ça fait perdre du temps !

Là je suis en parti d'accord avec toi même si la documentation spécifie clairement ce qui se passe ...

++

[Ptit_Dje]

Je lisais ce post et je me disais que je n'ai jamais upgrade une instance...
En general on repart d'une installation propre et on migre.

Quels ont ete vos arguments en faveur d'un upgrade d'instance par rapport a une migration vers une nouvelle instance ?

[zinzineti]

Là je ne suis pas d'accord avec toi ... J'ai un cas justement d'un client où le fait de passer au niveau de compatibilité par défaut de la version en cours n'était pas appropriée. Eh oui il employait encore des anciennes syntaxes de requêtes qui n'étaient pas compatibles avec le niveau 90 par exemple ... Le processus de mise à niveau a été pris en compte dans les ROAD MAP du client et la mise à niveau s'est effectuée un an après la mise à jour vers SQL Server 2005 !!
++

Normalement ce travail devrait être fait en amont.
ça fait partie de la préparation à l'Upgrade.
En jouant un peu avec l'Upgrade Advisor et des requêtes
on peut identifier des prostocks ou fonctions qui ne seront pas compatible sql 2005.

[mikedavem]

C'est vrai mais dans certains cas, cette logique ne fonctionne pas. Pour mon cas, ils ont basculé SQL Server 2005 pour des questions de performance (ils en souffraient effectivement .. Microsoft avait bien fait sa COM ).

En jouant avec le niveau de compatibilité cela permet de souffler un peu on va dire ... Cette même fonctionnalité permettait également de prévoir une road map dans le tems pour effectuer un projet de mise à jour du code incriminé. (Attention je parle d'une base possédant à peu près 8000 procédures stockée à modifier). Malheureusement il faut également assurer les mises à jour applicatives de l'application qui passe bien évidemment en priorité par rapport à de la maintenance de code (eh oui encore le business) ..

Je pense que dire que cela doit être traité en amont c'est bien mais ce n'est malheureusement pas ou plus la réalité du terrain ...

++

[dbaffaleuf]

En jouant un peu avec l'Upgrade Advisor et des requêtes on peut identifier des prostocks ou fonctions qui ne seront pas compatible sql 2005.

Ça n'est pas suffisant malheureusement, parce que - et c'est pour tendre un pont vers la théorie de Fred (les bases 'épaisses') -, lorsque le code se trouve sur le serveur applicatif, il ne peut pas être testé automatiquement par SQLUA. Il faut tracer des scenarii applicatifs avec des évènements Profiler pour faire ressortir qq chose, sans garantie que ces tests soient exhaustifs.

David B.

[dbaffaleuf]

Quels ont ete vos arguments en faveur d'un upgrade d'instance par rapport a une migration vers une nouvelle instance ?

Souvent c'est un problème de sous $$$.

David B.

[mikedavem]

Envoyé par Ptit_Dje
Quels ont ete vos arguments en faveur d'un upgrade d'instance par rapport a une migration vers une nouvelle instance ?

La migration côte à côte est à mon sens bien meilleure que celle en place. Comme le dit dbaffaleuf c'est souvent une question de sous car il faut bien évidemment du matériel en plus.

++

[Ptit_Dje]

Comment tu prevois ton plan de rollback avec un upgrade ?!
Une image systeme a restaurer ?

[zinzineti]

Dans ton blog, tu peux mettre plutôt la méthode pour changer le mode de compatibilité de master, comme c'est un peu en dehors des sentiers battus.
David B.

Je viens de rédiger le billet il est disponible ici

Vos commentaires sont les bienvenus