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 ;-)

[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 ...

++