<Desc/Clms Page number 1>
"Améliorations apportées à des svstèmes de sauvegarde de base de données et en relation avec ceux-ci" L'invention concerne la génération et la maintenance d'un système de sauvegarde de base de données dans lequel un grand nombre de millions d'éléments de données sont mémorisés en format tabulaire. Un tel système de sauvegarde doit entrer en fonctionnement lorsqu'une défaillance se produit dans un système opérationnel.
Jusqu'à présent, l'approche suivie pour la génération d'un tel système de sauvegarde consistait à utiliser deux systèmes identiques de bases de données reliés en parallèle, qui recevaient et enregistraient parallèlement les données. Dans une telle configuration, la défaillance de l'un des systèmes de bases de données entraîne la reprise des opérations de base de données par l'autre système. Lorsque le système de sauvegarde doit se situer dans un emplacement physiquement éloigné et être physiquement indépendant du système opérationnel, les frais continuels occasionnés par la communication entre les deux systèmes rendent cette approche dispendieuse.
En outre, parce qu'il possède la même configuration que le système opérationnel, le système de sauvegarde est plus cher que nécessaire si l'on tient compte du fait qu'il ne devrait être éventuellement sollicité que pour une moyenne de quelques heures par an.
La description British Patent Spécification n 2202656B (IBM)
EMI1.1
expose un procédé de reconfiguration de mémoire dans un système e
<Desc/Clms Page number 2>
de micro-ordinateur. Ce procédé semble bien être inadapté dans le cas d'un arrêt simultané de la mémoire et du processeur.
L'invention a pour objectif de fournir une méthode de génération et de maintenance d'un système de sauvegarde qui soit peu coûteux à installer et entretenir et puisse être très rapidement mis en service en cas de défaillance du système opérationnel.
Dans la présente invention. une méthode est fournie pour effectuer le transfert des données ou des programmes d'un système opérationnel de base de données informatique à un système de sauvegarde de base de données informatique et maintenir le système de sauvegarde de base de données informatique prêt à une utilisation d'urgence ; cette méthode comporte les étapes qui suivent :- conversion successive de chaque ligne de chaque module de programme du système opérationnel de base de données informatique en un format qui soit compatible avec le système de sauvegarde de base de données informatique ; transfert dans une mémoire des modules de programmes reformatés ;
EMI2.1
transfert de la mémoire à un système de sauvegarde de base de e données informatique et test du module de programme sur ce système ;
conversion au format ASCII des enregistrements de données situés dans le système opérationnel de base de données informatique ; transfert des enregistrements de données convertis au système de sauvegarde de base de données informatique et insertion des enregistrements dans des structures tabulaires pré-triées ; mémorisation d'un fichier incrémentiel dans le système opérationnel de base de données informatique :
<Desc/Clms Page number 3>
réception des données introduites dans le système opérationnel de base de données informatique, en parallèle avec la mise à jour des tables utilisant ces données et l'écriture des données dans le fichier incrémentiel ;
écriture, à intervalles réguliers, des contenus du fichier incrémentiel dans une mémoire de sauvegarde et transfert de cette mémoire dans le système de sauvegarde de base de données informatique : réalisation de brefs contrôles d'intégrité sur les tables mises à jour dans les systèmes opérationnels et de sauvegarde de base de données informatiques ; exécution de la conversion du format alphabétique au format numérique pour les caractères situés dans certaines colonnes et rangées des tables de données dans le système opérationnel comme dans le système de sauvegarde de base de données informatiques ; et réalisation de tests d'équilibrage comportant une analyse statistique des tables de données dans les deux systèmes de base de données informatique et vérification de la similitude des données mémorisées dans les deux systèmes.
Dans une réalisation de l'invention, l'étape de reformatage des
EMI3.1
données du système opérationnel de base de données informatique 1 p en vue de leur transfert dans le système de sauvegarde de base de données informatiques comporte les étapes secondaires ci-après :-
EMI3.2
vérification de l'éventuelle nécessité d'une conversion de syntaxe v et, le cas échéant, reformatage de la ligne de programme par modification de la syntaxe ;
EMI3.3
s'il est nécessaire de convertir la structure de la ligne du Z > programme, conversion de la structure dans un format apte à
<Desc/Clms Page number 4>
fonctionner sur le système opérationnel de base de données informatique : test de la ligne de programme sur le système opérationnel de base de données informatique ;
EMI4.1
après vérification, reformatage de la ligne de programme de ZD manière à ce qu'elle puisse fonctionner sur le système de sauvegarde de base de données informatique.
On comprendra plus clairement la présente invention à partir de la description ci-après de quelques-unes de ses réalisations préférentielles, qui n'est donnée qu'à titre d'exemple et en référence aux dessins d'accompagnement. dans lesquels :- la fig. 1 est une représentation schématique des systèmes opérationnel et de sauvegarde de base de données informatique selon l'invention ; la fig. 2 est un organigramme montrant la génération des données et programmes mémorisés pour le système de sauvegarde, et
EMI4.2
la fig. 3 est un diagramme montrant une méthode de e 9 maintenance du système de sauvegarde.
Si l'on se reporte aux dessins, en commençant par la fig. 1, on y trouvera l'illustration d'un système opérationnel de base de données 1 et d'un système de sauvegarde de base de données 2. Le système opérationnel de base de données 1 comporte une unité centrale 2 IBM 2200/401 reliée à plusieurs terminaux par un serveur de terminaux 3. L'unité centrale 2 est également reliée à une batterie d'unités d'entraînement de disques fixes 5 d'une capacité de 11, 4 Gb et stocke en mémoire des bases de données relationnelles. Des programmes tournant sur l'unité centrale 2 contrôlent la mémorisation des données dans les bases de données relationnelles ainsi que la génération d'états et d'autres fonctions d'un système de bases de données.
<Desc/Clms Page number 5>
Le système de sauvegarde de base de données 2 comporte un miniordinateur multi-traitement 12 doté d'un système d'exploitation UNIXTM. Le mini-ordinateur 12 possède cinq microprocesseurs 486TM tournant à 33 MHz et disposant de 256 Mb de mémoire. Les unités d'entraînement de disques fixes 13 ont une capacité de 40 Gb. La structure du mini-ordinateur 12 est modulaire, en ce sens qu'il est possible, selon les besoins, d'y ajouter ou d'en retrancher des unités centrales, des disques internes ou externes et des circuits de mémoire. Le mini-ordinateur est du type normalement utilisé dans un réseau comme serveur de réseau. Chacun des microprocesseurs Intel 486tam du mini-ordinateur 12 possède 64 K de mémoire cache interne et 256 K de mémoire cache externe.
La mémoire cache externe utilise un protocole"write back"plutôt qu'un protocole"write through". En d'autres termes, la modification est maintenue dans la mémoire cache jusqu'au moment où elle doit être remplacée, évitant ainsi les goulots d'étranglement qui peuvent survenir lors d'un traitement intensif. La totalité des circuits de mémoire et des microprocesseurs du mini-ordinateur 12 utilisent le bus de microprocesseur pour la rapidité de l'accès aux opérations de traitement et de leur contrôle.
Si l'on se reporte à présent à la fig. 2, on y trouvera l'illustration d'une méthode 20 de génération de programmes de bases de données et de chargement des programmes dans le système de sauvegarde de base de données 2. L'organigramme montre également une méthode 40 de transfert de données du système opérationnel 1 au système de sauvegarde 2. La fig. 3 expose une méthode de maintenance du système de sauvegarde 2 qui garantisse que ce dernier puisse être mis en service immédiatement et avec un minimum de discontinuité dans les opérations de la base de données en cas de défaillance du système opérationnel.
Le système opérationnel de base de données 1 peut être utilisé pour le traitement d'obligations nationales ou tout autre grand type de transactions où un fonctionnement continu revêt une grande importance.
<Desc/Clms Page number 6>
La méthode 20 comporte comme étape initiale l'analyse d'une ligne du code de programme utilisé par le système opérationnel de base de données 1. La structure de la ligne est l'instruction ou la série d'instructions qu'elle contient et qui peuvent ne s'appliquer qu'au seul système opérationnel de base de données 1. La syntaxe de la ligne consiste en la série de caractères qui y sont utilisés. A la suite de cette analyse, une décision est prise à l'étape 22 sur l'éventuelle nécessité d'effectuer une conversion de la ligne de manière à ce qu'elle puisse être utilisée pour le système de sauvegarde de base de données 2.
Dans l'affirmative, on détermine à l'étape 23 si la conversion peut se limiter à la seule syntaxe. Si tel est le cas, la ligne est automatiquement reformatée à la syntaxe correcte lors de l'étape 24 et le processus revient à l'étape 21 pour la ligne suivante de ce module de programme particulier. Si, en revanche, la nécessité d'une modification structurelle de la ligne a été déterminée à l'étape 23, une conversion de la structure de la ligne est effectuée à l'étape 25. Cette étape de conversion implique la conversion dans une structure susceptible de fonctionner sur le système opérationnel de base de données 1, bien que des instructions différentes soient utilisées dans cette ligne de programme.
Autrement dit. la ligne convertie aboutira au même résultat final sur la machine opérationnelle, bien que les opérations qu'implique l'obtention du résultat final soient différentes. A l'étape 26, la ligne convertie est testée sur le système opérationnel 1 et, à l'étape 27. on détermine si la ligne a ou n'a pas été vérifiée. Si elle ne l'a pas été, les étapes 25 et 26 sont réitérées. Si elle l'a été, la ligne subit à l'étape 28 un reformatage similaire à celui de l'étape 24. Le reformatage implique une simple modification de la syntaxe destinée à lui permettre de fonctionner sur le système de sauvegarde 2.
A l'étape 29, on détermine s'il faut analyser une autre ligne de code du module. Dans l'affirmative, les étapes 21 à 29 sont réitérées pour chaque ligne successive de code du programme. Quand ces étapes ont été exécutées pour toutes les lignes du module de
<Desc/Clms Page number 7>
programme, le module est écrit sur une bande de sauvegarde 6 du système opérationnel de base de données 1 au cours de l'étape 30. A l'étape 31, on fait tourner le module sur le système de sauvegarde 2 et divers tests sont effectués pour s'assurer de son fonctionnement correct. Les étapes 21 à 32 sont réitérées jusqu'à ce que le module soit vérifié. Lorsque c'est chose faite, les étapes 21 à 32 sont réitérées pour le module de programme suivant du système opérationnel de base de données 1.
On retiendra que dans une telle conversion des programmes du système opérationnel de base de données 1 en vue de leur utilisation sur le système de sauvegarde 2, un traitement identique se déroulera dans chacun des deux systèmes utilisant les programmes, malgré leurs différences de systèmes d'exploitation. de processeurs, etc. Les étapes 25 et 26 se sont avérées particulièrement efficaces pour assurer une conformité entre les deux systèmes, étant donné que la conversion initiale implique la transformation en une structure pouvant fonctionner sur le système opérationnel de base de données 1 et que le reformatage pour le système de sauvegarde 2 s'effectue seulement après que cette possibilité de fonctionnement a été vérifiée.
Les étapes 24, 25 et 26 impliquent également l'enregistrement dans l'un des entraîneurs de disques fixes 5 de toutes les modifications apportées aux lignes de programme. Ces enregistrements comportant l'heure, la date et la nature des modifications effectuées, il est possible de procéder ultérieurement à une vérification manuelle de la méthode de conversion.
La méthode 40, également exposée à la fig. 2, a trait au transfert de données des entraîneurs de disques fixes 5 aux entraîneurs de disques fixes 13 du système de sauvegarde 2. Ici aussi, ces systèmes possèdent des processeurs et systèmes d'exploitation différents, si bien que les données doivent être mises en mémoire d'une manière différente dans chaque système. Il est toutefois primordial que les données mises en mémoire dans les deux systèmes soient identiques, de manière à ce que le soient aussi les
<Desc/Clms Page number 8>
résultats finaux du traitement dans chacun des deux systèmes. A l'étape 41, l'unité centrale 2 lit un enregistrement extrait d'une table d'une base de données d'un entraîneur de disque fixe 5 et, à l'étape 42, convertit ces données au format ASCII.
Selon ce qui aura été déterminé à l'étape de décision 43. cette opération est réitérée pour chaque enregistrement d'une table de base de données. Lorsque tous les enregistrements d'une table ont été convertis au format
ASCII, l'étape 44 consiste à les écrire sur une bande de sauvegarde
6 qui est ensuite transférée physiquement dans le système de sauvegarde de base de données 2, où elle sert à l'écriture des enregistrements sur un disque fixe 13 au cours de l'étape 45. A l'étape 46, le mini-ordinateur 12 génère une structure de table en utilisant les programmes convertis par la méthode 20 puis, à l'étape 47, écrit les enregistrements sur la structure tabulaire à l'aide de ces mêmes programmes.
Il s'est avéré qu'en convertissant d'emblée les enregistrements au format ASCII et en procédant à un transfert enregistrement par enregistrement jusqu'à ce que tous les enregistrements de la table aient été convertis au format ASCII, le transfert des données s'effectue avec efficacité et sans altération de données.
Une fois que les méthodes 20 et 40 ont été mises à exécution de manière à obtenir un système de sauvegarde apte à exécuter des opérations de base de données semblables à celles du système opérationnel, il est primordial de s'assurer que le système de sauvegarde 2 soit maintenu en état afin de pouvoir être utilisé à très brève échéance et avec un minimum de discontinuité dans les opérations lorsqu'une défaillance survient dans le système opérationnel 1. La méthode de maintenance destinée à atteindre cet objectif est exposée à la fig. 3 et représentée par le chiffre 50. A l'étape 51 de cette méthode, un fichier incrémentiel est créé dans le système opérationnel 1. Ce fichier aura une taille suffisante pour contenir toutes les données à recevoir pendant un certain intervalle de transfert. généralement un jour.
Dans la présente réalisation, la taille du fichier sera de 5. 5 Mb. A l'étape 52, les
<Desc/Clms Page number 9>
données sont reçues en continu aux terminaux reliés à l'unité centrale 2 du système opérationnel 1. L'unité centrale 2 remet parallèlement à jour les tables des bases de données situées sur les disques fixes 5 et, à l'étape 54, écrit simultanément les données dans le fichier incrémentiel. De cette manière, toutes les données reçues sont immédiatement écrites dans le fichier incrémentiel du système opérationnel 1. Grâce au contrôle effectué par une horloge en temps réel, on décide à l'étape 55 si un intervalle de transfert préétabli s'est écoulé ou non. Comme on l'a dit, cet intervalle est fixé à un jour dans la présente réalisation.
Une fois ce laps de temps écoulé. l'étape 56 consiste à écrire le fichier incrémentiel sur une bande de sauvegarde 6 qui est alors transférée dans le système de sauvegarde 2, où les données sont réparties dans les tables concernées des disques fixes 13 en utilisant les programmes du système de sauvegarde. Aux étapes 58 et 59, des contrôles d'intégrité sont effectués dans le système opérationnel 1 comme dans le système de sauvegarde 2 de manière à s'assurer que les données des deux systèmes soient en harmonie.
Ces contrôles d'intégrité sont fort brefs et sont exécutés à chaque transfert de données. Les opérations impliquées dans le contrôle d'intégrité peuvent comprendre, par exemple, des totalisations d'échantillons de rangées ou colonnes et des vérifications croisées.
A des intervalles périodiques, des rangées ou colonnes de données provenant de tables sont converties du format alphabétique au format numérique. tant dans le système opérationnel 1 que dans le système de sauvegarde 2. Cette conversion est effectuée pour toutes les colonnes et rangées principales ainsi que pour quelques autres. Aux étapes 61 et 62, des tests d'équilibrage sont lancés respectivement sur le système opérationnel et sur le système de sauvegarde. Chaque test d'équilibrage comporte la génération de statistiques se rapportant à une table de données. Ces statistiques comprendront toujours le nombre de rangées de la table et peuvent également inclure d'autres valeurs, comme le montant total d'une colonne déterminée.
Vu l'importance du volume des données impliquées, les statistiques ne sont réalisables que si elles peuvent être produites en utilisant une seule instruction de test
<Desc/Clms Page number 10>
d équilibrage. La conversion préalable du format alphabétique au format numérique dans un grand nombre de rangées et de colonnes accroît notablement l'efficacité du test d'équilibrage. A l'étape 63, on décide si les tests d'équilibrage sont ou ne sont pas positifs.
S'ils le sont, la méthode 50 est réitérée de manière continue. S'ils ne le sont pas, une analyse-qui implique parfois une vérification manuelle de sorties imprimées-a lieu à l'étape 64.
Il s'est avéré qu'en soumettant le système de sauvegarde 2 à une maintenance de ce type, seule une quantité minimale de la capacité de traitement de l'unité centrale 2 est nécessaire, tandis que les défaillances de données sont très rares, étant donné la nature des vérifications et tests exécutés. Comme les données sont écrites dans le fichier incrémentiel et sont utilisées pour la mise à jour parallèle des tables du système opérationnel 1, on a l'assurance de pouvoir à tout instant mettre très rapidement à jour le système de sauvegarde 2 en cas de défaillance.
La méthode de la présente invention pour le transfert de programmes et données et la maintenance du système de sauvegarde s'est avérée particulièrement efficace même si les matériels et systèmes d'exploitation des deux systèmes de bases de données sont totalement différents. On évite ainsi de devoir utiliser des matériels et systèmes d'exploitation identiques pour le système de sauvegarde et le système opérationnel, d'où une réduction notable des coûts.
La présente invention ne se limite pas aux réalisations décrites cidessus mais peut être modifiée dans sa structure comme dans ses détails.
<Desc / Clms Page number 1>
"Improvements to and in Relation to Database Backup Systems" The invention relates to the generation and maintenance of a database backup system in which a large number of millions of elements of data are stored in tabular format. Such a backup system must come into operation when a failure occurs in an operational system.
Until now, the approach followed for the generation of such a backup system consisted in using two identical database systems connected in parallel, which received and recorded the data in parallel. In such a configuration, the failure of one of the database systems results in the resumption of database operations by the other system. When the backup system must be in a physically remote location and be physically independent from the operating system, the ongoing costs of communication between the two systems make this approach expensive.
In addition, because it has the same configuration as the operating system, the backup system is more expensive than necessary, taking into account that it should only be used for an average of a few hours per year. .
Description British Patent Specification No. 2202656B (IBM)
EMI1.1
describes a method for reconfiguring memory in a system e
<Desc / Clms Page number 2>
microcomputer. This process seems to be unsuitable in the case of a simultaneous shutdown of the memory and the processor.
The invention aims to provide a method of generating and maintaining a backup system which is inexpensive to install and maintain and can be put into service very quickly in the event of failure of the operational system.
In the present invention. a method is provided for transferring data or programs from an operational computer database system to a computer database backup system and keeping the computer database backup system ready for use by emergency; this method comprises the following steps: - successive conversion of each line of each program module of the computer database operational system into a format which is compatible with the computer database backup system; transfer of reformatted program modules into a memory;
EMI2.1
transfer of the memory to a computer database backup system and testing of the program module on this system;
converting data records located in the computer database operational system to ASCII format; transfer of the converted data records to the computer database backup system and insertion of the records into pre-sorted tabular structures; storage of an incremental file in the operational computer database system:
<Desc / Clms Page number 3>
reception of the data entered in the operational computer database system, in parallel with the updating of the tables using this data and the writing of the data to the incremental file;
writing, at regular intervals, the contents of the incremental file into a backup memory and transfer of this memory into the computer database backup system: carrying out brief integrity checks on the tables updated in the operational systems and computer database backup; carrying out the conversion from alphabetical to numeric format for the characters located in certain columns and rows of the data tables in the operating system as in the computer database backup system; and carrying out balancing tests comprising a statistical analysis of the data tables in the two computer database systems and verification of the similarity of the data stored in the two systems.
In one embodiment of the invention, the step of reformatting the
EMI3.1
data from the 1 p computer database operating system for transfer to the computer database backup system comprises the following secondary steps: -
EMI3.2
verification of the possible need for a syntax conversion v and, if necessary, reformatting of the program line by modification of the syntax;
EMI3.3
if it is necessary to convert the structure of the Z> program line, convert the structure into a format suitable for
<Desc / Clms Page number 4>
operate on the computer database operating system: test of the program line on the computer database operating system;
EMI4.1
after verification, reformatting the program line of ZD so that it can operate on the computer database backup system.
The present invention will be understood more clearly from the description below of some of its preferred embodiments, which is given only by way of example and with reference to the accompanying drawings. in which: - fig. 1 is a schematic representation of the operational and computer database backup systems according to the invention; fig. 2 is a flowchart showing the generation of the data and programs stored for the backup system, and
EMI4.2
fig. 3 is a diagram showing a method of maintaining the backup system.
If we refer to the drawings, starting with fig. 1, there is an illustration of a database operational system 1 and of a database backup system 2. The database operational system 1 comprises a central unit 2 IBM 2200/401 connected to several terminals by a terminal server 3. The central unit 2 is also connected to a battery of fixed disk drive units 5 with a capacity of 11.4 Gb and stores relational databases in memory. Programs running on central unit 2 control the storage of data in relational databases as well as the generation of reports and other functions of a database system.
<Desc / Clms Page number 5>
The database backup system 2 includes a multiprocessing minicomputer 12 equipped with a UNIXTM operating system. The minicomputer 12 has five 486TM microprocessors running at 33 MHz and having 256 Mb of memory. The fixed disk drive units 13 have a capacity of 40 Gb. The structure of the mini-computer 12 is modular, in the sense that it is possible, as required, to add to or subtract from it central units, internal or external disks and memory circuits. The minicomputer is of the type normally used in a network as a network server. Each of the Intel 486tam microprocessors in minicomputer 12 has 64 K of internal cache memory and 256 K of external cache memory.
The external cache memory uses a "write back" protocol rather than a "write through" protocol. In other words, the change is kept in the cache until it needs to be replaced, thus avoiding the bottlenecks that can arise during intensive processing. All of the memory circuits and microprocessors of the minicomputer 12 use the microprocessor bus for rapid access to processing operations and their control.
Referring now to FIG. 2, there is shown an illustration of a method 20 for generating database programs and for loading the programs into the database backup system 2. The flowchart also shows a method 40 for transferring data from the operational system 1 to backup system 2. FIG. 3 sets out a method of maintaining the backup system 2 which guarantees that it can be put into service immediately and with a minimum of discontinuity in the operations of the database in the event of failure of the operational system.
The operational database system 1 can be used for processing national bonds or any other large type of transaction where continuous operation is of great importance.
<Desc / Clms Page number 6>
Method 20 comprises as an initial step the analysis of a line of the program code used by the operational database system 1. The structure of the line is the instruction or the series of instructions which it contains and which may apply only to the operational database system 1. The line syntax consists of the series of characters used there. Following this analysis, a decision is made at step 22 on the possible need to perform a conversion of the line so that it can be used for the database backup system 2.
If so, it is determined in step 23 if the conversion can be limited to the syntax only. If this is the case, the line is automatically reformatted to the correct syntax in step 24 and the process returns to step 21 for the next line in this particular program module. If, on the other hand, the need for a structural modification of the line was determined in step 23, a conversion of the structure of the line is carried out in step 25. This conversion step involves conversion into a structure likely to run on database operating system 1, although different instructions are used in this program line.
In other words. the converted line will lead to the same final result on the operational machine, although the operations involved in obtaining the final result are different. In step 26, the converted line is tested on the operating system 1 and, in step 27. it is determined whether the line has or has not been verified. If it has not been, steps 25 and 26 are repeated. If it was, the line undergoes at step 28 a reformatting similar to that of step 24. Reformatting involves a simple modification of the syntax intended to allow it to function on the backup system 2.
In step 29, it is determined whether to analyze another line of code of the module. If so, steps 21 to 29 are repeated for each successive line of program code. When these steps have been carried out for all the lines of the module
<Desc / Clms Page number 7>
program, the module is written on a backup tape 6 of the operational database system 1 during step 30. In step 31, the module is run on the backup system 2 and various tests are carried out to make sure it is working properly. Steps 21 to 32 are repeated until the module is checked. When this is done, steps 21 to 32 are repeated for the next program module of the database operating system 1.
It will be noted that in such a conversion of the programs of the operational database system 1 with a view to their use on the backup system 2, an identical processing will take place in each of the two systems using the programs, despite their differences in systems of exploitation. processors, etc. Steps 25 and 26 have been found to be particularly effective in ensuring compliance between the two systems, since the initial conversion involves transformation into a structure capable of operating on the database operating system 1 and that reformatting for the database system 1 backup 2 takes place only after this possibility of operation has been verified.
Steps 24, 25 and 26 also involve recording in one of the fixed disc trainers 5 all the modifications made to the program lines. Since these records include the time, date and the nature of the modifications made, it is possible to carry out a manual verification of the conversion method later.
Method 40, also shown in fig. 2, relates to the transfer of data from the fixed disk drives 5 to the fixed disk drives 13 of the backup system 2. Here too, these systems have different processors and operating systems, so that the data must be put in memory in a different way in each system. However, it is essential that the data stored in the two systems is identical, so that the data is also the same.
<Desc / Clms Page number 8>
final results of treatment in each of the two systems. In step 41, the central processing unit 2 reads a recording extracted from a table of a database of a fixed disk trainer 5 and, in step 42, converts this data to ASCII format.
According to what will have been determined in decision step 43. this operation is repeated for each record of a database table. When all the records of a table have been converted to the format
ASCII, step 44 consists of writing them on a backup tape
6 which is then physically transferred to the database backup system 2, where it is used to write the recordings to a fixed disk 13 during step 45. In step 46, the mini-computer 12 generates a table structure using the programs converted by method 20 and then, in step 47, writes the records to the tabular structure using these same programs.
It turned out that by converting the records in ASCII format from the start and by performing a record-by-record transfer until all the records in the table have been converted to ASCII format, the data transfer is performs efficiently and without altering data.
Once the methods 20 and 40 have been implemented in order to obtain a backup system capable of performing database operations similar to those of the operating system, it is essential to ensure that the backup system 2 is kept in condition so that it can be used at very short notice and with a minimum of discontinuity in operations when a failure occurs in the operational system 1. The maintenance method intended to achieve this objective is set out in fig. 3 and represented by the number 50. In step 51 of this method, an incremental file is created in the operating system 1. This file will have a size sufficient to contain all the data to be received during a certain transfer interval. usually one day.
In the present embodiment, the file size will be 5.5 Mb. In step 52, the
<Desc / Clms Page number 9>
data is continuously received at the terminals connected to the central unit 2 of the operational system 1. The central unit 2 updates in parallel the tables of the databases located on the fixed disks 5 and, in step 54, writes simultaneously the data in the incremental file. In this way, all the data received are immediately written to the incremental file of the operating system 1. Thanks to the control carried out by a real-time clock, it is decided in step 55 if a preset transfer interval has passed or not. . As has been said, this interval is fixed at one day in the present embodiment.
Once this period of time has elapsed. step 56 consists in writing the incremental file on a backup tape 6 which is then transferred to the backup system 2, where the data is distributed in the relevant tables of the fixed disks 13 using the programs of the backup system. In steps 58 and 59, integrity checks are carried out in the operational system 1 as in the backup system 2 so as to ensure that the data of the two systems are in harmony.
These integrity checks are very brief and are performed each time data is transferred. The operations involved in the integrity check may include, for example, tabulation of row or column samples and cross-checks.
At periodic intervals, rows or columns of data from tables are converted from alphabetical to numeric format. both in operational system 1 and in backup system 2. This conversion is carried out for all the main columns and rows as well as for a few others. In steps 61 and 62, balancing tests are launched respectively on the operating system and on the backup system. Each balancing test involves the generation of statistics relating to a data table. These statistics will always include the number of rows in the table and may also include other values, such as the total amount of a specific column.
Given the importance of the volume of data involved, statistics are only achievable if they can be produced using a single test instruction
<Desc / Clms Page number 10>
balancing. Converting alphabetically to numeric format in a large number of rows and columns significantly increases the effectiveness of the balancing test. In step 63, it is decided whether the balancing tests are or are not positive.
If they are, method 50 is repeated continuously. If they are not, an analysis - which sometimes involves manual verification of printed output - takes place in step 64.
It has been found that by subjecting the backup system 2 to maintenance of this type, only a minimum amount of the processing capacity of the central unit 2 is required, while data failures are very rare, being given the nature of the verifications and tests carried out. As the data are written to the incremental file and are used for the parallel updating of the tables of the operating system 1, we can be sure that we can update the backup system 2 very quickly in the event of a failure.
The method of the present invention for transferring programs and data and maintaining the backup system has proven to be particularly effective even if the hardware and operating systems of the two database systems are completely different. This avoids having to use identical hardware and operating systems for the backup system and the operating system, thereby significantly reducing costs.
The present invention is not limited to the embodiments described above but can be modified in its structure as in its details.