Discussion :

[Népomucène]

Bonjour.

J'ai 3 serveurs SQL 2000 qui tournent 24/24 sauf le Week-end.
Ces 3 serveurs échangent directement des données par des connexions "Serveurs liés".

Bien entendu, un des 3 serveurs est en train de lâcher et après bien des négociations,
j'ai enfin obtenu qu'il soit remplacé par une machine récente avec SQL2016.

2 gros problèmes :

1) A l'évidence on ne peut pas restaurer des sauvegardes SQL2000 sur du SQL2016. Pareil si je veux attacher une base SQL2000 au serveur SQL2016.
Donc, je suppose que je n'ai pas d'autre solution que d'exporter les données dans des fichiers plats et de les importer dans une base SQL2016 ?
Si quelqu'un a connaissance d'un outil-miracle, je suis preneur.

2) Sur SQL2016 je n'arrive pas non plus à faire un serveur lié avec un SQL2000. Pareil dans l'autre sens.
Je m'y prends probablement comme un manche car mon boulot c'est le développement et pas DBA. Quelqu'un pourrait-il me mettre sur la piste ?

Le second problème est celui qui me préoccupe le plus car malheureusement, il n'est pas possible de migrer tous les serveurs vers SQL2016.

[janlouk]

1) A l'évidence on ne peut pas restaurer des sauvegardes SQL2000 sur du SQL2016. Pareil si je veux attacher une base SQL2000 au serveur SQL2016.
Donc, je suppose que je n'ai pas d'autre solution que d'exporter les données dans des fichiers plats et de les importer dans une base SQL2016 ?
Si quelqu'un a connaissance d'un outil-miracle, je suis preneur.

Tu peux passer par une instance 2008 R2, et ensuite tu repasses la DB sur le 2016. Bien sûr, il faut pouvoir avoir à disponibilité une instance 2008R2.

[Népomucène]

Je vais tester avec un backup / restore sur une petite base déjà.

[SQLpro]

Tu peux passer par une instance 2008 R2, et ensuite tu repasses la DB sur le 2016. Bien sûr, il faut pouvoir avoir à disponibilité une instance 2008R2.

Vous pouvez téléchargez n'importe quelle version de SQL Server gratuitement à l'essai pendant 180 jours.... Cela permet de voir venir.

Mieux... Lorsque vous achetez une licence, vous avez droit d'installer n'importe quelle version rétrograde en exploitation.

Vous pouvez donc au choix :
1) mettre en place une version intermédiaire 2008 ou 2008R2 pour faire une migration en 2 bonds
2) installer votre base sur la version 2008 ou 2008R2, puis migrer votre instance de 2008/2008R2 en 2016 par écrasement

A +

[Népomucène]

Merci ! il y a un serveur de comptabilité qui est en SQL2008. je vais tester cela.

Sinon pour connecter SQL2000 avec SQL2016, auriez-vous une idée ?

[Népomucène]

La restauration de la base SQL2000 sur le serveur SQL 2008 a bien fonctionné.

Sur le serveur 2008, est-ce que je dois changer le niveau de compatibilité de la base
en le passant en "compatible 2008" avant de faire une sauvegarde destinée au serveur 2016 ?

[elsuket]

Bonjour,

Intuitivement je dirai que oui, mais ça vaut le coup de tester : au pire le RESTORE plantera rapidement

@++

[Népomucène]

Je fais 2 sauvegardes : avec et sans ...
Je dois changer de site pour faire la restauration et ce soir je te dirais si ton intuition est bonne ...
(au fait on doit écrire restoration ou restauration ?)

Une fois définitivement installé sur SQL2016, je suppose qu'il est mieux de spécifier un niveau de compatibilité SQL2016 ?

[SQLpro]

Je fais 2 sauvegardes : avec et sans ...
Je dois changer de site pour faire la restauration et ce soir je te dirais si ton intuition est bonne ...
(au fait on doit écrire restoration ou restauration ?)

Une fois définitivement installé sur SQL2016, je suppose qu'il est mieux de spécifier un niveau de compatibilité SQL2016 ?

La rétro compatibilité 2000 n'est pas possible sur un serveur supérieur à 2008R2. En revanche la rétro compatibilité 2005 à 2014 est possible sur un serveur 2016. Moralité, passez votre base en compatibilité 2008 ur le serveur 2008.

Évidemment, ce serait son d'avoir un serveur 2016 et de ne pas profiter de toutes les fonctionnalités ! DOnc passez en compatibilité 2016 !

Enfin pourquoi ne pas rassembler vos 3 serveurs 2000 en un seul serveur 2016 ?

SQL Server supporte parfaitement la charge de plusieurs milliers d'utilisateur et plusieurs To de données. Donc, soyez malin, faites des économies !!!

A +

[Népomucène]

on a un traitement très lourd : importation de gros fichiers plats et mise en forme dans plusieurs tables
que j'ai installé sur un petit serveur 2000 secondaire.
quand le traitement est fait, il l'envoie sur le gros serveur de production.

J'avais fait cela en 2004 pour ne pas mettre à genou le gros serveur.

Est-ce que SQL2016 est plus performant en soit que 2000 ? (oui, je sais, ça a l'air idiot comme question, mais bon ...)

[Bernardos]

Est-ce que SQL2016 est plus performant en soit que 2000 ? (oui, je sais, ça a l'air idiot comme question, mais bon ...)

oui c'est relativement idiot comme question
Microsoft améliore continuellement les performances de sql server. Donc sans aucun doute sql server 2016 est plus peformant. et le support initial pour sql server 2000 a été arrété le 08/04/2008 et le support étendu le 09/04/2013.
et puis le nouveau serveur sur le quel tu as installé ton 2016 a une configuration probablement(enfin j'espère) beaucoup plus intéressante que ton vieux serveur, non?



Mais attention, cela ne fait pas tout. si ta modélisation est pourrie, que tu fais des shrink tous les matins avec un taux d'auto croissance configuré à 1 Mo(valeur par défaut) pour les data et 10% pour les log, que ta base est sur ou sous indexée, que ton stockage est pourri,...enfin si tout ca, ben tu ne profiteras peut -être pas du gain de performance amené par le passage à 2016 et par le fait d'avoir une machine plus moderne et plus puissante.

Cordialement,

[Népomucène]

Bonjour,

Intuitivement je dirai que oui, mais ça vaut le coup de tester : au pire le RESTORE plantera rapidement

@++

La restauration sur SQL2016 a fonctionné dans les deux cas de sauvegarde, je récupère toujours une base compatible 2008.
Du coup, je la passe en compatible SQL2016 (format 130 de mémoire)

J'ai l'impression que cela n'affecte pas les données mais plutôt la façon de les traiter (utilisation de Thread ...) ?

[Népomucène]

Mais attention, cela ne fait pas tout. si ta modélisation est pourrie, que tu fais des shrink tous les matins

Non, chaque procédure stockée est rigoureusement optimisée avec toute une série de tests (chrono, conso, etc.)
Avec SQL2000 j'ai tout fait à la mano jusqu'à ce que les temps de réponse soient satisfaisant.

Maintenant, chaque jour avec SQL2000 il fallait faire un BACKUP LOG WITH TRUNCATE_ONLY car je n'ai pas trouvé d'autre moyen de contrer l'augmentation terrifiante de la taille du journal.
Je suppose qu'il y a de meilleures pratiques ?

[SQLpro]

J'ai l'impression que cela n'affecte pas les données mais plutôt la façon de les traiter (utilisation de Thread ...) ?

En fait aucune données ni aucun objet de la base (procédures stockées, vue, UDF, déclencheurs...) n'est modifié.
En revanche les tables système sont profondément remaniées et le moteur de stockage accepte des nouveaux types de données :

• VARCHAR(max)
• NVARCHAR(max)
• VARBINARY(max)
• UNIQUEIDENTIFIER
• XML
• HIERARCHYID
• GEOMETRY
• GEOGRAPHY
• ROWVERSION
• DATE
• TIME
• DATETIME2
• DATETIMEOFFSET

ATTENTION : certains types sont obsolètes ou dépréciés :
TEXT
NTEXT
IMAGE
DATETIME
TIMESTAMP

Les jointures externes *=, =* et *=* provoquent des erreurs de syntaxe.

Les vues ayant des ORDER BY combinées à l'aide de TOP ne présentent plus les données de manière ordonnée...

Il existe bien d'autres limitations et si vous en voulez la liste exhaustive il existe un assistant de migration spécifique pour débusquer toutes les horreurs que votre base pourrait contenir !

A +

[Népomucène]

DATETIME n'est plus utilisable ?

[SQLpro]

DATETIME n'est plus utilisable ?

Il est déconseillé car entâché d'une imprécision de 3 ms qui pose de multiples problèmes aussi bien dans les requêtes (résultats potentiellement faux) que pour les jointures (nécessité d'activer le "date time correlation optimisation" au niveau de la base pour tenter d'en corriger les effets).

Mieux vaudrait changer ce type de données par un DATETIME2(3) lorsque vous avez réellement un DATETIME contenant date et heure, sinon par un DATE si vous ne voulez que la date, sinon TIME si vous ne voulez que la partie DATE.

Ceci se fait via :

Code :

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

ALTER TABLE MaTable ALTER COLUMN MaColonne MonNouveautype

A +

[Népomucène]

Ah OK merci pour cette indication

J'avais déjà constaté empiriquement cette imprécision.

Je me sers du DateTime pour enregistrer les moments des étapes de production d'un article.
le niveau de précision "à la seconde près" est suffisant.
Après, les statistiques de quantités produites sont "heure par heure"

Pour le moment, je pense ne rien changer : je dois avoir quelques 7.000 lignes de Transaq sql !

[Bernardos]

Maintenant, chaque jour avec SQL2000 il fallait faire un BACKUP LOG WITH TRUNCATE_ONLY car je n'ai pas trouvé d'autre moyen de contrer l'augmentation terrifiante de la taille du journal.
Je suppose qu'il y a de meilleures pratiques ?

oulaaaa, pas bien ca! de 2 choses l'une soit ton fichier log grossit de manière anormal et tu dois corriger la cause. soit c'est le comportement normal.
Ton fichier log peut grossir indéfiniment si ton mode de récupération est défini à "full" sans que tu fasses des sauvegardes du journal de transactions (je vois ça très souvent)
la commande

Code :

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

BACKUP LOG WITH TRUNCATE_ONLY

fait un faux backup(en fait il ne sauvegarde rien du tout).
donc si tel le cas chez toi, pose toi la question. as tu besoin de sauvegarder le journal de transaction ou non?

• si oui, mode de récupération = complet avec un stratégie de backup incluant une sauvegarde régulière du journal de transactions.
• si non, mode de récupération = simple

une fois que tu as supprimé les comportements "anormaux", si ton fichier log a besoin de 100 Go , c'est qu'il en aura besoin à un autre moment.
Il ne faut, en principe, jamais réduire les fichiers (que ce soit les data ou les log). tu crées de la fragmentation. d'autant plus si ton taux de croissance est petit.
il faut donc estimer la taille au plus juste et dimensionner ton fichier dès le départ à cette taille.
Il faut également prévoir les disques en conséquences.
Cordialement,

[Népomucène]

fait un faux backup(en fait il ne sauvegarde rien du tout).

Bien entendu. J'ai toujours considéré que c'était une bidouille.

si non, mode de récupération = simple

J'ai ma réponse !
Je te remercie !

[Bernardos]

Donc j'en conclus que ta/tes base(s) étai(en)t en mode complet?

Alors pour le choix d'utiliser ou non le mode complet, je t'invite à réfléchir sur le long terme. c'est une question délicate et la réponse peut être très variable.
En fait il y a 2 facteurs importants :

1. La quantité de données que tu peux te permettre de perdre : si tu peux te permettes de perdre une journée, des backup full et/ou bakcup différentiel une fois par jour suffisent. si tu ne peux pas te permettre de perdre plus d'un quart d'heure alors il faudra jouer avec sauvegardes du journal de transactions(voir peut être du miroring synchrone)
2. L'évolutivité de ta base : si tu as une bases dans laquelle tu modifies ou ajoutes 100.000.000 record par heure ou si tu as une base très consultée mais qui ne bouge plus en terme de contenu ou qui bouge une fois par mois, la refléxion ne sera pas la même

les 2 étant forcément liés.
Après, si tu veux faire du database miroring, tu es obligé de travailler en mode "complet" (ce qui en soit est logique)
Cordialement,