Data processing: database and file management or data structures – Database design – Data structure types
Reexamination Certificate
1998-07-15
2001-07-17
Black, Thomas (Department: 2776)
Data processing: database and file management or data structures
Database design
Data structure types
C707S793000, C707S793000, C707S793000, C707S793000
Reexamination Certificate
active
06263338
ABSTRACT:
FIELD OF INVENTION
The present invention relates to a method that pertain to a database and that is intended to provide reliable collection of log-information in connection with database changes.
The method utilises fuzzy check-points with the object of enabling the waiting times that normally occur at consistent check-points to be reduced, wherein these fuzzy check-points are combined with a physiological log with the intention of enabling log-information to be collected in real time.
Data information belonging to the database is divided into smaller parts in accordance with a predetermined data-structure, wherein respective parts are distributed on a common page or on separate pages belonging to the database.
The inventive method can be applied in particular with applications that concern distributed databases where there is a need for a location and replica independent log.
BACKGROUND OF THE INVENTION
Two basic database structures will be described by way of introduction, together with a few associated properties, namely a disk memory database and a primary memory database.
In a disk memory database, part of the information, the information latest used, lies in a primary memory while the remainder lies in a disk memory. In this case, if the desired information does not happen to be already stored in the primary memory it must be taken from the disk memory and entered in the primary memory. The new information taken from the disk memory is written over the information that is present in the primary memory, and if this written-over information shall be used at a later stage, it is necessary to recollect said information from the disk memory. The memory content is divided into pages and the pages are handled independently of one another. For instance, new information can be taken into one page, while another page remains unaffected.
In the case of a disk memory database, the data-structure in the primary memory is normally a 1:1 mapping of the structure in the disk memory.
Since the memory content of the primary memory of a disk memory database is updated to the disk memory one page at a time, the links between different pages are inconsistent upon the restart of a system subsequent to a crash. Consistent check-points are thus often difficult to implement in conjunction with disk memory databases.
Consistent check-points are easier to achieve in a primary memory database. For instance, this consistency can be readily achieved by having two replicas of the database in disk memory. That is, a replica of the latest or current version of the database and a replica of the older version. This is possible because the whole of the database is found in the primary memory at once and different versions of the database where it is known that consistency prevails between all pages according to a given check-point can then be readily stored in the disk memory.
It may be that certain attributes belonging to an object in a database are primary-memory based, while other attributes within the same object are disk-memory based. Tables that constitute a mixture between a disk-memory database and a primary memory database may also be found.
A database includes data tables that are formatted in different ways. A table is comprised of a number of columns, where each column contains a certain kind of information. Each column is allocated a specific attribute and the information in said column is formatted in accordance with this attribute.
Examples of attributes are that the information stored is formatted as an integer, with or without signs, a floating number, a decimal number, a date, text, and so on.
Other factors determined by the attribute include:
when the attribute is a fixed attribute, i.e. when the content takes-up a fixed memory size;
when the attribute is a variable attribute, i.e. the attribute can vary in size; or
when the attribute is a dynamic attribute, i.e. when the attribute is present or absent, such as a selectable or optional attribute.
A dynamic attribute may either be variable or fixed.
An object in a table corresponds to a row or line in the table and includes the attributes (columns) present in the table. An object can thus include a mixture of the aforesaid different attributes.
A table listing personal information concerning a group of persons is one example in this regard. Different attributes may include Christian name(s), surname, street address, postal address, telephone number, date of birth and other optional comments.
Date of birth is a fixed attribute (if it is entered on a predetermined format), while name, address and telephone number are variable attributes and comments is a dynamic variable attribute.
An object is then a person and information relating to that person.
There are many ways in which a table according to this example can be stored. The table can be stored in the fixed memory spaces in a consecutive sequence in a memory. This requires a large amount of memory space, the greater part of which will be empty in order to be able to prepare space for variable and dynamic attributes. The variable attributes will then only be variable in a limited way according to the size of the allocated memory space.
Alternatively, each object can be given a header that discloses the size of the variable attributes and also whether a dynamic attribute is present or not, and also the size of such attributes if present. Thus, when creating an object the memory space required for respective attributes is allocated and the attributes are combined to form an object. The header discloses the size of respective attributes, thereby enabling the information in the object to be interpreted correctly. The header may also include an index which includes a pointer that points to respective attributes.
When storing a table in a memory in practice, it is seldom that the memory has continuous memory space for storing the entire table, since a memory is often fragmented to a greater or lesser extent. In the majority of cases, a table is too large to be accommodated on one page. The various objects in a table are thus spread on one page, and a table is divided up over several such pages.
A fragment is a part of a table and also includes several different pages. In distributed databases, a table can be distributed over several processor nodes in the distributed database. A fragment is then a part of a table found in a node. A fragment also includes all replicas of the same part of the table. Thus, a fragment can include a primary replica of a part of a table stored in a node and a secondary replica of the same part of the same table stored in another node. Several different replicas of different fragments of the same or different tables may be stored in one node.
In the case of large objects, it is not unusual to find it necessary to divide-up the various objects and store these object-divisions at different locations in a page, or to divide the object up between different pages. For instance, a large object may be one where one or more attributes is/are comprised of a text file that can include several thousand characters.
In the case of large objects, it is known in connection with disk memory databases to use for a table and for the objects in a table, advanced data-structures that build a tree-structure, such as a B-tree.
An object is then divided-up into different parts and these parts stored in available memory spaces in accordance with the tree-structure. The header for respective objects will then include a pointer which points down in a B-tree, thereby enabling the different parts of the object to be found. The parts need not necessarily constitute a whole attribute and the object can be handled as one single, continuous character string and divided-up in any desired way according to the memory spaces that are available.
This procedure is normally applied when an object is so large as to cover a full page and where a change is written directly into the disk memory. If the information is not written directly into the disk memory, some type of log is required.
In such cases where
Jacobsson David
Larsson Lars Joakim
Ronstrom Ulf Mikael
Black Thomas
Burns Doane Swecker & Mathis L.L.P.
Do Thuy
Telefonaktiebolaget LM Ericsson (publ)
LandOfFree
Method relating to databases does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Method relating to databases, we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Method relating to databases will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-2499296