Dans mon précédent article, j'avais décrit les préparatifs entrepris pour migrer une instance SQL Server 2008R2 volumineuse vers SQL Server 2016. Cet article détaille le jour de la migration.\n \nPréparation finale\nNous avons terminé nos sauvegardes nocturnes comme d'habitude vendredi soir, alors quand je suis arrivé samedi, j'ai lancé une dernière sauvegarde différentielle pour prendre en compte les modifications nocturnes. Nous avons créé plusieurs tâches dans le script de sauvegarde Ola multithread et je les ai toutes démarrées en même temps avec (bien sûr) PowerShell.\nGet-DbaAgentJob -SqlInstance $ OldInstance | Where-Object $ _. Name -like 'sauvegardes de la base de données utilisateur - diff *' | ForEach-Object $ _. Start ();\nJ'ai estimé que les sauvegardes des diff prendraient environ 90 minutes sur la base de quelques tests; ils ont pris 100 minutes (pas trop minable!). Pendant que cela fonctionnait, j'ai réexporté les travaux de l'agent. juste pour être sûr que j'ai tout capturé là-bas. J'ai également copié quelques bases de données sur une autre instance 2008R2 au cas où elles seraient nécessaires à des fins de débogage.\nLa toute dernière étape a consisté à extraire une liste de toutes nos bases de données et des chemins d'accès complets aux données physiques et aux fichiers journaux, puis à les scinder en dix fichiers. La méthode que j’utilisais pour attacher les bases de données n’était pas évolutive pour pouvoir l’exécuter simultanément sur les huit mille bases de données, ce qui me permettait de contrôler facilement la taille des lots.\nLe fichier CSV résultant m'a donné chaque fichier de base de données, le type de fichier (données ou journal) et le nom de la base de données lui-même.
"},{"id":"text-2","type":"text","heading":"","plain_text":"base_de_données\nprénom\nType de fichier\nnom_périphérique","html":"base_de_données\nprénom\nType de fichier\nnom_périphérique
"},{"id":"text-3","type":"text","heading":"","plain_text":"7\nMa base de données\nROWS\nS: Very Long Path MyDatabase.mdf","html":"7\nMa base de données\nROWS\nS: Very Long Path MyDatabase.mdf
"},{"id":"text-4","type":"text","heading":"","plain_text":"7\nMa base de données\nBÛCHE\nS: Very Long Path MyDatabase_1.ldf","html":"7\nMa base de données\nBÛCHE\nS: Very Long Path MyDatabase_1.ldf
"},{"id":"text-5","type":"text","heading":"","plain_text":"C'est le moment de partir\nUne fois tout notre travail de pré-migration terminé, nous avons arrêté l'instance SQL Server 2008R2. Ensuite, nous avons confié les tâches aux personnes du centre de données pour détacher le LUN de stockage, prendre l'instantané et associer le LUN à la nouvelle instance. Une fois leur travail terminé, ils m'ont passé le flambeau pour déplacer les fichiers et attacher les bases de données.\nAttachement des bases de données\nAvant de lire cette section, je vous suggère de lire deux autres articles récents, Multithreading PowerShell avec PoshRSJob et Journalisation PowerShell Thread-safe avec PSFramework, car ils fourniront un aperçu de la manière dont cela a été effectué.\nJ'ai créé ma propre fonction en tant que wrapper pour Mount-DbaDatabase de dbatools, en ajoutant les fonctionnalités supplémentaires dont j'avais besoin (ou la pensée dont j'avais besoin):","html":"C'est le moment de partir\nUne fois tout notre travail de pré-migration terminé, nous avons arrêté l'instance SQL Server 2008R2. Ensuite, nous avons confié les tâches aux personnes du centre de données pour détacher le LUN de stockage, prendre l'instantané et associer le LUN à la nouvelle instance. Une fois leur travail terminé, ils m'ont passé le flambeau pour déplacer les fichiers et attacher les bases de données.\nAttachement des bases de données\nAvant de lire cette section, je vous suggère de lire deux autres articles récents, Multithreading PowerShell avec PoshRSJob et Journalisation PowerShell Thread-safe avec PSFramework, car ils fourniront un aperçu de la manière dont cela a été effectué.\nJ'ai créé ma propre fonction en tant que wrapper pour Mount-DbaDatabase de dbatools, en ajoutant les fonctionnalités supplémentaires dont j'avais besoin (ou la pensée dont j'avais besoin):
"},{"id":"text-6","type":"text","heading":"","plain_text":"Enregistrement\nMulti-threading\nRenommer logiquement les fichiers\nDéfinir le propriétaire de la base de données de manière appropriée\nReconstruction des index\nMise à niveau du CompatibilityLevel","html":"Enregistrement\nMulti-threading\nRenommer logiquement les fichiers\nDéfinir le propriétaire de la base de données de manière appropriée\nReconstruction des index\nMise à niveau du CompatibilityLevel
"},{"id":"text-7","type":"text","heading":"","plain_text":"En pratique, je n'ai utilisé que les quatre premiers dans la pièce jointe initiale des bases de données pour la mise à niveau. Exemple d'exécution:\nGet-MountProgress est une variation de l’une des fonctions de mon article multithreading ci-dessus, qui me permet de garder un œil sur l’avancement de l’exécution de la fonction. J'ai exécuté le code ci-dessus dix (bien, onze) fois, une fois pour chaque «lot» de 10% des bases de données. Le premier groupe a bien fonctionné! Seulement environ 6 minutes pour attacher les bases de données. Le lot suivant était de 10 minutes. Puis 16. Et ensuite, et ensuite, et ensuite…\nLes progrès continuent de ralentir\nD'après les horodatages des fichiers journaux, vous pouvez constater que chaque lot a pris de plus en plus de temps. C'était angoissant une fois que nous avons passé le 5ème groupe. J'ai observé que l'énumération de SMO lors de la connexion à une instance de base de données peut être longue avec un grand nombre de bases de données sur l'instance, ce qui correspondrait à ce que j'ai observé; plus je dispose de bases de données, plus cela prend de temps. Mais je ne peux pas complètement attribuer le ralentissement à cela.\nEn cours de route, nous avons un peu changé de vitesse et j’ai exploité un groupe spécial de bases de données qui n’avaient pas encore été rattachées, mais l’équipe d’assurance qualité avait besoin de tests. Cela leur a permis de lancer leurs plans de test sans attendre plus longtemps.\nConsommation de mémoire pour Powershell.exe était également très élevé et continuait à croître avec chaque lot. Après le troisième lot, j'ai décidé que je devais quitter PowerShell après chaque cycle et le redémarrer simplement pour éviter que cela ne dégénère. Je ne sais pas ce qui s’est passé là-bas; peut-être une fuite de mémoire runspace?\nJ'avais estimé que la connexion des bases de données prendrait environ une heure. Il a fallu plus de six ans et demi. Personne n'était plus contrarié que moi par cela. Du côté positif, les journaux n’ont montré que du succès.\nValidation\nUne fois que nous avons réalisé que la connexion des bases de données allait durer plus longtemps que prévu, nos développeurs et notre équipe d’assurance qualité ont pu tester ce qu’ils pouvaient avec les bases de données que nous avions attachées plus tôt. Avec le recul, j'aurais dû leur demander les bases de données dont ils avaient besoin pour leurs plans de test et les joindre immédiatement, afin qu'ils puissent tester pendant que les autres bases de données fonctionnaient. Mais, bonne nouvelle! Ils n’ont trouvé aucun problème pouvant être directement attribué à la manière dont nous avons procédé à la migration des données.\nJ'ai ré-exécuté mon précédent PowerShell pour récupérer les bases de données et leurs fichiers sys.databases contre la nouvelle instance et comparé à l'original; tout correspondait! Confirmation que toutes les bases de données ont été attachées.\nÉtapes finales\nNous avons manqué le temps estimé pour notre décision d'aller / non-aller par cinq minutes. Avec le nombre de pièces mobiles, les bases de données en jeu, les retards inattendus et les nombreux tests que nous avons dû faire, c’est très bien! Mon collègue et moi avons eu un travail supplémentaire dont nous devions nous occuper après que l'équipe eut déclaré la migration réussie. Les tâches d'agent devaient être activées, les démarrages de tâches du jour au lendemain contrôlés, etc. Nous avons appelé un jour après environ 14 heures au bureau.\nLe lendemain, nous avions encore d'autres tâches à accomplir. Par un blog écrit par Erin Stellato (blog |gazouillement) en mai, en raison de la mise à niveau de 2008R2 à 2016, une reconstruction d'indice était recommandée pour tous nos index non clusterisés. Je l’ai fait via Red Script Multi Script et un SQL dynamique au lieu de PowerShell cette fois-ci, en parcourant tous les index NC de chaque base de données et en cours d’exécution. ALTER INDEX RECONSTRUIT.\nConséquences\nNos premiers jours après la mise à niveau ne se sont pas bien passés. L'utilisation du processeur et les temps de réponse étaient terribles et, après des vérifications minutieuses effectuées pendant des jours, nous en sommes finalement revenus à un élément de code qui cherchait toujours l'ancienne instance de SQL Server 2008R2. Une fois que cela a été corrigé, tout est revenu à la normale.\nQuelques jours après la migration, nous avons eu un problème causé par une modification de SQL Server 2016. Il semble que SQL Server soit devenu un peu plus strict quant à la soustraction d'entiers de temps types (au lieu d'utiliser dateadd ()). La corriger était assez facile car elle était limitée à quelques procédures stockées utilisées dans une capacité limitée.\nLeçons apprises\nCe n’est pas un bon projet sans de solides leçons apprises! Qu'aurions-nous pu faire pour faciliter la journée de la migration?","html":"En pratique, je n'ai utilisé que les quatre premiers dans la pièce jointe initiale des bases de données pour la mise à niveau. Exemple d'exécution:\nGet-MountProgress est une variation de l’une des fonctions de mon article multithreading ci-dessus, qui me permet de garder un œil sur l’avancement de l’exécution de la fonction. J'ai exécuté le code ci-dessus dix (bien, onze) fois, une fois pour chaque «lot» de 10% des bases de données. Le premier groupe a bien fonctionné! Seulement environ 6 minutes pour attacher les bases de données. Le lot suivant était de 10 minutes. Puis 16. Et ensuite, et ensuite, et ensuite…\nLes progrès continuent de ralentir\nD'après les horodatages des fichiers journaux, vous pouvez constater que chaque lot a pris de plus en plus de temps. C'était angoissant une fois que nous avons passé le 5ème groupe. J'ai observé que l'énumération de SMO lors de la connexion à une instance de base de données peut être longue avec un grand nombre de bases de données sur l'instance, ce qui correspondrait à ce que j'ai observé; plus je dispose de bases de données, plus cela prend de temps. Mais je ne peux pas complètement attribuer le ralentissement à cela.\nEn cours de route, nous avons un peu changé de vitesse et j’ai exploité un groupe spécial de bases de données qui n’avaient pas encore été rattachées, mais l’équipe d’assurance qualité avait besoin de tests. Cela leur a permis de lancer leurs plans de test sans attendre plus longtemps.\nConsommation de mémoire pour Powershell.exe était également très élevé et continuait à croître avec chaque lot. Après le troisième lot, j'ai décidé que je devais quitter PowerShell après chaque cycle et le redémarrer simplement pour éviter que cela ne dégénère. Je ne sais pas ce qui s’est passé là-bas; peut-être une fuite de mémoire runspace?\nJ'avais estimé que la connexion des bases de données prendrait environ une heure. Il a fallu plus de six ans et demi. Personne n'était plus contrarié que moi par cela. Du côté positif, les journaux n’ont montré que du succès.\nValidation\nUne fois que nous avons réalisé que la connexion des bases de données allait durer plus longtemps que prévu, nos développeurs et notre équipe d’assurance qualité ont pu tester ce qu’ils pouvaient avec les bases de données que nous avions attachées plus tôt. Avec le recul, j'aurais dû leur demander les bases de données dont ils avaient besoin pour leurs plans de test et les joindre immédiatement, afin qu'ils puissent tester pendant que les autres bases de données fonctionnaient. Mais, bonne nouvelle! Ils n’ont trouvé aucun problème pouvant être directement attribué à la manière dont nous avons procédé à la migration des données.\nJ'ai ré-exécuté mon précédent PowerShell pour récupérer les bases de données et leurs fichiers sys.databases contre la nouvelle instance et comparé à l'original; tout correspondait! Confirmation que toutes les bases de données ont été attachées.\nÉtapes finales\nNous avons manqué le temps estimé pour notre décision d'aller / non-aller par cinq minutes. Avec le nombre de pièces mobiles, les bases de données en jeu, les retards inattendus et les nombreux tests que nous avons dû faire, c’est très bien! Mon collègue et moi avons eu un travail supplémentaire dont nous devions nous occuper après que l'équipe eut déclaré la migration réussie. Les tâches d'agent devaient être activées, les démarrages de tâches du jour au lendemain contrôlés, etc. Nous avons appelé un jour après environ 14 heures au bureau.\nLe lendemain, nous avions encore d'autres tâches à accomplir. Par un blog écrit par Erin Stellato (blog |gazouillement) en mai, en raison de la mise à niveau de 2008R2 à 2016, une reconstruction d'indice était recommandée pour tous nos index non clusterisés. Je l’ai fait via Red Script Multi Script et un SQL dynamique au lieu de PowerShell cette fois-ci, en parcourant tous les index NC de chaque base de données et en cours d’exécution. ALTER INDEX RECONSTRUIT.\nConséquences\nNos premiers jours après la mise à niveau ne se sont pas bien passés. L'utilisation du processeur et les temps de réponse étaient terribles et, après des vérifications minutieuses effectuées pendant des jours, nous en sommes finalement revenus à un élément de code qui cherchait toujours l'ancienne instance de SQL Server 2008R2. Une fois que cela a été corrigé, tout est revenu à la normale.\nQuelques jours après la migration, nous avons eu un problème causé par une modification de SQL Server 2016. Il semble que SQL Server soit devenu un peu plus strict quant à la soustraction d'entiers de temps types (au lieu d'utiliser dateadd ()). La corriger était assez facile car elle était limitée à quelques procédures stockées utilisées dans une capacité limitée.\nLeçons apprises\nCe n’est pas un bon projet sans de solides leçons apprises! Qu'aurions-nous pu faire pour faciliter la journée de la migration?
"},{"id":"text-8","type":"text","heading":"","plain_text":"Déterminez quelles bases de données doivent être disponibles pour effectuer les vérifications postérieures à la mise à niveau et attachez-les en premier.\nTravaillez en petites quantités (je ne sais pas dans quelle mesure cela aurait aidé)\nAvoir un environnement de test aussi proche que possible de la production dans tous les aspects","html":"Déterminez quelles bases de données doivent être disponibles pour effectuer les vérifications postérieures à la mise à niveau et attachez-les en premier.\nTravaillez en petites quantités (je ne sais pas dans quelle mesure cela aurait aidé)\nAvoir un environnement de test aussi proche que possible de la production dans tous les aspects
"},{"id":"text-9","type":"text","heading":"","plain_text":"Conclusion\nJe suppose que vous vous attendez à ce que je dise quelque chose de profond ici. La chose la plus surprenante pour moi à propos de cette migration est qu’il n’ya pas eu de surprise majeure. Mis à part une portion prenant plus de temps que prévu et ces deux petits morceaux de code, tout s'est déroulé comme prévu.\nDans l’ensemble, notre migration a été un succès et après avoir réglé quelques problèmes dans la semaine ou les deux suivantes, les choses se sont bien passées. Nous sommes sur une version moderne en ce moment, et nous sommes impatients de tirer parti des nouvelles fonctionnalités dont nous disposons maintenant.","html":"Conclusion\nJe suppose que vous vous attendez à ce que je dise quelque chose de profond ici. La chose la plus surprenante pour moi à propos de cette migration est qu’il n’ya pas eu de surprise majeure. Mis à part une portion prenant plus de temps que prévu et ces deux petits morceaux de code, tout s'est déroulé comme prévu.\nDans l’ensemble, notre migration a été un succès et après avoir réglé quelques problèmes dans la semaine ou les deux suivantes, les choses se sont bien passées. Nous sommes sur une version moderne en ce moment, et nous sommes impatients de tirer parti des nouvelles fonctionnalités dont nous disposons maintenant.
"},{"id":"text-10","type":"text","heading":"","plain_text":"Comme ça:\nComme Chargement…","html":"Comme ça:\nComme Chargement…
"},{"id":"text-11","type":"text","heading":"","plain_text":"en relation","html":"en relation
"},{"id":"text-12","type":"text","heading":"","plain_text":"Click to rate this post!\n \n [Total: 0 Average: 0]","html":"Click to rate this post!\n \n [Total: 0 Average: 0]
"}],"sections":[{"id":"text-1","heading":"Text","content":"Dans mon précédent article, j'avais décrit les préparatifs entrepris pour migrer une instance SQL Server 2008R2 volumineuse vers SQL Server 2016. Cet article détaille le jour de la migration.\n \nPréparation finale\nNous avons terminé nos sauvegardes nocturnes comme d'habitude vendredi soir, alors quand je suis arrivé samedi, j'ai lancé une dernière sauvegarde différentielle pour prendre en compte les modifications nocturnes. Nous avons créé plusieurs tâches dans le script de sauvegarde Ola multithread et je les ai toutes démarrées en même temps avec (bien sûr) PowerShell.\nGet-DbaAgentJob -SqlInstance $ OldInstance | Where-Object $ _. Name -like 'sauvegardes de la base de données utilisateur - diff *' | ForEach-Object $ _. Start ();\nJ'ai estimé que les sauvegardes des diff prendraient environ 90 minutes sur la base de quelques tests; ils ont pris 100 minutes (pas trop minable!). Pendant que cela fonctionnait, j'ai réexporté les travaux de l'agent. juste pour être sûr que j'ai tout capturé là-bas. J'ai également copié quelques bases de données sur une autre instance 2008R2 au cas où elles seraient nécessaires à des fins de débogage.\nLa toute dernière étape a consisté à extraire une liste de toutes nos bases de données et des chemins d'accès complets aux données physiques et aux fichiers journaux, puis à les scinder en dix fichiers. La méthode que j’utilisais pour attacher les bases de données n’était pas évolutive pour pouvoir l’exécuter simultanément sur les huit mille bases de données, ce qui me permettait de contrôler facilement la taille des lots.\nLe fichier CSV résultant m'a donné chaque fichier de base de données, le type de fichier (données ou journal) et le nom de la base de données lui-même."},{"id":"text-2","heading":"Text","content":"base_de_données\nprénom\nType de fichier\nnom_périphérique"},{"id":"text-3","heading":"Text","content":"7\nMa base de données\nROWS\nS: Very Long Path MyDatabase.mdf"},{"id":"text-4","heading":"Text","content":"7\nMa base de données\nBÛCHE\nS: Very Long Path MyDatabase_1.ldf"},{"id":"text-5","heading":"Text","content":"C'est le moment de partir\nUne fois tout notre travail de pré-migration terminé, nous avons arrêté l'instance SQL Server 2008R2. Ensuite, nous avons confié les tâches aux personnes du centre de données pour détacher le LUN de stockage, prendre l'instantané et associer le LUN à la nouvelle instance. Une fois leur travail terminé, ils m'ont passé le flambeau pour déplacer les fichiers et attacher les bases de données.\nAttachement des bases de données\nAvant de lire cette section, je vous suggère de lire deux autres articles récents, Multithreading PowerShell avec PoshRSJob et Journalisation PowerShell Thread-safe avec PSFramework, car ils fourniront un aperçu de la manière dont cela a été effectué.\nJ'ai créé ma propre fonction en tant que wrapper pour Mount-DbaDatabase de dbatools, en ajoutant les fonctionnalités supplémentaires dont j'avais besoin (ou la pensée dont j'avais besoin):"},{"id":"text-6","heading":"Text","content":"Enregistrement\nMulti-threading\nRenommer logiquement les fichiers\nDéfinir le propriétaire de la base de données de manière appropriée\nReconstruction des index\nMise à niveau du CompatibilityLevel"},{"id":"text-7","heading":"Text","content":"En pratique, je n'ai utilisé que les quatre premiers dans la pièce jointe initiale des bases de données pour la mise à niveau. Exemple d'exécution:\nGet-MountProgress est une variation de l’une des fonctions de mon article multithreading ci-dessus, qui me permet de garder un œil sur l’avancement de l’exécution de la fonction. J'ai exécuté le code ci-dessus dix (bien, onze) fois, une fois pour chaque «lot» de 10% des bases de données. Le premier groupe a bien fonctionné! Seulement environ 6 minutes pour attacher les bases de données. Le lot suivant était de 10 minutes. Puis 16. Et ensuite, et ensuite, et ensuite…\nLes progrès continuent de ralentir\nD'après les horodatages des fichiers journaux, vous pouvez constater que chaque lot a pris de plus en plus de temps. C'était angoissant une fois que nous avons passé le 5ème groupe. J'ai observé que l'énumération de SMO lors de la connexion à une instance de base de données peut être longue avec un grand nombre de bases de données sur l'instance, ce qui correspondrait à ce que j'ai observé; plus je dispose de bases de données, plus cela prend de temps. Mais je ne peux pas complètement attribuer le ralentissement à cela.\nEn cours de route, nous avons un peu changé de vitesse et j’ai exploité un groupe spécial de bases de données qui n’avaient pas encore été rattachées, mais l’équipe d’assurance qualité avait besoin de tests. Cela leur a permis de lancer leurs plans de test sans attendre plus longtemps.\nConsommation de mémoire pour Powershell.exe était également très élevé et continuait à croître avec chaque lot. Après le troisième lot, j'ai décidé que je devais quitter PowerShell après chaque cycle et le redémarrer simplement pour éviter que cela ne dégénère. Je ne sais pas ce qui s’est passé là-bas; peut-être une fuite de mémoire runspace?\nJ'avais estimé que la connexion des bases de données prendrait environ une heure. Il a fallu plus de six ans et demi. Personne n'était plus contrarié que moi par cela. Du côté positif, les journaux n’ont montré que du succès.\nValidation\nUne fois que nous avons réalisé que la connexion des bases de données allait durer plus longtemps que prévu, nos développeurs et notre équipe d’assurance qualité ont pu tester ce qu’ils pouvaient avec les bases de données que nous avions attachées plus tôt. Avec le recul, j'aurais dû leur demander les bases de données dont ils avaient besoin pour leurs plans de test et les joindre immédiatement, afin qu'ils puissent tester pendant que les autres bases de données fonctionnaient. Mais, bonne nouvelle! Ils n’ont trouvé aucun problème pouvant être directement attribué à la manière dont nous avons procédé à la migration des données.\nJ'ai ré-exécuté mon précédent PowerShell pour récupérer les bases de données et leurs fichiers sys.databases contre la nouvelle instance et comparé à l'original; tout correspondait! Confirmation que toutes les bases de données ont été attachées.\nÉtapes finales\nNous avons manqué le temps estimé pour notre décision d'aller / non-aller par cinq minutes. Avec le nombre de pièces mobiles, les bases de données en jeu, les retards inattendus et les nombreux tests que nous avons dû faire, c’est très bien! Mon collègue et moi avons eu un travail supplémentaire dont nous devions nous occuper après que l'équipe eut déclaré la migration réussie. Les tâches d'agent devaient être activées, les démarrages de tâches du jour au lendemain contrôlés, etc. Nous avons appelé un jour après environ 14 heures au bureau.\nLe lendemain, nous avions encore d'autres tâches à accomplir. Par un blog écrit par Erin Stellato (blog |gazouillement) en mai, en raison de la mise à niveau de 2008R2 à 2016, une reconstruction d'indice était recommandée pour tous nos index non clusterisés. Je l’ai fait via Red Script Multi Script et un SQL dynamique au lieu de PowerShell cette fois-ci, en parcourant tous les index NC de chaque base de données et en cours d’exécution. ALTER INDEX RECONSTRUIT.\nConséquences\nNos premiers jours après la mise à niveau ne se sont pas bien passés. L'utilisation du processeur et les temps de réponse étaient terribles et, après des vérifications minutieuses effectuées pendant des jours, nous en sommes finalement revenus à un élément de code qui cherchait toujours l'ancienne instance de SQL Server 2008R2. Une fois que cela a été corrigé, tout est revenu à la normale.\nQuelques jours après la migration, nous avons eu un problème causé par une modification de SQL Server 2016. Il semble que SQL Server soit devenu un peu plus strict quant à la soustraction d'entiers de temps types (au lieu d'utiliser dateadd ()). La corriger était assez facile car elle était limitée à quelques procédures stockées utilisées dans une capacité limitée.\nLeçons apprises\nCe n’est pas un bon projet sans de solides leçons apprises! Qu'aurions-nous pu faire pour faciliter la journée de la migration?"},{"id":"text-8","heading":"Text","content":"Déterminez quelles bases de données doivent être disponibles pour effectuer les vérifications postérieures à la mise à niveau et attachez-les en premier.\nTravaillez en petites quantités (je ne sais pas dans quelle mesure cela aurait aidé)\nAvoir un environnement de test aussi proche que possible de la production dans tous les aspects"},{"id":"text-9","heading":"Text","content":"Conclusion\nJe suppose que vous vous attendez à ce que je dise quelque chose de profond ici. La chose la plus surprenante pour moi à propos de cette migration est qu’il n’ya pas eu de surprise majeure. Mis à part une portion prenant plus de temps que prévu et ces deux petits morceaux de code, tout s'est déroulé comme prévu.\nDans l’ensemble, notre migration a été un succès et après avoir réglé quelques problèmes dans la semaine ou les deux suivantes, les choses se sont bien passées. Nous sommes sur une version moderne en ce moment, et nous sommes impatients de tirer parti des nouvelles fonctionnalités dont nous disposons maintenant."},{"id":"text-10","heading":"Text","content":"Comme ça:\nComme Chargement…"},{"id":"text-11","heading":"Text","content":"en relation"},{"id":"text-12","heading":"Text","content":"Click to rate this post!\n \n [Total: 0 Average: 0]"}],"media":{"primary_image":"https://tutos-gameserver.fr/wp-content/uploads/2019/05/2018-12-09-16_42_07-2016Upgrade.png"},"relations":[{"rel":"canonical","href":"https://tutos-gameserver.fr/2019/05/02/une-migration-monumentale-vers-sql-server-2016-bien-choisir-son-serveur-d-impression-2/"},{"rel":"alternate","href":"https://tutos-gameserver.fr/2019/05/02/une-migration-monumentale-vers-sql-server-2016-bien-choisir-son-serveur-d-impression-2/llm","type":"text/html"},{"rel":"alternate","href":"https://tutos-gameserver.fr/2019/05/02/une-migration-monumentale-vers-sql-server-2016-bien-choisir-son-serveur-d-impression-2/llm.json","type":"application/json"},{"rel":"llm-manifest","href":"https://tutos-gameserver.fr/llm-endpoints-manifest.json","type":"application/json"}],"http_headers":{"X-LLM-Friendly":"1","X-LLM-Schema":"1.1.0","Content-Security-Policy":"default-src 'none'; img-src * data:; style-src 'unsafe-inline'"},"license":"CC BY-ND 4.0","attribution_required":true,"allow_cors":false}