<Desc/Clms Page number 1>
Processus de gestion de base de données sur bande magnétique L'invention se rapporte à un processus exécuté par un gestionnaire de base de données sur bande magnétique connecté entre un système de traitement de données et un système à bande magnétique.
Il est bien connu que le stockage de données sur bande magnétique est bien moins coûteux que le stockage sur disque. C'est pour cette raison que la bande magnétique est souvent utilisée pour l'archivage de grandes quantités de données. Un exemple est l'archivage de données de facturation d'une société de service telle une compagnie de téléphone. Des systèmes à bande magnétique tels que ceux décrits dans la description du brevet américain n 4145724 (Consolidated Electronic Industries) ou dans la description du brevet PCT nO 9301595 (Storage Technology Corp. ) sont utilisés pour la manutention automatisée des bandes.
Jusqu'à ce jour, la recherche de données sur bande est un processus généralement assez lent. D'ailleurs, étant donné sa lenteur, il n'est généralement pas utilisé dans des applications de traitement en temps réel. Il en résulte des inconvénients commerciaux considérables pour des sociétés de service p. e. par les délais de réponse à des questions posées par des clients. Un exemple est un abonné qui téléphone à la compagnie du téléphone au sujet d'une facture datant de plusieurs mois. Les données de cette facture auront plus que probablement été archivées sur
<Desc/Clms Page number 2>
bande et ne seront plus accessibles sur disque.
Il est alors indispensable de générer les instructions nécessaires à la recherche de la bande qui contient les données recherchées, puis de lire les données et de répondre au client au moins deux heures plus tard.
L'invention vise un processus de stockage et de recherche de données sur bande exécuté suffisamment rapidement pour être utile dans des applications de traitement de données en temps réel.
Selon l'invention, il est prévu un processus de stockage et de recherche de données sur un système à bande magnétique, le processus étant exécuté par un gestionnaire de base de données sur bande connecté entre un système de traitement de données et un pilote de système à bande, le gestionnaire comprenant les étapes de : - mise en place d'une structure de base de données comprenant une pluralité d'enregistrements dans la base de données ; - mise en place d'une structure générale de bande d'un certain nombre de blocs de données de longueur variable pour les bandes utilisées par le système à bandes ; - réception d'une demande de stockage émanant du gestionnaire de données et exécution des étapes suivantes :
attribution d'un volume de bande unique à l'ensemble de données concerné, organisation de la création d'un nouvel en-tête d'enregistrement dans le bloc de
<Desc/Clms Page number 3>
données du volume de bande, l'en-tête comprenant une clé principale et une date de stockage, et d'enregistrement séquentielle des données après l'en-tête dans une pluralité de sous enregistrements ; - création d'un fichier index associé à la base de données comprenant un enregistrement index unique de contrôle qui contient les données d'initialisation du système à bande ;
- après l'écriture des données vers le système à bande, démarrage par le gestionnaire de base de données sur bande d'un cycle d'enregistrement index d'accès de l'enregistrement de données, l'enregistrement index d'accès comprenant la clé principale et la date d'enregistrement ainsi que le numéro d'ordre du volume associé et l'identification du bloc ; - réception d'une demande de recherche de données et d'exécution des étapes suivantes :- - adressage du fichier index par la clé principale et la date d'enregistrement et accès à l'enregistrement index d'accès associé pour y lire le numéro d'ordre du volume d'enregistrement des données et de l'identification du bloc ; et - transmission d'instructions de lecture au pilote du système à bande.
<Desc/Clms Page number 4>
Dans une réalisation, le gestionnaire de la base de données sur bande attribue un nom d'ensemble de données composé d'une référence commune primaire et une référence secondaire qui contient le numéro d'ordre du volume.
De préférence il sera prévu un nombre variable de sous enregistrements pour chaque enregistrement de données, un seul enregistrement de données ne pouvant occuper plus de deux blocs ou davantage à moins que sa taille ne soit plus grande.
Dans une autre réalisation, l'enregistrement index de contrôle du fichier index comprend le nombre en cours de blocs du volume de bande, ce nombre étant automatiquement mis à jour par le gestionnaire de la base de données sur bande après chaque écriture d'un nouveau bloc.
L'invention sera plus facilement comprise par la description ci-dessous de quelques unes des réalisations préférées de l'invention, description donnée uniquement à titre d'exemple et en se référant aux dessins joints dans lesquels : - la fig. 1 est un schéma de principe d'un système de traitement de données qui comprend un système à bande et un gestionnaire de bases de données sur bande de l'invention ; - la fig. 2 est un organigramme qui montre le flux des instructions dans le gestionnaire de la base de données sur bande ;
<Desc/Clms Page number 5>
- la fig. 3 est une représentation schématisée de l'hiérarchie d'une base de données sur bande générée par le processus de l'invention ; et - la fig. 4 représente le fichier index généré par le gestionnaire de la base de données sur bande.
La fig. 1 représente un système de traitement de données 1.
Le système 1 exécute des opérations de traitement et plus spécialement des opérations sur des bases de données. Le système 1 comprend une unité de traitement de données 2 qui gère les différentes opérations du traitement. Une des tâches principales de l'unité de traitement 2 est l'accès à des données de bases de données sur disque dur et le traitement de ces données. Il sera toutefois régulièrement nécessaire d'accéder à des données d'un grand système à bande de bases de données 3 d'une capacité pouvant atteindre 26 téraoctets. Un élément de pilotage de bande 4 est conçu pour recevoir des données ou des demandes d'accès aux données ainsi que des adresses d'écriture et de lecture des données du système à bande ainsi que de gestion des systèmes robotisés du système à bande 3.
Pour permettre au système de traitement des données 2 d'accéder aux bases de données du système à bande 3, le système 1 comprend un gestionnaire de base de données sur bande 10 connecté entre le système de traitement de données 2 et Isolément de pilotage de bande 4. Il comprend, en outre, une interface de pilotage de bande 11 connectée pour intercepter les instructions du gestionnaire de bases de données sur bande 10 et pour fournir des instructions auxiliaires de manutention robotisée destinées à l'élément de pilotage de
<Desc/Clms Page number 6>
bande 4. Le gestionnaire de base de données sur bande 10 fonctionne conjointement avec le fichier index 12 et le fichier catalogue 13, décrits ci-dessous.
La fig. 2 illustre l'interaction du gestionnaire de base de données sur bande 10 et de l'interface de l'unité de pilotage de bande 11. Une instruction 20 transmise par le gestionnaire de base de données 10 est interceptée à l'étape 21 par l'interface de l'unité de pilotage de bande 11. Lorsqu'il s'agit d'une instruction de lecture ou d'écriture de données d'une bande déjà chargée dans le mécanisme de lecture, l'instruction est transmise immédiatement à travers l'élément de pilotage de bande 4 comme indiqué par la flèche 22.
Si toutefois une action robotisée est nécessaire pour charger la bande concernée dans le mécanisme de lecture, l'interface de l'unité de pilotage de bande 11 génère les instructions de manipulation robotisée nécessaires à l'élément de pilotage de bande 4 avant de transmettre l'instruction, dans ce cas indirectement, comme indiqué par la flèche 24.
Les caractéristiques importantes de l'invention résident dans le fonctionnement du gestionnaire de bases de données sur bande 10 pour assurer l'écriture et la lecture rapides de données d'une base de données sur bande dans le système à bande 3. La lecture rapide de données est plus importante que l'écriture, le dernière pouvant se faire par un processus de traitement d'archivage par lots.
Le gestionnaire 10 met en place une structure de base de données comprenant un grand nombre d'ensembles de données.
La fig. 3 illustre une base de données 30. En plus, le
<Desc/Clms Page number 7>
gestionnaire 10 met en place une structure générale de bande pour chaque bande manipulée par le système à bande 3.
Cette structure générale de bande comprend une pluralité de blocs de données de longueur fixe, la longueur de chaque bloc de données ne dépassant pas 32 ko. Le gestionnaire 10 met également en place un fichier index 12. Le fichier index 12 contient un enregistrement index unique de gestion qui contient toutes les données d'initialisation de la base de données nécessaires. Plusieurs bases de données peuvent être stockées dans le système à bande 3, chaque base de données ayant été attribué un fichier index unique.
L'enregistrement index de gestion contient plusieurs valeurs de tolérance de niveau haut de stockage de données sur les bandes, y compris le maximum de nombre de blocs par volume de bande ainsi que la taille de bloc maximale pour un ensemble de données, le nombre maximum de périodes d'archivage, c. à. d. la durée maximum de conservation des données dans les bases de données avant l'effacement automatique. L'enregistrement index de gestion contient également le bloc en cours d'utilisation. Le fichier index 12 est illustré de façon plus détaillée à la fig. 4.
L'enregistrement index de gestion y est repéré par le nombre 60.
Lorsque le gestionnaire 10 reçoit une demande de stockage du système de traitement de données 2, il définit d'abord l'ensemble de données concerné et met en place un volume de bande unique pour cet ensemble de données pour autant que ceci n'ait pas encore été fait. La fig. 3 illustre qu'il existe un volume de bande unique 31 pour chaque ensemble de données. Chaque volume est identifié par un repère séquentiel, c. à. d., un numéro d'ordre dans la fourchette de
<Desc/Clms Page number 8>
1 à n. Dès qu'un volume de bande a été attribué à un ensemble de données, le nom de l'ensemble est généré. Celui-ci comprend une référence primaire commune ou standard suivi par une référence secondaire qui comprend le numéro d'ordre du volume.
La réalisation décrite gère un maximum de 65.535 ensembles de données et la référence secondaire utilise donc le format nnnnn.
La structure de chaque volume de bande 31 est illustrée par la fig. 3. Cette structure comprend un enregistrement, qui contient le numéro d'ordre de volume 32, suivi de deux en-têtes, 33 et 34, et d'un marqueur de bande 35. Puis, suit une séquence de blocs de données de longueur constante 36. Un bloc de données 36 typique est également représenté par la fig. 3 et est constitué d'un certain nombre d'enregistrements 37. L'enregistrement de données dans un volume de bande spécifié implique l'enregistrement dans un bloc de données 36, ce qui nécessite la création d'un nouvel en-tête d'enregistrement pour l'enregistrement 37.
Chaque enregistrement 37 contient un nombre variable de sous enregistrements de longueur variable. L'exemple de la fig. 3 montre un enregistrement de données 37 qui contient trois sous enregistrements 37. L'en-tête 40 de chaque enregistrement de données archivées est illustré de façon détaillée à la fig. 3. Dans cette réalisation, celui-ci contient une paire de caractères @@ fixes 50 suivis par un champ clé principal 51 et une clé de date d'enregistrement 52. L'information fournie au gestionnaire 10 par le système de traitement 2 comprend la clé principale qui peut p. e. être le numéro de compte client dans le cas d'une compagnie de téléphone ou d'électricité. La date de stockage est dérivée d'une horloge en temps réel.
Le gestionnaire 10
<Desc/Clms Page number 9>
dispose donc de toutes les données nécessaires à la création d'un en-tête 40 lors de l'écriture de données dans un bloc de données 36. L'organisation des données en sous enregistrements 41 dépend de la nature des données. Toute l'information nécessaire à l'enregistrement des données à l'endroit correct de la bande souhaitée est générée par le gestionnaire 10 et encodée dans les instructions transmises soit directement soit indirectement à l'élément de pilotage de bande 4. Le gestionnaire de base de données sur bande 10 n'intervent pas dans l'écriture proprement dite des données ni dans la manutention robotisée des bandes.
Après l'écriture des données sur la bande, le gestionnaire 10 crée un enregistrement index d'accès dans le fichier index 12 qui correspond à l'enregistrement de données 37.
L'enregistrement index d'accès, repéré à la fig. 4 par le nombre 70, comprend un préfixe de longueur constante constitué d'un champ clé primaire 71 et d'un champ 72, long d'un demi mot, qui contient le nombre de cycles de l'enregistrement index d'accès 70. Le préfixe de longueur constante est suivi d'un certain nombre de cycles comprenant chacun les champs 73 à 76. Chaque cycle contient la date d'archivage ou de stockage sur 6 octets 73 et un champ binaire 74, d'un demi mot, qui contient le nombre de blocs de bande occupés par cette entité de données archivées. Un aspect important de ce processus d'écriture est qu'un enregistrement de données archivées n'occupe pas plus qu'un bloc de données, à moins que sa longueur ne dépasse la taille d'un bloc (32ko).
Le cycle contient également un champ binaire 75, d'un mot entier, identifiant
<Desc/Clms Page number 10>
le premier bloc de bande qui contient des données de l'enregistrement et finalement, un champ binaire 76, d'un demi mot, contenant le numéro d'ordre du volume.
Il est donc à noter qu'il y a un enregistrement index d'accès unique dans le fichier index 12 pour chaque clé principale correspondant p. e. au numéro de compte client.
Le cycle approprié donne l'information de recherche des données sur la bande appropriée. Pour lire des données dans une base de données sur bande d'un système à bande 3, le système de traitement de données 2 transmet la clé principale et la date d'archivage des données. Par un accès au fichier index 12, le gestionnaire de bases de données 10 extrait le numéro d'ordre du volume et la référence du bloc de départ respectivement des champs 76 et 75 du cycle approprié de l'enregistrement index d'accès 70. Dès que le bloc approprié est déterminé dans le volume de bande approprié, l'enregistrement de données correspondant 37 est trouvé à l'aide de la clé principale dans les champs 51 des en-têtes 40 de l'enregistrement des données.
Dès la fin d'une opération d'écriture, le gestionnaire 10 met à jour l'enregistrement index de contrôle du fichier index concerné 12 avec la référence du bloc dans lequel l'écriture a eu lieu. Il est important de savoir que les blocs sont utilisés de façon séquentielle, indépendamment de la nature des données qui y ont été écrites. Ceci réduit au minimum la manutention des bandes du système à bande 3.
Le fait que les données associées à une clé principale unique, telle que le numéro de compte client, puissent se trouver dans différents volumes de bande dans différents éléments de données est d'importance mineure étant donné la
<Desc/Clms Page number 11>
méthode de recherche utilisée par le processus décrit ci-dessus. Il s'est avéré que la structure particulière des données utilisée et la méthode de recherche par l'accès au fichier index 12 résultent en un temps de recherche très court et, en effet, on peut pratiquement garantir un temps d'accès moyen de 30 secondes pour un système à bande de technologie de pointe. Le gestionnaire 10 peut être utilisé avec un nombre plus important de systèmes de traitement de données 2 si gérés par un système hôte central.
Pour cela, celui-ci transmet en tâche de fond des instructions codées pour exécuter toutes les fonctions de bande d'un processeur particulier du système de traitement de données. Les instructions de la tâche de fond sont transmises vers l'espace adresse d'un processeur particulier afin d'éviter que d'autres processeurs ne soient ralentis par les opérations d'un quelconque processeur cherchant des données sur une bande.
L'invention n'est pas limitée aux réalisations décrites ci-dessus qui peuvent varier tant dans leurs constructions que dans leurs détails.
<Desc / Clms Page number 1>
The invention relates to a process executed by a database manager on magnetic tape connected between a data processing system and a magnetic tape system.
It is well known that storing data on magnetic tape is much less expensive than storing on disc. For this reason, magnetic tape is often used for archiving large amounts of data. An example is the archiving of billing data from a service company such as a telephone company. Magnetic tape systems such as those described in the description of US Patent No. 4145724 (Consolidated Electronic Industries) or in the description of PCT Patent No. 9301595 (Storage Technology Corp.) are used for automated tape handling.
To date, searching for data on tape has generally been a fairly slow process. Moreover, given its slowness, it is generally not used in real-time processing applications. This results in considerable commercial disadvantages for service companies p. e. by the response times to questions asked by customers. An example is a subscriber who calls the telephone company about a bill that is several months old. The data on this invoice will more than likely have been archived on
<Desc / Clms Page number 2>
tape and will no longer be accessible on disk.
It is therefore essential to generate the instructions necessary to find the tape that contains the data sought, then read the data and respond to the client at least two hours later.
A tape data storage and retrieval process is performed quickly enough to be useful in real-time data processing applications.
According to the invention, there is provided a process for storing and retrieving data on a magnetic tape system, the process being executed by a tape database manager connected between a data processing system and a system driver. tape, the manager comprising the steps of: - setting up a database structure comprising a plurality of records in the database; - establishment of a general band structure of a number of variable length data blocks for the bands used by the band system; - receipt of a storage request from the data manager and execution of the following steps:
allocation of a single tape volume to the data set concerned, organization of the creation of a new recording header in the block of
<Desc / Clms Page number 3>
tape volume data, the header comprising a master key and a date of storage, and of sequential recording of the data after the header in a plurality of sub-records; - creation of an index file associated with the database comprising a single control index record which contains the initialization data of the tape system;
- after the writing of the data to the tape system, starting by the database manager on tape of an access index recording cycle of the data recording, the access index recording comprising the main key and the date of recording as well as the serial number of the associated volume and the identification of the block; - reception of a request for data search and execution of the following steps: - - addressing of the index file by the main key and the date of recording and access to the associated access index record to read the number order of data recording volume and block identification; and - transmission of read instructions to the pilot of the tape system.
<Desc / Clms Page number 4>
In one embodiment, the manager of the tape database assigns a data set name composed of a primary common reference and a secondary reference which contains the serial number of the volume.
Preferably, a variable number of sub-records will be provided for each data record, a single data record cannot occupy more than two or more blocks unless its size is larger.
In another embodiment, the index control record of the index file includes the current number of blocks of the tape volume, this number being automatically updated by the manager of the database on tape after each writing of a new block.
The invention will be more easily understood from the description below of some of the preferred embodiments of the invention, description given only by way of example and with reference to the accompanying drawings in which: - FIG. 1 is a block diagram of a data processing system which includes a tape system and a tape database manager of the invention; - fig. 2 is a flow chart showing the flow of instructions in the tape database manager;
<Desc / Clms Page number 5>
- fig. 3 is a schematic representation of the hierarchy of a tape database generated by the process of the invention; and - fig. 4 represents the index file generated by the database manager on tape.
Fig. 1 represents a data processing system 1.
The system 1 executes processing operations and more particularly operations on databases. The system 1 comprises a data processing unit 2 which manages the various processing operations. One of the main tasks of the processing unit 2 is the access to data from databases on hard disk and the processing of this data. However, data from a large database band system 3 with a capacity of up to 26 terabytes will be required on a regular basis. A band control element 4 is designed to receive data or data access requests as well as addresses for writing and reading data from the band system as well as for managing the robotic systems of the band system 3.
To allow the data processing system 2 to access the databases of the tape system 3, the system 1 comprises a tape database manager 10 connected between the data processing system 2 and Tape control in isolation 4. It further comprises a connected tape piloting interface 11 for intercepting the instructions of the tape database manager 10 and for providing auxiliary robotic handling instructions intended for the piloting element of
<Desc / Clms Page number 6>
tape 4. The tape database manager 10 works in conjunction with the index file 12 and the catalog file 13, described below.
Fig. 2 illustrates the interaction of the tape database manager 10 and the interface of the tape control unit 11. An instruction 20 transmitted by the database manager 10 is intercepted in step 21 by the tape drive unit interface 11. When it is an instruction to read or write data from a tape already loaded in the read mechanism, the instruction is immediately transmitted through the band control element 4 as indicated by the arrow 22.
If, however, a robotic action is necessary to load the tape concerned in the reading mechanism, the interface of the tape control unit 11 generates the robotic manipulation instructions necessary for the tape control element 4 before transmitting the instruction, in this case indirectly, as indicated by arrow 24.
The important features of the invention reside in the operation of the tape database manager 10 to ensure rapid writing and reading of data from a tape database in the tape system 3. The fast reading of data is more important than writing, the latter can be done by a batch archiving processing process.
The manager 10 sets up a database structure comprising a large number of data sets.
Fig. 3 illustrates a database 30. In addition, the
<Desc / Clms Page number 7>
manager 10 sets up a general band structure for each band handled by the band system 3.
This general band structure comprises a plurality of data blocks of fixed length, the length of each data block not exceeding 32 kb. The manager 10 also sets up an index file 12. The index file 12 contains a single management index record which contains all the necessary initialization data of the database. Several databases can be stored in the 3 band system, each database having been assigned a unique index file.
Management index record contains several high-level data storage tolerance values on tapes, including the maximum number of blocks per tape volume as well as the maximum block size for a data set, the maximum number archival periods, c. at. d. the maximum duration of data retention in databases before automatic deletion. The management index record also contains the block in use. The index file 12 is illustrated in more detail in FIG. 4.
The management index record is identified by the number 60.
When the manager 10 receives a storage request from the data processing system 2, it first defines the data set concerned and sets up a single tape volume for this data set provided that this has not yet been done. Fig. 3 illustrates that there is a unique tape volume 31 for each set of data. Each volume is identified by a sequential mark, c. at. d., a serial number in the range of
<Desc / Clms Page number 8>
1 year. Once a tape volume has been assigned to a data set, the name of the set is generated. This includes a common or standard primary reference followed by a secondary reference that includes the serial number of the volume.
The described embodiment manages a maximum of 65,535 data sets and the secondary reference therefore uses the nnnnn format.
The structure of each strip volume 31 is illustrated in FIG. 3. This structure includes a record, which contains the volume sequence number 32, followed by two headers, 33 and 34, and a band marker 35. Then follows a sequence of data blocks of length constant 36. A typical data block 36 is also shown in FIG. 3 and consists of a number of records 37. Saving data in a specified tape volume involves recording in a data block 36, which requires the creation of a new header. registration for registration 37.
Each record 37 contains a variable number of sub-records of variable length. The example in fig. 3 shows a data record 37 which contains three sub-records 37. The header 40 of each record of archived data is illustrated in detail in FIG. 3. In this embodiment, it contains a pair of @@ fixed characters 50 followed by a main key field 51 and a registration date key 52. The information supplied to the manager 10 by the processing system 2 includes the main key which can p. e. be the customer account number in the case of a telephone or electricity company. The storage date is derived from a real time clock.
The manager 10
<Desc / Clms Page number 9>
therefore has all the data necessary for creating a header 40 when writing data to a data block 36. The organization of the data into sub-records 41 depends on the nature of the data. All the information necessary for recording data at the correct location on the desired tape is generated by the manager 10 and encoded in the instructions transmitted either directly or indirectly to the tape control element 4. The basic manager of data on tape 10 do not intervene in the actual writing of the data or in the robotic handling of the tapes.
After writing the data to the tape, the manager 10 creates an access index record in the index file 12 which corresponds to the data record 37.
The access index record, identified in fig. 4 by the number 70, comprises a prefix of constant length consisting of a primary key field 71 and a field 72, half a word long, which contains the number of cycles of the access index record 70. The prefix of constant length is followed by a certain number of cycles each comprising fields 73 to 76. Each cycle contains the date of archiving or storage on 6 bytes 73 and a binary field 74, of a half word, which contains the number of tape blocks occupied by this archived data entity. An important aspect of this writing process is that an archived data record occupies no more than a block of data, unless its length exceeds the size of a block (32kb).
The cycle also contains a binary field 75, of a whole word, identifying
<Desc / Clms Page number 10>
the first block of tape which contains data of the recording and finally, a binary field 76, of a half word, containing the serial number of the volume.
It should therefore be noted that there is a unique access index record in the index file 12 for each corresponding main key p. e. to the customer account number.
The appropriate cycle provides the data search information on the appropriate tape. To read data from a tape database of a tape system 3, the data processing system 2 transmits the master key and the date of archiving of the data. By accessing the index file 12, the database manager 10 extracts the serial number of the volume and the reference of the starting block respectively from fields 76 and 75 of the appropriate cycle of the access index record 70. From that the appropriate block is determined in the appropriate tape volume, the corresponding data record 37 is found using the master key in fields 51 of the headers 40 of the data record.
At the end of a write operation, the manager 10 updates the control index record of the concerned index file 12 with the reference of the block in which the write took place. It is important to know that the blocks are used sequentially, regardless of the nature of the data written to them. This minimizes the tape handling of the tape system 3.
The fact that the data associated with a unique master key, such as the customer account number, can be in different tape volumes in different data items is of minor importance given the
<Desc / Clms Page number 11>
search method used by the process described above. It turns out that the particular data structure used and the search method by accessing the index file 12 results in a very short search time and, in fact, one can practically guarantee an average access time of 30 seconds for an advanced technology tape system. The manager 10 can be used with a larger number of data processing systems 2 if managed by a central host system.
To do this, the latter transmits coded instructions in the background to execute all the tape functions of a particular processor of the data processing system. The instructions of the background task are transmitted to the address space of a particular processor in order to avoid that other processors are slowed down by the operations of any processor seeking data on a tape.
The invention is not limited to the embodiments described above which can vary both in their constructions and in their details.