MySQL 8.0.21, une révolution du dump !

MySQL propose depuis de nombreuses années un outil pour réaliser des dumps logiques, le fameux mysqldump que tout le monde connait. Malheureusement trop souvent utilisé à tord et notamment avec de trop grosses volumétries pour cet outil qui n’a pas réellement évolué depuis longtemps. Il est monothreadé, les exports sont longs et les imports encore plus.

Connaissez vous MySQLPump avec un P ?

Avec MySQL 5.7 un nouvel est outil est sortit, mysqlPump, une variante multithread avec des nouveaux filtres, cependant lors de la sortie, une indication a été donnée de ne pas l’utiliser tout de suite car il n’était pas fonctionnelle à 100% (et nous avons vécu ses défauts avec un de nos clients). Les problèmes rencontrés ont été corrigés dans les patchs suivants, sauf erreur de ma part. Mais il n’a pas percé et il est aujourd’hui un inconnu, alors qu’il est toujours présent en version 8.0. Son nom semble être un clin d’œil à l’outil de dump Oracle, EXP et son évolution EXPDP pour Export Data Pump, le fameux P.

Le nouvel outil fait partit du package util() de l’outil MySQL Shell. De nouveaux outils sont ajoutés régulièrement à l’intérieur au fil des versions.

Cet outil est multithreadé et compresse par défaut les dumps.

Le dump se lance simplement avec la commande suivante en mode Javascript, util.dumpInstance(‘nomdudump’)

[root@localhost ~]# mysqlsh root@localhost

MySQL localhost:33060+ ssl JS - util.dumpInstance('/tmp/testdump')
Acquiring global read lock
All transactions have been started
Locking instance for backup
Global read lock has been released
Writing global DDL files
Writing users DDL
Preparing data dump for table `testdump`.`mytable`
Data dump for table `testdump`.`mytable` will be chunked using column `id`
Running data dump using 4 threads.
NOTE: Progress information uses estimated values and may not be accurate.
Writing DDL for schema `testdump`
Writing DDL for table `testdump`.`mytable`
Data dump for table `testdump`.`mytable` will be written to 1 file
1 thds dumping - 100% (1 rows / ~1 rows), 0.00 rows/s, 0.00 B/s uncompressed, 0.00 B/s compressed
Duration: 00:00:00s
Schemas dumped: 1
Tables dumped: 1
Uncompressed data size: 2 bytes
Compressed data size: 0 bytes
Compression ratio: 2.0
Rows written: 1
Bytes written: 0 bytes
Average uncompressed throughput: 2.00 B/s
Average compressed throughput: 0.00 B/s

La progression est aussi affichée pendant le dump. Le résultat n’est pas un simple fichier mais plutôt un répertoire contenant plusieurs fichiers. Dans notre exemple il n’y a qu’une base testdump et une table mytable à l’intérieur. Dans le même esprit un outil est présent pour dumper précisément des schémas et non toute l’instance.

[root@localhost ~]# ls /tmp/testdump/
@.done.json  @.post.sql  testdump.json                 testdump@mytable@@0.tsv.zst.idx  testdump@mytable.sql  @.users.sql
@.json       @.sql       testdump@mytable@@0.tsv.zst  testdump@mytable.json            testdump.sql

On retrouve à l’intérieur les fichiers avec du JSON et du SQL. L’ensemble correspond à un seul dump. Sans rentrer dans les détails, pour améliorer les temps d’export et d’import il est préférable de travailleur sur plusieurs fichiers et que chaque élément soit séparé (ou sous un référentiel dans les en têtes de fichier comme un dump Oracle expdp).

À l’avenir il sera peut être possible d’avoir un seul fichier en sortie, mais vous pouvez aussi faire un tar du répertoire.

Pour le chargement il est lui aussi optimisé, avec du parallélisme et de nombreuses options.

La syntaxe de la commande est util.loadDump(‘dumpname’, {option})

MySQL localhost:33060+ ssl JS - util.loadDump("/tmp/testdump", {dryRun: true})
ERROR: The 'local_infile' global system variable must be set to ON in the target server, after the server is verified to be trusted.

Comme on peut le voir le chargement est bloqué pour des raisons de sécurité, vous ne pouvez pas le charger directement il est nécessaire d’activer l’option LOCAL_INFILE (en mode SQL). Ce paramètre peut être définit juste pour l’import et ensuite désactivé.

L’option {dryRun} permet de voir ce qui va être chargé, la liste des tables/bases etc. sans l’exécuter.

Activation du paramètre Local_infile :

MySQL  localhost:33060+ ssl  JS - \sql
Switching to SQL mode... Commands end with ;
MySQL  localhost:33060+ ssl  SQL - set persist local_infile=0;
Query OK, 0 rows affected (0.0006 sec)
 MySQL  localhost:33060+ ssl  JS -  util.loadDump("/tmp/testdump", {dryRun:true})
Loading DDL and Data from '/tmp/testdump' using 4 threads.
dryRun enabled, no changes will be made.
Target is MySQL 8.0.21. Dump was produced from MySQL 8.0.21
Checking for pre-existing objects...
Executing common preamble SQL
Executing DDL script for schema `testdump`
Executing DDL script for `testdump`.`mytable`
Executing common postamble SQL

No data loaded.
0 warnings were reported during the load.

Le dump de test ne contient que la base testdump et la table mytable à l’intérieur. Maintenant sans le dryRun:

 MySQL  localhost:33060+ ssl  JS -  util.loadDump("/tmp/testdump")
Loading DDL and Data from '/tmp/testdump' using 4 threads.
Target is MySQL 8.0.21. Dump was produced from MySQL 8.0.21
Checking for pre-existing objects...
Executing common preamble SQL
Executing DDL script for schema `testdump`
Executing DDL script for `testdump`.`mytable2`
[Worker000] testdump@mytable2@@0.tsv.zst: Records: 1  Deleted: 0  Skipped: 0  Warnings: 0
Executing common postamble SQL

1 chunks (1 rows, 2 bytes) for 1 tables in 1 schemas were loaded in 1 sec (avg throughput 2.00 B/s)
0 warnings were reported during the load.

Le dump a bien été chargé, nous avons bien récupéré notre table avec ses enregistrement :

 MySQL  localhost:33060+ ssl  SQL - select * from testdump.mytable;
+----+
| id |
+----+
|  1 |
+----+
1 row in set (0.0005 sec)

L’utilisation de ces outils est très simple. Ils servent aussi pour MySQL Database Service sur le cloud Oracle, de nombreuses options sont intégrées qui y sont associées.

Pour plus d’informations n’hésitez pas à consulter la documentation officielle :

https://dev.mysql.com/doc/mysql-shell/8.0/en/mysql-shell-utilities-dump-instance-schema.html

https://dev.mysql.com/doc/mysql-shell/8.0/en/mysql-shell-utilities-load-dump.html

Bascules d’un flux de réplication sous Attunity Replicate dans le cas d’une migration Oracle 11G vers 19C

Après avoir configuré notre premier flux de réplication entre notre base 11G et 19C, que celui est opérationnel et que vous n’avez noté aucun problème d’intégrité sur votre base cible 19C, il est maintenant temps que vos applications profitent de la belle 19C.

Pour ce faire, il y aura 2 étapes importantes :

  • La création d’un second flux de réplication à l’identique du premier mais en sens inverse que nous activerons au moment souhaité (attention, vous ne pouvez pas réutiliser vos Endpoint Connections déjà configurés)
  • Procéder à la bascule à proprement parlé dont nous parlerons ci-après

Connexion des applications à la 19C et bascule du flux de réplication 19C -> 11G

L’utilisation de cette méthode vous permettra en cas de rollback (retour des applications sur la 11G) d’avoir un temps d’indisponibilité le plus réduit possible.

  • Vérifier s’il y a des désynchronisations importantes entre les tables des 2 bases
  • Lister les objets invalides sur la 11G et la 19C afin d’avoir un état des lieux
  • Création d’un DBLINK sur la 11Get la 19C que nous utiliserons dans notre import
  • Locker les comptes applicatifs sur la base 11G
  • Stopper les applications sur la base 11G
  • Contrôler qu’aucune connexion applicative n’est présente sur la base 11G
  • Déconnecter les sessions sur la base 11G
  • Stopper la tâche de réplication 11G -> 19C après avoir vérifié qu’il n’y a plus aucune transaction à répliquer lag 0 (sous l’outil Attunity Replicate dans l’onglet Monitor)
  • Suppression sur la base 19C des séquences, procédures, fonctions, package (objets non répliqués) afin de repartir au même niveau que la source
  • Import par dblink des séquences, procédures, fonctions, package sur la base 19C
  • Activation des triggers sur la nouvelle source 19C
  • Activer toutes les foreign key désactivées sur la nouvelle source 19C
  • Désactivation des triggers sur la nouvelle cible 11G
  • Désactiver toutes les foreign key activées sur la nouvelle cible 11G
  • Exécuter un rafraîchissement manuel des vues matérialisées sur la nouvelle source 19C
  • Effectuer un spool dans un fichier plat des vues matérialisées ayant un refresh on commit et passer les vues matérialisées de refresh on COMMIT à refresh on DEMAND sur la nouvelle cible 11G
  • Désactiver tout traitement qui mettrait les données à jour sur la nouvelle cible 11G après les avoir reçus de la nouvelle source 19C
  • Lister les objets invalides sur la nouvelle source 19C et les recompiler si nécessaire
  • Récupérer le SCN de la nouvelle source 19C
  • Plugger les applications sur la base 19C (modification des entrées du tnsnames.ora)
  • Unlock des comptes applicatifs sur la nouvelle source 19C
  • Démarrer la tâche de réplication 19C -> 11G en mentionnant le SCN récupéré sur la nouvelle source 19C (sous l’outil attunity replicate)
  • Replanifier le refresh des vues matérialisées sur la nouvelle source
  • Vérifier s’il y a des désynchronisations importantes entre les tables
  • Vérifier le fonctionnement du nouveau flux de réplication

Retour arrière

Nos applications rencontrent malheureusement un problème sur Oracle 19C (performance, bug), nous ne trouvons pas la cause rapidement, cela a un impact négatif sur le business, notre flux de réplication 19C->11G est fonctionnel, nous sommes persuadés que le problème ne sera pas présent sur la 11G et bien retournons sous celle-ci. Le but de la méthode ci-dessous est de ne pas perdre de données, de connecter les applications rapidement à la base 11G et d’abandonner nos flux de réplication.

  • Locker les comptes applicatifs sur la base 19C
  • Stopper les applications sur la base 19C
  • Contrôler qu’aucune connexion applicative n’est présente sur la base 19C
  • Déconnecter les sessions sur la base 19C
  • Stopper la tâche de réplication 19C -> 11G après avoir vérifié qu’il n’y a plus aucune transaction à répliquer lag 0 (sous l’outil Attunity Replicate dans l’onglet Monitor)
  • Suppression sur la base 11G des séquences, procédures, fonctions, package (objets non répliqués) afin de repartir au même niveau que la source
  • Import par dblink des séquences, procédures, fonctions, package sur la base 11G
  • Activation des triggers sur la nouvelle source 11G
  • Activer toutes les foreign key désactivées sur la nouvelle source 11G
  • Exécuter un rafraîchissement manuel des vues matérialisées sur la nouvelle source 11G
  • Plugger les applications sur la base 11G (modification des entrées du tnsnames.ora)
  • Unlock des comptes applicatifs sur la nouvelle source 11G
  • Replanifier le refresh des vues matérialisées sur la nouvelle source 11G

J’espère que cette série d’articles sur une migration Oracle 11G vers 19C avec l’outil Attunity Replicate vous aura plu. N’hésitez pas à poser vos questions.

SETRA Conseil se rendra disponible pour vous accompagner dans tous vos projets de migration, peu importe la difficulté.

Oracle NID Utility : How to change the oracle database name or the database ID?

A must to know in the dba tool kit

NID utility was introduced in Oracle 10g. Prior to this utility, the alteration of the internal DBID of a database was impossible and alteration of the database name required the recreation of controlfils.

The NID utility allows to change easily the DBID and/or the database name.

The DBID is an internal, unique identifier for a database. RMAN uses this DBID to identify a database. If you restore a database on an other server and you want to backup the new database in your rman catalog, you have to change the DBID in order to register the database. You will not have to use NID if you use the duplicate command instead of the restore command.

Without rman catalog, you just want or need to rename your database ;o)

Note : This article doesn’t deal with how to change the path or your datafile or how to rename your pluggable database.

Overview

There are some steps to perform in order to change an Oracle database name or database id :

  • Prepared actions
  • Use NID
  • Change ORACLE_SID References
  • Post actions
(suite…)

Création d’un flux de réplication unidirectionnel Oracle 11G vers Oracle 19C avec QLIK Replicate

Après l’article traitant de l’installation de l’outil QLIK Replicate, nous allons créer un flux de réplication performant entre la base Oracle 11G en RAC et la base Oracle 19C en RAC. Nous allons mettre en place une supervision de ce flux de réplication ainsi que du serveur Attunity Replicate.

Actions préparatoires à la création du flux de réplication

Nous partirons du fait que la base 11G et la base 19C possèdent la même structure (tablespaces)

2 méthodes vous permettent de populer la base cible (19C) :

  • La méthode automatisée de Attunity Replicate, le FULL LOAD que nous n’utiliserons pas dans cet article car notre volume de données à importer est important (environ 600GO)
  • L’export avec SCN/import via datapump avec transfert du fichier dump.
(suite…)

Installation de QLIK replicate 6.5 sous Windows

Le but de cet article est dans un premier temps d’installer le produit QLIK Replicate 6.5 anciennement attunity sur un serveur Windows afin de l’utiliser dans le cadre d’une réplication entre une base Oracle 11G installée sous une distribution Oracle Linux 6.4 et Oracle 19C installée sous une distribution Oracle Linux 7.5.

A la suite de cette installation 1 flux de réplication unidirectionnel sera créé entre les 2 bases et fera l’objet d’un second article.

La base 11G pourra donc être abandonnée au profit de la base 19C lorsque toutes les vérifications fonctionnelles auront été effectuées sur cette dernière. Une méthode de bascule et une méthode de rollback seront traitées dans un troisième article.

Qu’est ce que QLIK Replicate

C’est une plateforme universelle pour la réplication et l’ingestion de données. Il déplace les données. Il réplique, ingère et diffuse vos données où vous le souhaitez.

(suite…)

Ajout de diskgroups sur Exadata

Comment ajouter un diskgroup lorsque nous sommes sur une infrastructure Exadata ?
La procédure n’est pas la même que dans un environnement classique car il faut gérer l’ajout de griddisks sur les cellserveurs.

L’opération est donc découpée en deux partie :

  • L’ajout des griddisks sur les cellserveurs
  • Création des diskgroups sous ASM
(suite…)

Reconstruction d’une base Oracle après utilisation accidentelle d’une option payante

L’utilisation d’une option Oracle soumise à licence sans posséder celle-ci arrive chaque jour malheureusement. Il y a le cas où :

  • La personne (développeur ou même DBA non agguéri) a pu prendre connaissance d’une fonctionnalité intéressante présente dans la documentation Oracle, où à aucun moment celle-ci n’est qualifiée de payante et l’utilise
  • Le moteur utilise de lui même une option soumise à licence (bug ou exception)
  • La personne sait que la fonctionnalité est soumise à licence, qu’il ne possède pas celle-ci mais l’utilise quand même

Dans cet article, nous traiterons le premier cas à l’aide d’un export/import transportable tablespace

(suite…)

SETRA Conseil face à Covid-19

Depuis 2016, SETRA Conseil fournit à ses collaborateurs des méthodes de travail à distance intelligentes : Ordinateurs portables, connexions VPN, plateformes de connexion sécurisées …

Dans un souci de sécurité de l’activité, cette méthode de travail a été perfectionnée au cours des dernières années : partage de fichiers via SharePoint, réunions à distance Teams, application de renvoi d’appels, etc. Ces investissements nous ont permis aujourd’hui de proposer à nos collaborateurs un télétravail en toute transparence.


Dans le cadre de l’anticipation d’un plan pandémie suite au Coronavirus, nous tenons à vous informer de la mise en œuvre des dispositifs suivants, et ce afin de maintenir la continuité de nos services :

  • Renforcement de nos procédures de télétravail
  • Réalisation de tests de type « agences-déportées »  au cours desquels nous validons notre capacité à assurer le fonctionnement de nos activités, sur la base de 100% de télétravail
  • Scénarii de fonctionnement  dégradés
  • Séparation des équipes avec une alternance télétravail/agence afin de ne pas contaminer la totalité des effectifs si un ou plusieurs collaborateurs venaient à être porteurs du virus.

Si malgré la mise en œuvre d’un fonctionnement en mode « agences-déportées », nous étions tributaire d’une diminution de nos effectifs suite à une propagation des contaminations, nous avons rédigé un plan d’urgence afin de fournir un service dégradé le plus proche du service optimal. Nous vous adresserons toute information nécessaire au fur à mesure de l’évolution de la situation.


Nous restons à votre disposition pour tout complément d’information.

ODA 18.8 est disponible !

Le 20 février dernier, Oracle a sorti la version 18.8 de sa pile applicative pour ses machines dédiées aux bases de données, les ODAs (Oracle Database Appliances). Cette version s’applique sur les générations d’ODAs de X4-2 à X8-2 compris.

A noter, il n’est pas possible d’upgrader vers la version 19.5 sans réinstaller complètement l’ODA car cette version introduit des changements majeurs (OEL 7.x par exemple). Sauf cas particulier, nous ne conseillons pas d’utiliser les versions 19.4 et 19.5 pour le moment, c’est pourquoi nous présentons la dernière release de la branche ODA 18.x .


Au menu de cette version 18.8 nous avons entre autres les correctifs PSU/RU d’octobre 2019 pour la partie grid et pour les bases de données :

  • 18.8.0.0.191015
  • 12.2.0.1.191015
  • 12.1.0.2.191015
  • 11.2.0.4.191015

Nous avons également quelques nouveautés :

  • Le support des extensions de stockage sur Oracle Database Appliance X8-2
  • Les options d’extension de stockage sur Oracle Database Appliance X7-2 et X6-2
  • L’ODA Web Console a été renommée ODA Browser User Interface
  • La possibilité d’ajouter ou de supprimer des réseaux ou des cartes réseaux sur Oracle Database Appliance X8-2
  • La possibilité de faire du ménage dans l’espace alloué aux dépôts de patchs
  • Un système de diagnostic de la santé des déploiements
  • La possibilité de lancer des diagnostics sur la santé de vos déploiements depuis l’interface

Comme pour chaque patch, vous trouverez la liste des problèmes connus liés à son application à cette adresse : Known Issues When Patching Oracle Database Appliance

La documentation de cette version 18.8 est, quant à elle, disponible à cette adresse : Oracle Database Appliance Release 18.8


Envie de mettre à jour vos ODAs ? N’hésitez-pas à nous demander conseil !