| Les deux révisions précédentesRévision précédente | |
| issue110:migrer_depuis_vax_vms [2016/07/10 15:56] – auntiee | issue110:migrer_depuis_vax_vms [2016/07/10 16:56] (Version actuelle) – auntiee |
|---|
| L'inconvénient est que vous devez recompiler et relier tous les programmes utilisant la base de données, car ils doivent tous être avertis du changement de la disposition. Mais cela peut être fait (et testé !) avant d'exécuter la modification. | L'inconvénient est que vous devez recompiler et relier tous les programmes utilisant la base de données, car ils doivent tous être avertis du changement de la disposition. Mais cela peut être fait (et testé !) avant d'exécuter la modification. |
| |
| Quand une base de données est déchargée, vous obtenez le contenu de la base sous une forme lisible, dans un fichier texte. Si votre base de données est très grande, ce fichier texte sera aussi très grand et le processus de déchargement prendra du temps. Ceci peut être inacceptable, ce qui rend l'usage d'une base de données en réseau inadaptée à votre besoin. | Quand une base de données est déchargée, vous obtenez le contenu de la base sous une forme lisible, dans un fichier texte. Si votre base de données est très grande, ce fichier texte sera aussi très grand et le processus de déchargement prendra du temps. Ceci peut être inacceptable, ce qui rend l'usage d'une base de données réseau inadaptée à votre besoin. |
| |
| **Because the unload file is plain text, you can modify the contents of your database using a simple text editor. You can cut a large amount of records connected to one record, and paste it to a different record, in one move. This saved my ass last Christmas! | **Because the unload file is plain text, you can modify the contents of your database using a simple text editor. You can cut a large amount of records connected to one record, and paste it to a different record, in one move. This saved my ass last Christmas! |
| For the communication with the application, DBMS32 uses shared memory called the User Work Area (UWA). The application fills a part of the UWA with data, and then calls a database request, specifying what is to be done. A program called DATABASE_MANAGER handles the request, taking the data from the UWA, accessing the physical database, and puts the result back in the UWA. In the UWA there is space for exactly one record of every type, so each request to read the database can have only one result.** | For the communication with the application, DBMS32 uses shared memory called the User Work Area (UWA). The application fills a part of the UWA with data, and then calls a database request, specifying what is to be done. A program called DATABASE_MANAGER handles the request, taking the data from the UWA, accessing the physical database, and puts the result back in the UWA. In the UWA there is space for exactly one record of every type, so each request to read the database can have only one result.** |
| |
| Parce que le fichier de déchargement est en texte brut, vous pouvez modifier les enregistrements de votre base en utilisant un simple éditeur de texte. Vous pouvez couper une grande quantité d'enregistrements connectés à un enregistrement, et le coller à un autre enregistrement, d'un seul coup. Ceci a sauvé mon dernier Noël ! | Parce que le fichier de déchargement est en texte brut, vous pouvez modifier les enregistrements de votre base en utilisant un simple éditeur de texte. Vous pouvez couper une grande quantité d'enregistrements connectés à un enregistrement, et la coller à un autre enregistrement, d'un seul coup. Ceci a sauvé mon dernier Noël ! |
| |
| Pour la communication avec l'application, DBMS32 utilise de la mémoire partagée appelée User Work Area (UWA - zone de travail de l'utilisateur). L'application remplit une partie de l'UWA avec des données, et ensuite appelle une requête sur la base de données, spécifiant ce qui doit être fait. Un programme appelé DATABASE_MANAGER prend en charge cette requête, en prenant les données dans l'UWA, en accédant à la base de données physique et en mettant le résultat dans l'UWA. Dans l'UWA, il y a la place pour exactement un enregistrement de chaque type, de sorte que chaque requête pour lire la base ne peut avoir qu'un seul résultat. | Pour la communication avec l'application, DBMS32 utilise de la mémoire partagée appelée User Work Area (UWA - zone de travail de l'utilisateur). L'application remplit une partie de l'UWA avec des données, et ensuite appelle une requête sur la base de données, spécifiant ce qui doit être fait. Un programme appelé DATABASE_MANAGER prend en charge cette requête, en prenant les données dans l'UWA, en accédant à la base de données physique et en mettant le résultat dans l'UWA. Dans l'UWA, il y a la place pour exactement un enregistrement de chaque type, de sorte que chaque requête pour lire la base ne peut avoir qu'un seul résultat. |
| Mon implémentation | Mon implémentation |
| |
| DBMS32 a été créée dans les années 80. Les mémoires et les disques durs étaient chers et donc limités. Quand vous concevez une base de données utilisant DBMS32, vous devez réfléchir posément à la distribution des données dans les différents disques durs disponibles. Aujourd'hui, nous n'y faisons plus attention car l'espace disque est bon marché et abondant. Certaines spécifications du fichier de définition de la base de données d'origine sont donc obsolètes. Quand vous migrez d'un système VAX/VMS vers Linux, nous n'avez pas à retirer ces éléments, car, dans mon implémentation, ils sont simplement ignorés. Aucune modification du fichier de définition n'est nécessaire ! | DBMS32 a été créée dans les années 80. Les mémoires et les disques durs étaient chers et donc limités. Quand vous conceviez une base de données utilisant DBMS32, vous deviez réfléchir posément à la distribution des données dans les différents disques durs disponibles. Aujourd'hui, nous n'y faisons plus attention car l'espace disque est bon marché et abondant. Certaines spécifications du fichier de définition de la base de données d'origine sont donc obsolètes. Quand vous migrez d'un système VAX/VMS vers Linux, vous n'avez pas à retirer ces éléments, car, dans mon implémentation, ils sont simplement ignorés. Aucune modification du fichier de définition n'est nécessaire ! |
| |
| Les bases de données relationnelles modernes utilisent TCPIP pour la communication entre une application et la base. En plus de désolidariser l'application et la base, ceci permet de mettre la base sur un serveur séparé quelque part dans le réseau. De nombreux ordinateurs peuvent être connectés en même temps à une telle base de données. Pour utiliser DBMS32, il n'est pas nécessaire que TCPIP soit installé, et deux disques durs locaux seuls peuvent être utilisés. Dans mon implémentation, j'ai décidé de le garder tel quel. Dans DBMS32, vous assignez des groupes d'enregistrements à des « AREA » (« zones », en fait des fichiers) et, pour chaque « AREA », vous spécifiez sur quel disque et quel répertoire elle réside. Dans mon implémentation, chaque enregistrement a son propre fichier, et tous les fichiers sont sur les mêmes disque et répertoire. Il n'y a pas de DATABASE_MANAGER (gestionnaire de la base) et chaque application accède aux fichiers d'enregistrement eux-mêmes en les modélisant dans la mémoire partagée (« memory mapped files », fichiers modélisés en mémoire). La synchronisation et la préemption sont gérées via la même mémoire partagée. L'utilisation d'une mémoire partagée rend possible le contrôle par le système d'exploitation de l'assignation de la mémoire physique et la quantité de fichiers d'enregistrement qui sont en fait lus et chargés en mémoire. Ceci permet l'utilisation d'un très grand nombre d'enregistrements sans l'utilisation d'une énorme quantité de mémoire et sans temps d'accès démesurés. | Les bases de données relationnelles modernes utilisent TCPIP pour la communication entre une application et la base. En plus de désolidariser l'application et la base, ceci permet de mettre la base sur un serveur séparé quelque part dans le réseau. De nombreux ordinateurs peuvent être connectés en même temps à une telle base de données. Pour utiliser DBMS32, il n'était pas nécessaire que TCPIP soit installé, et seuls des disques durs locaux pouvaient être utilisés. Dans mon implémentation, j'ai décidé de le garder tel quel. Dans DBMS32, vous assignez des groupes d'enregistrements à des « AREA » (« zones », en fait des fichiers) et, pour chaque « AREA », vous spécifiez sur quel disque et dans quel répertoire elle réside. Dans mon implémentation, chaque enregistrement a son propre fichier, et tous les fichiers sont sur les mêmes disque et répertoire. Il n'y a pas de DATABASE_MANAGER (gestionnaire de la base) et chaque application accède aux fichiers d'enregistrement eux-mêmes en les modélisant dans la mémoire partagée (« memory mapped files », fichiers modélisés en mémoire). La synchronisation et la préemption sont gérées via la même mémoire partagée. L'utilisation d'une mémoire partagée rend possible le contrôle par le système d'exploitation de l'assignation de la mémoire physique et la quantité de fichiers d'enregistrement qui sont en fait lus et chargés en mémoire. Ceci permet l'utilisation d'un très grand nombre d'enregistrements sans l'utilisation d'une énorme quantité de mémoire et sans temps d'accès démesurés. |
| |
| **Changes to the database are also written to the journal file with a timestamp. When you create a full backup at regular intervals, and incremental backups on a smaller interval (a new journal file is created every time a backup is created), you can restore the database to any point in time on another computer. You would simply copy a set of connected files (full + incremental backup + journal file) to this computer, and restore the database up to time X. This allows for analyzing the data in the database at exactly (within a millisecond) the time a “bad thing happened”. | **Changes to the database are also written to the journal file with a timestamp. When you create a full backup at regular intervals, and incremental backups on a smaller interval (a new journal file is created every time a backup is created), you can restore the database to any point in time on another computer. You would simply copy a set of connected files (full + incremental backup + journal file) to this computer, and restore the database up to time X. This allows for analyzing the data in the database at exactly (within a millisecond) the time a “bad thing happened”. |
| Conclusion | Conclusion |
| |
| C'est la dernière partie de ma série sur la migration de VAX/VMS vers Linux. Bien que je parle du VAX, cet article est en fait aussi valable pour tous les ordinateurs utilisant openVMS, et aussi pour l'Alpha. L'impératif le plus important est que vos programmes soient écrits en Pascal. Parce que je prends ma retraite sous peu, j'ai beaucoup de temps pour vous aider si vous avez encore une ou plusieurs de ces « vieilles filles ». La migration vers Linux n'est pas très chère, l'avantage le plus important est que le résultat est prévisible. Pas de fonctionnalité « perdue pendant le transfert », pas de perte de production, pas de bug caché (sauf s'il est déjà présent...) qui vous touchera au pire moment et pas d'intrusion de hackers ou de virus pour arrêter la production. | C'est la dernière partie de ma série sur la migration de VAX/VMS vers Linux. Bien que je parle du VAX, cet article est en fait aussi valable pour tous les ordinateurs utilisant openVMS, et aussi pour l'Alpha. L'impératif le plus important est que vos programmes soient écrits en Pascal. Parce que je prends ma retraite sous peu, j'aurai beaucoup de temps pour vous aider si vous avez encore une ou plusieurs de ces « vieilles filles ». La migration vers Linux n'est pas seulement moins chère, l'avantage le plus important est que le résultat est prévisible. Pas de fonctionnalité « perdue pendant le transfert », pas de perte de production, pas de bug caché (sauf s'il est déjà présent...) qui vous touchera au pire moment et pas d'intrusion de hackers ou de virus pour arrêter la production. |
| |
| J'espère que vous avez aimé lire ma série. Si vous voulez en savoir plus sur VMS, Pascal ou DBMS32 (ou les base de données en réseau, plus généralement), vous pouvez toujours m'envoyer un mail à : info@theovanoosten.nl. | J'espère que vous avez aimé lire ma série. Si vous voulez en savoir plus sur VMS, Pascal ou DBMS32 (ou les bases de données réseau, plus généralement), vous pouvez toujours m'envoyer un mail à : info@theovanoosten.nl. |
| |
