US20060143187A1 - Integrating tablespaces with different block sizes - Google Patents
Integrating tablespaces with different block sizes Download PDFInfo
- Publication number
- US20060143187A1 US20060143187A1 US11/347,644 US34764406A US2006143187A1 US 20060143187 A1 US20060143187 A1 US 20060143187A1 US 34764406 A US34764406 A US 34764406A US 2006143187 A1 US2006143187 A1 US 2006143187A1
- Authority
- US
- United States
- Prior art keywords
- data
- data blocks
- database system
- tablespace
- database
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Abandoned
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
- G06F16/28—Databases characterised by their database models, e.g. relational or object models
- G06F16/283—Multi-dimensional databases or data warehouses, e.g. MOLAP or ROLAP
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/90—Details of database functions independent of the retrieved data types
- G06F16/901—Indexing; Data structures therefor; Storage structures
- G06F16/9017—Indexing; Data structures therefor; Storage structures using directory or table look-up
-
- Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y10—TECHNICAL SUBJECTS COVERED BY FORMER USPC
- Y10S—TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y10S707/00—Data processing: database and file management or data structures
- Y10S707/99931—Database or file accessing
- Y10S707/99938—Concurrency, e.g. lock management in shared database
-
- Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y10—TECHNICAL SUBJECTS COVERED BY FORMER USPC
- Y10S—TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y10S707/00—Data processing: database and file management or data structures
- Y10S707/99941—Database schema or data structure
- Y10S707/99942—Manipulating data structure, e.g. compression, compaction, compilation
-
- Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y10—TECHNICAL SUBJECTS COVERED BY FORMER USPC
- Y10S—TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y10S707/00—Data processing: database and file management or data structures
- Y10S707/99951—File or database maintenance
- Y10S707/99952—Coherency, e.g. same view to multiple users
- Y10S707/99955—Archiving or backup
Definitions
- the present invention relates to database systems, and in particular, to techniques for efficiently moving data between database systems.
- a data warehouse represents a transformation of raw data.
- the raw data used by the warehouse typically comes from a “source” database system, such as an online transaction processing (“OLTP”) database.
- the OLTP database system is oriented towards the “real time” operation of a business, while the data warehouse is oriented toward answering longer range, management oriented, questions about the business.
- the data warehouse house is periodically updated with information from the OLTP database system. These updates entail transfers of large quantities of data.
- a conventional technique for transferring data is the command generation technique.
- an “exporting” database system generates a file of insert commands.
- the insert commands conform to a database language, such as the structured query language (“SQL”).
- SQL structured query language
- an “importing” database system which is capable of executing commands written in the database language, scans the file, executing each insert command.
- Executing an insert command for each record to export is typically a slow process, one which may span days for larger databases. While data is being exported, access to the data is restricted. Consequently, the database user, who requires access to the data, may be significantly impacted. Thus, conventional techniques for exporting data may be significantly burdensome.
- ETL extraction, transformation, and loading.
- ETL tools extract data from a source database system by issuing queries to the source database system to retrieve data.
- ETL tools load data in the data warehouse by issuing insert commands to the data warehouse to load the data retrieved from the source database system. While the use of ETL tools may be more efficient than the command generation technique, the process of transferring data may still require undesirably long periods of time.
- a novel technique that is much more efficient than the conventional techniques for transferring data is referred to as transportable tablespaces.
- a tablespace is a collection of storage containers (e.g. data files) used to store data for database objects.
- Database objects are objects managed by a database system.
- Transportable tablespaces is a technique that allows tablespaces to be copied and integrated into another database system, or in other words, “plugged into” the other database system. This capability allows data to be copied using operating system utilities for copying files, which run much faster than the process of extracting and loading data by executing queries and insert statements.
- a data block is an atomic unit of storage space allocated to store one or more database records (e.g. rows).
- a database system is configured to operate upon a database composed of data blocks of one particular size.
- the particular size may be configured by a user when a database is created. Once a database is created, however, the data block size may not be changed. Consequently, a tablespace composed of data blocks of a given size may not be plugged into a database system that expects data blocks of a different block size.
- the source database system and the data warehouse may be configured for the same data block size.
- Described herein is a mechanism that allows a given database system to access data blocks from another database system, where the data blocks from the given database system and data blocks from the other database system have different sizes.
- the data blocks in the other database system are contained in a tablespace.
- the tablespace is detached from the other database system and integrated into the given database, which is capable of processing data stored in data blocks of different sizes.
- FIG. 1 is a block diagram of a database system used to illustrate an embodiment of the present invention
- FIG. 2 is a block diagram of tablespaces and data structures used to support a relative addressing scheme according to an embodiment of the present invention
- FIG. 3 is a block diagram of structures used to support a buffer cache system that handles multiple size data blocks according to an embodiment of the present invention
- FIG. 4 is a flow chart depicting a process for integrating a tablespace into a database system, where data blocks in the tablespace and data blocks in the database system have different block sizes according to an embodiment of the present invention.
- FIG. 5 is a block diagram depicting a computer system that may be used to implement an embodiment of the present invention.
- Described herein is a mechanism that allows a given database system to access data blocks from another database system, where data blocks from the given database system and data blocks from the other database system have different sizes.
- the techniques involve the use of a database system that handles databases with data blocks that have different sizes. These techniques are illustrated using an exemplary database system.
- FIG. 1 is a block diagram that provides an overview of an exemplary database system used to illustrate an embodiment of the present invention.
- Database system 101 processes and stores data in database objects.
- Database objects are objects managed by a database system for the purpose of storing, retrieving, and processing data. Examples of database objects include tables, indexes, and code modules which may be executed by a database system.
- the database objects are stored in static storage, in one or more data blocks in a data file.
- Database system 101 performs operations to data in a database object by performing operations on data blocks that hold the data. Operations on data blocks are carried out on copies of data blocks read into buffer cache 190 from static storage. Copies of the data blocks are stored in buffers in the buffer cache 190 .
- the buffers are shared by all user processes concurrently connected to database system 101 .
- a copy of a data block is loaded into buffer cache 190 whenever database system 101 performs an operation involving a data item stored in the data block, such as a row in a table. If the operation changes the data item, the change is made to the copy of the data block stored in buffer cache 190 . Afterwards, a database writer writes the modified blocks of data from buffer cache 190 to the data files on disk.
- Data for a particular set of database objects may be stored in space allocated from one or more tablespaces, such as tablespaces 130 , 140 , and 150 .
- a tablespace is a collection of storage containers (e.g. data files) used to store data for database objects.
- tablespace 130 contains data files 130 - 1 to 130 - 4 .
- a database object may be referred to as being in a particular tablespace when the tablespace holds data for the database object.
- Database metadata 110 is metadata that describes the configuration of a database system.
- Database metadata 110 defines, for example, database objects (e.g. tables and indexes for tables), tablespaces, and what tablespaces to use to store data for a table or index.
- Database metadata is generated in response to receiving data definition commands from a user.
- a user issues database commands to a database system to modify the configuration of a database system to define, for example, the database objects in the database system, the attributes of database objects, and the tablespaces that hold data for the database objects.
- Data definition commands must conform to a data definition language recognized by a database system, such as SQL.
- Database system 101 may encounter problems that can halt the operation of a database or affect the writing of database information to disk.
- Common types of failures include process failures, involving a failure in a user, server, or background process of a database instance, or media failures, involving a physical problem reading or writing physical files needed for normal database operation.
- a major aspect of database operation and administration involves the recovery of the database from the various types of failures encountered.
- a logging mechanism entails recording all changes made to a database system by maintaining a log for the database system.
- Several different operation logs are maintained to perform various database maintenance functions.
- a redo log is used to store database operations so that the operations can be re-performed to restore the database to its pre-failure state after a failure. For example, when a transaction modifies data in the buffer cache 190 , a redo entry that specifies the modification is stored in a redo log on disk. If a failure occurs before the updated data within the buffer cache has been stored to disk, the modified data in the buffer cache 190 may be lost. Under these conditions, during the recovery process, the database may be modified to include the lost change based on the redo entry.
- the basic component of a log system is a group of one or more log files used to store redo and undo entries.
- Log files group 180 includes data files 150 - 1 to 150 - 4 in tablespace 150 .
- Redo and undo entries store low-level representations of database changes. Redo entries contain the information necessary to redo changes made by data operations such as INSERT, UPDATE, DELETE, CREATE, ALTER, or DROP. Conversely, undo entries contain the information necessary to undo changes made by data operations.
- the redo or undo entries in the redo log file group in static storage are referred to as redo logs.
- Transportable tablespaces refers to a technique for transferring data between database systems that is based on integrating copies of tablespaces from a “source database system” into a “target database system”. Integrating a copy of a tablespace involves altering the database metadata of the target database by modifying or adding data to define the tablespace as any other tablespace used by the database system, as shall be described in greater detail. Examples of techniques for integrating tablespaces are described in Pluggable Tablespaces and Tablespace-Relative Database Pointers.
- the database metadata may be altered using a variety of techniques. Utilities available on the source database system may be executed to export the metadata into an “export control file”, and utilities on the target database system may be executed to reconstruct metadata from the export control file. Alternately, exported metadata could be included with the data being transported in the tablespace, and the target database would reconstruct the metadata from the data included in the tablespace. A user could manually reconstruct the metadata on the target database system. Finally, utilities on the source database system could examine the data in the tablespaces to derive the metadata.
- copy refers to both the source data and a duplicate of the source data.
- a copy of a source data file may be the source data file itself, or another data file that is a duplicate generated using readily available copy utilities, such as operating system utilities for creating copies of data files.
- a tablespace may be integrated into a database by detaching the tablespace from the original source database or by creating a separate copy to integrate. While the copy is being made, operations on the tablespace should be restricted to read-only operations.
- the source database may need to be configured so that the source database system no longer uses the tablespace to store data.
- Configuring the source database may entail altering database metadata in the source database system, by, for example, removing data defining the tablespace as part of the source database system, or setting a flag to indicate that the tablespace is no longer used.
- a reason a detached tablespace or a separate copy of it is integrated is that many database systems are not configured to directly access a data file concurrently with other database systems.
- the term “directly access” refers to accessing data in a data container, such as data in a data file, without having to request that another database system provide the data.
- An example of a database system directly accessing a data container is a database system running on a computer invoking an operating system function to access a data file residing on either a disk drive connected to a bus of the computer or a disk drive connected to a server coupled to the computer via a network.
- An example of not directly accessing a data file is issuing a query to another database requesting data from a table.
- a reference is data that indicates the location of a particular data item stored in a database. References are used by database systems in many scenarios. For example, a database system may use references in an index of a column of a table. The index maps values for the column to rows in the table containing those values. Each entry in the index maps a particular value to a row, and stores a reference to the location of the row.
- a reference for a data item may contain information identifying the particular data container that contains the data item. Such information may include a database-relative file number.
- a database-relative file number is a number used by a database system to uniquely identify a data file relative to any other data files used by the database system.
- a reference to a particular data item such as a row or an object, may include a data file number of the data file containing the data block holding the data item.
- the reference may include an offset into the file to identify a data block's location within the file.
- a database-relative file number on one database system may be used to identify a different data file on another database system.
- This problem may be overcome by using several measures. First, data files transferred to another database system could be assigned new database-relative file numbers. Second, because the transferred data files may contain data objects with references holding database-relative file numbers, these references would have to be modified to reflect the newly assigned database-relative file numbers. For example, a set of data files is transferred from one database system to another database system. The data files are assigned new database-relative file numbers. The data files may hold a portion of a table and an index indexing rows in the table. The references in the index may contain database-relative file numbers that should be changed to reflect newly assigned database-relative file numbers.
- FIG. 2 is a block diagram that depicts a relative addressing scheme used to illustrate an embodiment of the present invention.
- FIG. 2 illustrates identifiers used to identify tablespaces and data files, and the relationship between them, and other elements upon which the relative addressing scheme hinges.
- database system 101 (not shown) associates tablespace numbers (TSNs) 9 and 8 with tablespaces 130 and 140 , respectively.
- TSNs tablespace numbers
- database system 101 defines a tablespace, it associates a tablespace number with the tablespace.
- a tablespace number uniquely identifies a tablespace.
- database system 101 associates a tablespace-relative file number (TRFN) with each data file in a tablespace.
- TRFN tablespace-relative file number
- a tablespace-relative file number is unique relative to other data files in the tablespace, but not to other data files in other tablespaces.
- tablespace 130 the tablespace-relative file numbers assigned to data files 130 - 1 , 130 - 2 , 130 - 3 and 130 - 4 are 1, 2, 3 and 4, respectively.
- tablespace-relative file numbers assigned to data files 140 - 1 , 140 - 2 , 140 - 3 and 140 - 4 are 1, 2, 3 and 4, respectively.
- Database system 101 associates a control file with each tablespace.
- the control file maps a tablespace-relative file number to a database-relative file number, and hence maps a data file within a tablespace to a database-relative file number.
- Control file 210 is associated with tablespace 130
- control file 220 is associated with tablespace 140 .
- Control file 210 includes two fields: (1) tablespace-relative file number 212 (“TRFN 212 ”) and database-relative file number (DRFN 214 ), (2) and entries 210 - 1 through 210 - 4 , which each contain a value for TRFN 212 and DRFN 214 .
- Entry 210 - 1 maps tablespace-relative file number ‘1’ to database-relative file number ‘12’.
- Control file 220 is structured similarly relative to tablespace 140 .
- Any data file in a tablespace can be identified by a tablespace number and a tablespace-relative file number.
- a “data block pointer” in an index entry refers to the data block containing a particular row.
- the data block resides in data file 130 - 1 .
- the data block pointer contains the value ‘9’ as the tablespace reference number and the value ‘1’ as the tablespace-relative file number, thereby identifying tablespace 130 and data file 130 - 1 .
- the data file can be identified using the following procedure. Given the tablespace number and tablespace-relative file number, the control list associated with the tablespace-relative file number is accessed to find the database-relative file number mapped to the tablespace-relative file number. In control file 210 , entry 210 - 4 maps the tablespace-relative file number ‘4’ to database-relative file number 42 , which identifies data file 130 - 4 .
- a set of tablespaces is self contained when there are no references to any data item in the set that refer to any data item outside the set. For example, if the tablespace holds data for an index of a table in another tablespace, then the tablespace is not self contained. If a set of tablespaces is not self-contained, several measures may be used to render the tables self contained.
- the data in the tablespace may be modified to make the set of tablespaces self contained.
- the makeup of the set of tablespaces can be modified by, for example, removing tablespaces from the set or adding additional tablespaces.
- Database metadata 110 stores data mapping tablespace numbers to tablespaces, data files to database-relative file numbers, and, for a particular tablespace, tablespace-relative file numbers to database-relative file numbers of data files.
- database system 101 When database system 101 is configured to access a data file, database system 101 generates a new database-relative file number for the file and updates database metadata 110 accordingly.
- database system 101 When database system 101 is configured to access a data file as part of a tablespace, database system 101 generates for the data file a new tablespace-relative file number that is unique relative to other data files in the tablespace and updates database metadata 110 accordingly.
- the present invention is not limited to any particular technique for transportable tablespaces, or any technique for integrating data files from a database system into another database system.
- a database system that supports multi-size data blocks may have several capabilities. These include the capability to manage a buffer cache that can store copies of different sized data blocks, and the capability to generate undo records for data that is stored in different sized data blocks.
- FIG. 3 depicts components of database system 101 used to manage caching different sized data blocks in buffer cache 190 .
- buffer cache 190 has buffers of different sizes for storing data blocks of different sizes: buffer 392 has block size A, buffer 394 has block size B, buffer 396 has block size C, buffer 398 has block size D.
- a buffer in buffer cache 190 may be any of a number of discrete data block sizes defined by database metadata 110 .
- Database system 101 may also define a default data block size to use as shall be further described.
- all data blocks within a tablespace have the same size.
- the commands may include a parameter that specifies the data block size of data blocks in the tablespace. If no size is specified for the tablespace, then the default data block size is the data block size for the tablespace.
- Block size mapping 330 is used to map data files to data block sizes. Specifically, block size mapping 330 maps the “database-relative” file number of a data file to the block size of data blocks contained in the data file. Block size mapping 330 includes block size mapping entries 332 and columns database-relative file number 336 and block size 334 . An entry in block size mapping entries 332 maps the database-relative file number value in column database-relative file number 336 to the block size value in block size 334 .
- Database-relative number mapping 320 maps the tablespace number and tablespace-relative file number of a data file to the database-relative number of the data file.
- Database-relative number mapping 320 includes database-relative number mapping entries 322 and columns tablespace number 325 , tablespace-relative file number 326 , and database-relative number 324 .
- An entry in database-relative number mapping entries 322 maps the pair of values in columns tablespace number 325 and tablespace-relative file number 326 to the database-relative number in database-relative number 324 .
- Database system 101 may use both the database-relative number mapping 320 and block size mapping 330 to determine what size buffer is needed to store a data block before reading a data block from static storage. Given a tablespace number and tablespace-relative number of a data file, the block size can be found by initially examining database-relative number mapping 320 to find the database-relative number. From the database-relative number, the block size can be determined by examining block size mapping 330 .
- database system 101 receives a request to read a data block DBR pointed to by data block pointer R.
- Data block pointer R specifies the tablespace number and tablespace-relative file number of the tablespace and data file containing the data block, and an offset indicating where the data block begins within the data file.
- Database system 101 examines the database-relative number mapping 320 and block size mapping 330 to determine that blocks size C is the data block size of the data block DBR. Database system 101 then loads the data block from static storage into a buffer in buffer cache 190 of block size C.
- a data block pointer may contain a database-relative file number.
- Database system 101 uses only block size mapping 330 to determine the block size for the buffer needed to store the data block referred to by the data block pointer.
- undo entries contain the data (“undo data”) needed to undo a change made by database operations. More data blocks may be needed to store undo data than are needed to store the data that has been changed. There are at least several causes for this.
- the amount of undo data may be inherently greater than the amount of changed data. In other words, a change to all user data in one data block of size X may require more undo data than can be stored in one data block of the same size X.
- the changed data is stored in data blocks that have a greater size than the data blocks used to store the undo log.
- tablespace 150 holds log file 150 .
- Tablespace 150 may be configured for data block sizes that are less than the data block size for which tablespace 130 is configured. Because of the difference in data block sizes, undo data for a data block in tablespace 130 may require more data blocks in tablespace 150 than would be needed if the data block sizes for the tablespaces were equal.
- database system 101 is configured to store undo data in more than one data block. This feature allows database system 101 to handle differences in sizes between the undo data and the corresponding changed data, whether the size of the undo data is inherently greater than that of the changed data, or is stored in data blocks smaller in size than the data blocks that store the changed data.
- FIG. 4 is a flowchart depicting the steps of a process for integrating a tablespace into a target database system from a source database system, where the tablespace includes data blocks that have a different data block size than at least a subset of data blocks used by the target database system to store data.
- the process is illustrated using database system 101 .
- database system 101 determines the block size of the tablespace to integrate into database system 101 .
- the determination may be made in any of a variety of ways. For example, database system 101 may examine an export control file generated for the tablespace to determine the data block size. Alternately, database system 101 may examine the tablespace, scanning for data structures that mark the boundaries of data blocks, and determining the amount of data that lies within the boundaries. Finally, database system 101 may prompt the user for the data block size.
- database system 101 determines whether it may integrate a tablespace of the data block size determined at step 410 . If database system 101 determines that it cannot integrate a tablespace of the data block size, then execution of the steps proceeds to step 490 , where database system 101 aborts the process of integrating the tablespace. Otherwise, execution proceeds to step 430 .
- the determination of whether a database system 101 may integrate a tablespace of the data block size may be made using a variety of techniques. If database system 101 supports discrete data block sizes defined by database metadata 110 , then database system 101 examines the database metadata to determine whether the data block size in question is one of the supported discrete block sizes. If database system 101 is hard coded to support discrete block sizes, then database system 101 may simply be hard coded to compare the data block size in question to one of the supported discrete block sizes.
- the database system 101 integrates the tablespace into database system 101 .
- the tablespace is integrated using any of the techniques for integrating tablespaces into database systems discussed earlier.
- the techniques for transporting data blocks of a given size to a database system having data blocks of a different size offer advantages over conventional techniques for transporting data between database systems.
- Use of transportable tablespaces allows data to be moved between databases much more quickly than conventional techniques for importing data.
- the target database is not restricted to using the same data block size as the source database, and may be configured to use data block sizes that are optimal for the target database.
- a data warehouse may be configured to hold data in bigger data blocks than OLTP source databases.
- data from the tablespace may be extracted and loaded into a tablespace having an optimal data block size.
- the tables contained in a transported tablespace, once integrated into a data warehouse may serve as staging tables.
- Data from the staging tables is extracted, transformed, and loaded into tables that serve as the primary online repository for the data warehouse. Extracting data from tables internal to a database system is typically performed far more efficiently than extracting data from another database's table.
- FIG. 5 is a block diagram that illustrates a computer system 500 upon which an embodiment of the invention may be implemented.
- Computer system 500 includes a bus 502 or other communication mechanism for communicating information, and a processor 504 coupled with bus 502 for processing information.
- Computer system 500 also includes a main memory 506 , such as a random access memory (RAM) or other dynamic storage device, coupled to bus 502 for storing information and instructions to be executed by processor 504 .
- Main memory 506 also may be used for storing temporary variables or other intermediate information during execution of instructions to be executed by processor 504 .
- Computer system 500 further includes a read only memory (ROM) 508 or other static storage device coupled to bus 502 for storing static information and instructions for processor 504 .
- ROM read only memory
- a storage device 510 such as a magnetic disk or optical disk, is provided and coupled to bus 502 for storing information and instructions.
- Computer system 500 may be coupled via bus 502 to a display 512 , such as a cathode ray tube (CRT), for displaying information to a computer user.
- a display 512 such as a cathode ray tube (CRT)
- An input device 514 is coupled to bus 502 for communicating information and command selections to processor 504 .
- cursor control 516 is Another type of user input device
- cursor control 516 such as a mouse, a trackball, or cursor direction keys for communicating direction information and command selections to processor 504 and for controlling cursor movement on display 512 .
- This input device typically has two degrees of freedom in two axes, a first axis (e.g., x) and a second axis (e.g., y), that allows the device to specify positions in a plane.
- the invention is related to the use of computer system 500 for implementing the techniques described herein. According to one embodiment of the invention, those techniques are performed by computer system 500 in response to processor 504 executing one or more sequences of one or more instructions contained in main memory 506 . Such instructions may be read into main memory 506 from another computer-readable medium, such as storage device 510 . Execution of the sequences of instructions contained in main memory 506 causes processor 504 to perform the process steps described herein. In alternative embodiments, hard-wired circuitry may be used in place of or in combination with software instructions to implement the invention. Thus, embodiments of the invention are not limited to any specific combination of hardware circuitry and software.
- Non-volatile media includes, for example, optical or magnetic disks, such as storage device 510 .
- Volatile media includes dynamic memory, such as main memory 506 .
- Transmission media includes coaxial cables, copper wire and fiber optics, including the wires that comprise bus 502 . Transmission media can also take the form of acoustic or light waves, such as those generated during radio-wave and infra-red data communications.
- Computer-readable media include, for example, a floppy disk, a flexible disk, hard disk, magnetic tape, or any other magnetic medium, a CD-ROM, any other optical medium, punchcards, papertape, any other physical medium with patterns of holes, a RAM, a PROM, and EPROM, a FLASH-EPROM, any other memory chip or cartridge, a carrier wave as described hereinafter, or any other medium from which a computer can read.
- Various forms of computer readable media may be involved in carrying one or more sequences of one or more instructions to processor 504 for execution.
- the instructions may initially be carried on a magnetic disk of a remote computer.
- the remote computer can load the instructions into its dynamic memory and send the instructions over a telephone line using a modem.
- a modem local to computer system 500 can receive the data on the telephone line and use an infra-red transmitter to convert the data to an infra-red signal.
- An infra-red detector can receive the data carried in the infra-red signal and appropriate circuitry can place the data on bus 502 .
- Bus 502 carries the data to main memory 506 , from which processor 504 retrieves and executes the instructions.
- the instructions received by main memory 506 may optionally be stored on storage device 510 either before or after execution by processor 504 .
- Computer system 500 also includes a communication interface 518 coupled to bus 502 .
- Communication interface 518 provides a two-way data communication coupling to a network link 520 that is connected to a local network 522 .
- communication interface 518 may be an integrated services digital network (ISDN) card or a modem to provide a data communication connection to a corresponding type of telephone line.
- ISDN integrated services digital network
- communication interface 518 may be a local area network (LAN) card to provide a data communication connection to a compatible LAN.
- LAN local area network
- Wireless links may also be implemented.
- communication interface 518 sends and receives electrical, electromagnetic or optical signals that carry digital data streams representing various types of information.
- Network link 520 typically provides data communication through one or more networks to other data devices.
- network link 520 may provide a connection through local network 522 to a host computer 524 or to data equipment operated by an Internet Service Provider (ISP) 526 .
- ISP 526 in turn provides data communication services through the world wide packet data communication network now commonly referred to as the “Internet” 528 .
- Internet 528 uses electrical, electromagnetic or optical signals that carry digital data streams.
- the signals through the various networks and the signals on network link 520 and through communication interface 518 which carry the digital data to and from computer system 500 , are exemplary forms of carrier waves transporting the information.
- Computer system 500 can send messages and receive data, including program code, through the network(s), network link 520 and communication interface 518 .
- a server 530 might transmit a requested code for an application program through Internet 528 , ISP 526 , local network 522 and communication interface 518 .
- the received code may be executed by processor 504 as it is received, and/or stored in storage device 510 , or other non-volatile storage for later execution. In this manner, computer system 500 may obtain application code in the form of a carrier wave.
Landscapes
- Engineering & Computer Science (AREA)
- Databases & Information Systems (AREA)
- Theoretical Computer Science (AREA)
- Data Mining & Analysis (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Software Systems (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Abstract
Provided herein is a mechanism that allows a given database system to access data blocks from another database system, where data blocks from the given database system and data blocks from the other database system have different sizes. According to an aspect of the present invention, a tablespace in the other database system contained the data blocks. The tablespace is detached from the other database system and integrated into the given database, which is capable of processing data stored in data blocks of different sizes.
Description
- The present application is a continuation of and claims priority to U.S. application Ser. No. 09/871,476 entitled “Integrating Tablespaces with Different Block Sizes”, filed May 30, 2001, by Sreedhar Mukkamalla, et al., which is (1) a continuation-in-part of U.S. application Ser. No. 08/865,693, now U.S. Pat. No. 6,272,503 B1, entitled “Tablespace-Relative Database Pointers”, filed on May 30, 1997 by William H. Bridge, Jr., et al., and (2) a continuation-in-part of U.S. application Ser. No. 09/675,195, now U.S. Pat. No. 6,549,901 B1 entitled “Using Transportable Tablespaces for Hosting Data of Multiple Users”, filed on Sep. 29, 2000, by Juan R. Loaiza, et al. The present application hereby claims priority to and the benefit of the application filing dates for each application listed above, the contents of which are each fully incorporated herein by reference.
- The present application is related to U.S. application Ser. No. 08/852,968, now U.S. Pat. No. 5,890,167 entitled “Pluggable Tablespaces”, filed on May 8, 1997, by William H. Bridge Jr., et al., the contents of which are herein incorporated by reference and referred to as Pluggable Tablespaces.
- The present invention relates to database systems, and in particular, to techniques for efficiently moving data between database systems.
- The ability to store and retrieve large amounts of data are some of the most important functions of computers in today's society. To carry out these functions, database systems are typically used to retrieve and store data in databases. Database systems have performed these functions very successfully, creating for society the ability to retrieve data at speeds and quantities previously unimagined, and bestowing onto society an unprecedented level of access to information. The success of database systems has unleashed an insatiable demand for even faster and more efficient database systems that process even greater quantities of data.
- One mechanism that provides efficient access to large amounts of data is a data warehouse. A data warehouse represents a transformation of raw data. The raw data used by the warehouse typically comes from a “source” database system, such as an online transaction processing (“OLTP”) database. The OLTP database system is oriented towards the “real time” operation of a business, while the data warehouse is oriented toward answering longer range, management oriented, questions about the business. To stay current, the data warehouse house is periodically updated with information from the OLTP database system. These updates entail transfers of large quantities of data.
- A conventional technique for transferring data is the command generation technique. Under the command generation technique, an “exporting” database system generates a file of insert commands. The insert commands conform to a database language, such as the structured query language (“SQL”). For each record being exported, an insert command specifies the creation of a record with the values needed to generate a copy of the record being exported. To import the data, an “importing” database system, which is capable of executing commands written in the database language, scans the file, executing each insert command.
- Executing an insert command for each record to export is typically a slow process, one which may span days for larger databases. While data is being exported, access to the data is restricted. Consequently, the database user, who requires access to the data, may be significantly impacted. Thus, conventional techniques for exporting data may be significantly burdensome.
- Another conventional technique for moving data into a data warehouse involves the use of tools available in applications used to manage data warehouses. These tools transfer data between a source database and a data warehouse using a process that has three stages: extracting data from the source database system, transforming the extracted data, and loading the transformed data into the data warehouse. These stages are referred to collectively as ETL, which stands for extraction, transformation, and loading. In general, ETL tools extract data from a source database system by issuing queries to the source database system to retrieve data. ETL tools load data in the data warehouse by issuing insert commands to the data warehouse to load the data retrieved from the source database system. While the use of ETL tools may be more efficient than the command generation technique, the process of transferring data may still require undesirably long periods of time.
- A novel technique that is much more efficient than the conventional techniques for transferring data is referred to as transportable tablespaces. A tablespace is a collection of storage containers (e.g. data files) used to store data for database objects. Database objects are objects managed by a database system. Transportable tablespaces is a technique that allows tablespaces to be copied and integrated into another database system, or in other words, “plugged into” the other database system. This capability allows data to be copied using operating system utilities for copying files, which run much faster than the process of extracting and loading data by executing queries and insert statements.
- Unfortunately, it is not always possible to plug in a tablespace from one database system to another because the database systems may not be configured to handle the same data block size. A data block is an atomic unit of storage space allocated to store one or more database records (e.g. rows). Typically, a database system is configured to operate upon a database composed of data blocks of one particular size. In some systems, the particular size may be configured by a user when a database is created. Once a database is created, however, the data block size may not be changed. Consequently, a tablespace composed of data blocks of a given size may not be plugged into a database system that expects data blocks of a different block size.
- It is possible to overcome this limitation by managing the data block sizes of both the data warehouse and its source database systems. The source database system and the data warehouse may be configured for the same data block size. However, for purposes of efficiency, it is usually desirable to have larger block sizes for data warehouses and smaller block sizes for OLTP systems. For this reason, data warehouses typically have larger block sizes than OLTP systems.
- Based on the foregoing, it is clearly desirable to provide a mechanism that allows a tablespace or any collection of data blocks of a given size to be plugged into a database system that operates on data blocks of a different size.
- Described herein is a mechanism that allows a given database system to access data blocks from another database system, where the data blocks from the given database system and data blocks from the other database system have different sizes. According to an aspect of the present invention, the data blocks in the other database system are contained in a tablespace. The tablespace is detached from the other database system and integrated into the given database, which is capable of processing data stored in data blocks of different sizes.
- The present invention is illustrated by way of example, and not by way of limitation, in the figures of the accompanying drawings and in which like reference numerals refer to similar elements and in which:
-
FIG. 1 is a block diagram of a database system used to illustrate an embodiment of the present invention; -
FIG. 2 is a block diagram of tablespaces and data structures used to support a relative addressing scheme according to an embodiment of the present invention; -
FIG. 3 is a block diagram of structures used to support a buffer cache system that handles multiple size data blocks according to an embodiment of the present invention; -
FIG. 4 is a flow chart depicting a process for integrating a tablespace into a database system, where data blocks in the tablespace and data blocks in the database system have different block sizes according to an embodiment of the present invention; and -
FIG. 5 is a block diagram depicting a computer system that may be used to implement an embodiment of the present invention. - A method and apparatus for transferring data between databases is described. In the following description, for the purposes of explanation, numerous specific details are set forth in order to provide a thorough understanding of the present invention. It will be apparent, however, to one skilled in the art that the present invention may be practiced without these specific details. In other instances, well-known structures and devices are shown in block diagram form in order to avoid unnecessarily obscuring the present invention.
- Described herein is a mechanism that allows a given database system to access data blocks from another database system, where data blocks from the given database system and data blocks from the other database system have different sizes. According to an embodiment of the present invention, the techniques involve the use of a database system that handles databases with data blocks that have different sizes. These techniques are illustrated using an exemplary database system.
-
FIG. 1 is a block diagram that provides an overview of an exemplary database system used to illustrate an embodiment of the present invention.Database system 101 processes and stores data in database objects. Database objects are objects managed by a database system for the purpose of storing, retrieving, and processing data. Examples of database objects include tables, indexes, and code modules which may be executed by a database system. Typically, the database objects are stored in static storage, in one or more data blocks in a data file. -
Database system 101 performs operations to data in a database object by performing operations on data blocks that hold the data. Operations on data blocks are carried out on copies of data blocks read intobuffer cache 190 from static storage. Copies of the data blocks are stored in buffers in thebuffer cache 190. The buffers are shared by all user processes concurrently connected todatabase system 101. A copy of a data block is loaded intobuffer cache 190 wheneverdatabase system 101 performs an operation involving a data item stored in the data block, such as a row in a table. If the operation changes the data item, the change is made to the copy of the data block stored inbuffer cache 190. Afterwards, a database writer writes the modified blocks of data frombuffer cache 190 to the data files on disk. - Data for a particular set of database objects may be stored in space allocated from one or more tablespaces, such as
tablespaces tablespace 130 contains data files 130-1 to 130-4. A database object may be referred to as being in a particular tablespace when the tablespace holds data for the database object. -
Database metadata 110 is metadata that describes the configuration of a database system.Database metadata 110 defines, for example, database objects (e.g. tables and indexes for tables), tablespaces, and what tablespaces to use to store data for a table or index. Database metadata is generated in response to receiving data definition commands from a user. A user issues database commands to a database system to modify the configuration of a database system to define, for example, the database objects in the database system, the attributes of database objects, and the tablespaces that hold data for the database objects. Data definition commands must conform to a data definition language recognized by a database system, such as SQL. -
Database system 101 may encounter problems that can halt the operation of a database or affect the writing of database information to disk. Common types of failures include process failures, involving a failure in a user, server, or background process of a database instance, or media failures, involving a physical problem reading or writing physical files needed for normal database operation. A major aspect of database operation and administration involves the recovery of the database from the various types of failures encountered. - One mechanism that
database system 101 uses to manage recovery from failures is a logging mechanism. A logging mechanism entails recording all changes made to a database system by maintaining a log for the database system. Several different operation logs are maintained to perform various database maintenance functions. Specifically, a redo log is used to store database operations so that the operations can be re-performed to restore the database to its pre-failure state after a failure. For example, when a transaction modifies data in thebuffer cache 190, a redo entry that specifies the modification is stored in a redo log on disk. If a failure occurs before the updated data within the buffer cache has been stored to disk, the modified data in thebuffer cache 190 may be lost. Under these conditions, during the recovery process, the database may be modified to include the lost change based on the redo entry. - The basic component of a log system is a group of one or more log files used to store redo and undo entries. Log
files group 180 includes data files 150-1 to 150-4 intablespace 150. Redo and undo entries store low-level representations of database changes. Redo entries contain the information necessary to redo changes made by data operations such as INSERT, UPDATE, DELETE, CREATE, ALTER, or DROP. Conversely, undo entries contain the information necessary to undo changes made by data operations. The redo or undo entries in the redo log file group in static storage are referred to as redo logs. - Transportable tablespaces refers to a technique for transferring data between database systems that is based on integrating copies of tablespaces from a “source database system” into a “target database system”. Integrating a copy of a tablespace involves altering the database metadata of the target database by modifying or adding data to define the tablespace as any other tablespace used by the database system, as shall be described in greater detail. Examples of techniques for integrating tablespaces are described in Pluggable Tablespaces and Tablespace-Relative Database Pointers.
- The database metadata may be altered using a variety of techniques. Utilities available on the source database system may be executed to export the metadata into an “export control file”, and utilities on the target database system may be executed to reconstruct metadata from the export control file. Alternately, exported metadata could be included with the data being transported in the tablespace, and the target database would reconstruct the metadata from the data included in the tablespace. A user could manually reconstruct the metadata on the target database system. Finally, utilities on the source database system could examine the data in the tablespaces to derive the metadata.
- The term “copy,” as used herein, refers to both the source data and a duplicate of the source data. For example, a copy of a source data file may be the source data file itself, or another data file that is a duplicate generated using readily available copy utilities, such as operating system utilities for creating copies of data files.
- A tablespace may be integrated into a database by detaching the tablespace from the original source database or by creating a separate copy to integrate. While the copy is being made, operations on the tablespace should be restricted to read-only operations.
- If the copy of the tablespace to integrate is a detached source tablespace, then the source database may need to be configured so that the source database system no longer uses the tablespace to store data. Configuring the source database may entail altering database metadata in the source database system, by, for example, removing data defining the tablespace as part of the source database system, or setting a flag to indicate that the tablespace is no longer used.
- A reason a detached tablespace or a separate copy of it is integrated is that many database systems are not configured to directly access a data file concurrently with other database systems. The term “directly access” refers to accessing data in a data container, such as data in a data file, without having to request that another database system provide the data. An example of a database system directly accessing a data container is a database system running on a computer invoking an operating system function to access a data file residing on either a disk drive connected to a bus of the computer or a disk drive connected to a server coupled to the computer via a network. An example of not directly accessing a data file is issuing a query to another database requesting data from a table.
- A reference is data that indicates the location of a particular data item stored in a database. References are used by database systems in many scenarios. For example, a database system may use references in an index of a column of a table. The index maps values for the column to rows in the table containing those values. Each entry in the index maps a particular value to a row, and stores a reference to the location of the row.
- A reference for a data item may contain information identifying the particular data container that contains the data item. Such information may include a database-relative file number. A database-relative file number is a number used by a database system to uniquely identify a data file relative to any other data files used by the database system. For example, a reference to a particular data item, such as a row or an object, may include a data file number of the data file containing the data block holding the data item. In addition, the reference may include an offset into the file to identify a data block's location within the file.
- Unfortunately, transferring data files between database systems that use references based on database-relative file numbers creates complications. These complications stem from the fact that a database-relative file number may not be unique between database systems. A database-relative file number on one database system may be used to identify a different data file on another database system. This problem may be overcome by using several measures. First, data files transferred to another database system could be assigned new database-relative file numbers. Second, because the transferred data files may contain data objects with references holding database-relative file numbers, these references would have to be modified to reflect the newly assigned database-relative file numbers. For example, a set of data files is transferred from one database system to another database system. The data files are assigned new database-relative file numbers. The data files may hold a portion of a table and an index indexing rows in the table. The references in the index may contain database-relative file numbers that should be changed to reflect newly assigned database-relative file numbers.
- The problem and measures attendant database-relative file numbers may be avoided by the use of a relative addressing scheme that addresses data files relative to the tablespace that contains the data file. The use of a relative addressing scheme also facilitates transportable tablespace processing, which as mentioned before, is a technique for transferring data between database systems using a process that includes moving or copying a tablespace. Examples of such techniques are described in Pluggable Tablespaces and Tablespace-Relative Database Pointers.
FIG. 2 is a block diagram that depicts a relative addressing scheme used to illustrate an embodiment of the present invention.FIG. 2 illustrates identifiers used to identify tablespaces and data files, and the relationship between them, and other elements upon which the relative addressing scheme hinges. - Referring to
FIG. 2 , database system 101 (not shown) associates tablespace numbers (TSNs) 9 and 8 withtablespaces database system 101 defines a tablespace, it associates a tablespace number with the tablespace. Within a given database system, a tablespace number uniquely identifies a tablespace. - Within a tablespace,
database system 101 associates a tablespace-relative file number (TRFN) with each data file in a tablespace. For a given data file in a tablespace, a tablespace-relative file number is unique relative to other data files in the tablespace, but not to other data files in other tablespaces. Fortablespace 130, the tablespace-relative file numbers assigned to data files 130-1, 130-2, 130-3 and 130-4 are 1, 2, 3 and 4, respectively. Fortablespace 140, the tablespace-relative file numbers assigned to data files 140-1, 140-2, 140-3 and 140-4 are 1, 2, 3 and 4, respectively. -
Database system 101 associates a control file with each tablespace. For each tablespace, the control file maps a tablespace-relative file number to a database-relative file number, and hence maps a data file within a tablespace to a database-relative file number.Control file 210 is associated withtablespace 130, whilecontrol file 220 is associated withtablespace 140.Control file 210 includes two fields: (1) tablespace-relative file number 212 (“TRFN 212”) and database-relative file number (DRFN 214), (2) and entries 210-1 through 210-4, which each contain a value forTRFN 212 andDRFN 214. Entry 210-1 maps tablespace-relative file number ‘1’ to database-relative file number ‘12’.Control file 220 is structured similarly relative totablespace 140. - Any data file in a tablespace can be identified by a tablespace number and a tablespace-relative file number. For example, a “data block pointer” in an index entry refers to the data block containing a particular row. The data block resides in data file 130-1. The data block pointer contains the value ‘9’ as the tablespace reference number and the value ‘1’ as the tablespace-relative file number, thereby identifying
tablespace 130 and data file 130-1. The data file can be identified using the following procedure. Given the tablespace number and tablespace-relative file number, the control list associated with the tablespace-relative file number is accessed to find the database-relative file number mapped to the tablespace-relative file number. Incontrol file 210, entry 210-4 maps the tablespace-relative file number ‘4’ to database-relative file number 42, which identifies data file 130-4. - Transporting data files between database systems is not only facilitated by use of a relative addressing scheme, but also by use of self contained tablespaces. A set of tablespaces is self contained when there are no references to any data item in the set that refer to any data item outside the set. For example, if the tablespace holds data for an index of a table in another tablespace, then the tablespace is not self contained. If a set of tablespaces is not self-contained, several measures may be used to render the tables self contained. The data in the tablespace may be modified to make the set of tablespaces self contained. In addition, the makeup of the set of tablespaces can be modified by, for example, removing tablespaces from the set or adding additional tablespaces.
-
Database metadata 110 stores data mapping tablespace numbers to tablespaces, data files to database-relative file numbers, and, for a particular tablespace, tablespace-relative file numbers to database-relative file numbers of data files. Whendatabase system 101 is configured to access a data file,database system 101 generates a new database-relative file number for the file andupdates database metadata 110 accordingly. Whendatabase system 101 is configured to access a data file as part of a tablespace,database system 101 generates for the data file a new tablespace-relative file number that is unique relative to other data files in the tablespace andupdates database metadata 110 accordingly. - It should be understood that the present invention is not limited to any particular technique for transportable tablespaces, or any technique for integrating data files from a database system into another database system.
- To integrate a tablespace into a database system that stores data in data blocks of a different size than those of the tablespace, the database system should support data blocks of different sizes. A database system that supports multi-size data blocks may have several capabilities. These include the capability to manage a buffer cache that can store copies of different sized data blocks, and the capability to generate undo records for data that is stored in different sized data blocks.
-
FIG. 3 depicts components ofdatabase system 101 used to manage caching different sized data blocks inbuffer cache 190. Referring toFIG. 3 ,buffer cache 190 has buffers of different sizes for storing data blocks of different sizes: buffer 392 has block size A,buffer 394 has block size B,buffer 396 has block size C,buffer 398 has block size D. A buffer inbuffer cache 190 may be any of a number of discrete data block sizes defined bydatabase metadata 110.Database system 101 may also define a default data block size to use as shall be further described. - According to an embodiment of the present invention, all data blocks within a tablespace have the same size. When a user submits DDL commands to define a tablespace, the commands may include a parameter that specifies the data block size of data blocks in the tablespace. If no size is specified for the tablespace, then the default data block size is the data block size for the tablespace.
-
Block size mapping 330 is used to map data files to data block sizes. Specifically,block size mapping 330 maps the “database-relative” file number of a data file to the block size of data blocks contained in the data file.Block size mapping 330 includes blocksize mapping entries 332 and columns database-relative file number 336 andblock size 334. An entry in blocksize mapping entries 332 maps the database-relative file number value in column database-relative file number 336 to the block size value inblock size 334. - Database-
relative number mapping 320 maps the tablespace number and tablespace-relative file number of a data file to the database-relative number of the data file. Database-relative number mapping 320 includes database-relativenumber mapping entries 322 and columns tablespacenumber 325, tablespace-relative file number 326, and database-relative number 324. An entry in database-relativenumber mapping entries 322 maps the pair of values incolumns tablespace number 325 and tablespace-relative file number 326 to the database-relative number in database-relative number 324. -
Database system 101 may use both the database-relative number mapping 320 andblock size mapping 330 to determine what size buffer is needed to store a data block before reading a data block from static storage. Given a tablespace number and tablespace-relative number of a data file, the block size can be found by initially examining database-relative number mapping 320 to find the database-relative number. From the database-relative number, the block size can be determined by examiningblock size mapping 330. - For example,
database system 101 receives a request to read a data block DBR pointed to by data block pointer R. Data block pointer R specifies the tablespace number and tablespace-relative file number of the tablespace and data file containing the data block, and an offset indicating where the data block begins within the data file.Database system 101 examines the database-relative number mapping 320 andblock size mapping 330 to determine that blocks size C is the data block size of the data block DBR.Database system 101 then loads the data block from static storage into a buffer inbuffer cache 190 of block size C. - Likewise, a data block pointer may contain a database-relative file number.
Database system 101 uses onlyblock size mapping 330 to determine the block size for the buffer needed to store the data block referred to by the data block pointer. - As mentioned previously, undo entries contain the data (“undo data”) needed to undo a change made by database operations. More data blocks may be needed to store undo data than are needed to store the data that has been changed. There are at least several causes for this. First, in terms of storage space needed to store data, the amount of undo data may be inherently greater than the amount of changed data. In other words, a change to all user data in one data block of size X may require more undo data than can be stored in one data block of the same size X.
- Second, the changed data is stored in data blocks that have a greater size than the data blocks used to store the undo log. Specifically, in
database system 101,tablespace 150 holdslog file 150.Tablespace 150 may be configured for data block sizes that are less than the data block size for which tablespace 130 is configured. Because of the difference in data block sizes, undo data for a data block intablespace 130 may require more data blocks intablespace 150 than would be needed if the data block sizes for the tablespaces were equal. - For changes made to a particular data block for a transaction,
database system 101 is configured to store undo data in more than one data block. This feature allowsdatabase system 101 to handle differences in sizes between the undo data and the corresponding changed data, whether the size of the undo data is inherently greater than that of the changed data, or is stored in data blocks smaller in size than the data blocks that store the changed data. -
FIG. 4 is a flowchart depicting the steps of a process for integrating a tablespace into a target database system from a source database system, where the tablespace includes data blocks that have a different data block size than at least a subset of data blocks used by the target database system to store data. The process is illustrated usingdatabase system 101. - Referring to
FIG. 4 , atstep 410,database system 101 determines the block size of the tablespace to integrate intodatabase system 101. The determination may be made in any of a variety of ways. For example,database system 101 may examine an export control file generated for the tablespace to determine the data block size. Alternately,database system 101 may examine the tablespace, scanning for data structures that mark the boundaries of data blocks, and determining the amount of data that lies within the boundaries. Finally,database system 101 may prompt the user for the data block size. - At
step 420,database system 101 determines whether it may integrate a tablespace of the data block size determined atstep 410. Ifdatabase system 101 determines that it cannot integrate a tablespace of the data block size, then execution of the steps proceeds to step 490, wheredatabase system 101 aborts the process of integrating the tablespace. Otherwise, execution proceeds to step 430. - The determination of whether a
database system 101 may integrate a tablespace of the data block size may be made using a variety of techniques. Ifdatabase system 101 supports discrete data block sizes defined bydatabase metadata 110, thendatabase system 101 examines the database metadata to determine whether the data block size in question is one of the supported discrete block sizes. Ifdatabase system 101 is hard coded to support discrete block sizes, thendatabase system 101 may simply be hard coded to compare the data block size in question to one of the supported discrete block sizes. - At
step 430, thedatabase system 101 integrates the tablespace intodatabase system 101. The tablespace is integrated using any of the techniques for integrating tablespaces into database systems discussed earlier. - The techniques for transporting data blocks of a given size to a database system having data blocks of a different size offer advantages over conventional techniques for transporting data between database systems. Use of transportable tablespaces allows data to be moved between databases much more quickly than conventional techniques for importing data. Furthermore, because the data blocks in the tablespace do not have to be the same size as that of the data blocks of a target database, the target database is not restricted to using the same data block size as the source database, and may be configured to use data block sizes that are optimal for the target database. For example, a data warehouse may be configured to hold data in bigger data blocks than OLTP source databases.
- Of course, if transported data remains in the tablespaces used to transport the data, data contained therein may be stored in data blocks of a size that is not optimal for the target database. However, it is not necessary that transported data remain in the tablespace used to transport the data.
- Once a tablespace is integrated, data from the tablespace may be extracted and loaded into a tablespace having an optimal data block size. For example, the tables contained in a transported tablespace, once integrated into a data warehouse, may serve as staging tables. Data from the staging tables is extracted, transformed, and loaded into tables that serve as the primary online repository for the data warehouse. Extracting data from tables internal to a database system is typically performed far more efficiently than extracting data from another database's table.
-
FIG. 5 is a block diagram that illustrates acomputer system 500 upon which an embodiment of the invention may be implemented.Computer system 500 includes abus 502 or other communication mechanism for communicating information, and aprocessor 504 coupled withbus 502 for processing information.Computer system 500 also includes amain memory 506, such as a random access memory (RAM) or other dynamic storage device, coupled tobus 502 for storing information and instructions to be executed byprocessor 504.Main memory 506 also may be used for storing temporary variables or other intermediate information during execution of instructions to be executed byprocessor 504.Computer system 500 further includes a read only memory (ROM) 508 or other static storage device coupled tobus 502 for storing static information and instructions forprocessor 504. Astorage device 510, such as a magnetic disk or optical disk, is provided and coupled tobus 502 for storing information and instructions. -
Computer system 500 may be coupled viabus 502 to adisplay 512, such as a cathode ray tube (CRT), for displaying information to a computer user. Aninput device 514, including alphanumeric and other keys, is coupled tobus 502 for communicating information and command selections toprocessor 504. Another type of user input device iscursor control 516, such as a mouse, a trackball, or cursor direction keys for communicating direction information and command selections toprocessor 504 and for controlling cursor movement ondisplay 512. This input device typically has two degrees of freedom in two axes, a first axis (e.g., x) and a second axis (e.g., y), that allows the device to specify positions in a plane. - The invention is related to the use of
computer system 500 for implementing the techniques described herein. According to one embodiment of the invention, those techniques are performed bycomputer system 500 in response toprocessor 504 executing one or more sequences of one or more instructions contained inmain memory 506. Such instructions may be read intomain memory 506 from another computer-readable medium, such asstorage device 510. Execution of the sequences of instructions contained inmain memory 506 causesprocessor 504 to perform the process steps described herein. In alternative embodiments, hard-wired circuitry may be used in place of or in combination with software instructions to implement the invention. Thus, embodiments of the invention are not limited to any specific combination of hardware circuitry and software. - The term “computer-readable medium” as used herein refers to any medium that participates in providing instructions to
processor 504 for execution. Such a medium may take many forms, including but not limited to, non-volatile media, volatile media, and transmission media. Non-volatile media includes, for example, optical or magnetic disks, such asstorage device 510. Volatile media includes dynamic memory, such asmain memory 506. Transmission media includes coaxial cables, copper wire and fiber optics, including the wires that comprisebus 502. Transmission media can also take the form of acoustic or light waves, such as those generated during radio-wave and infra-red data communications. - Common forms of computer-readable media include, for example, a floppy disk, a flexible disk, hard disk, magnetic tape, or any other magnetic medium, a CD-ROM, any other optical medium, punchcards, papertape, any other physical medium with patterns of holes, a RAM, a PROM, and EPROM, a FLASH-EPROM, any other memory chip or cartridge, a carrier wave as described hereinafter, or any other medium from which a computer can read.
- Various forms of computer readable media may be involved in carrying one or more sequences of one or more instructions to
processor 504 for execution. For example, the instructions may initially be carried on a magnetic disk of a remote computer. The remote computer can load the instructions into its dynamic memory and send the instructions over a telephone line using a modem. A modem local tocomputer system 500 can receive the data on the telephone line and use an infra-red transmitter to convert the data to an infra-red signal. An infra-red detector can receive the data carried in the infra-red signal and appropriate circuitry can place the data onbus 502.Bus 502 carries the data tomain memory 506, from whichprocessor 504 retrieves and executes the instructions. The instructions received bymain memory 506 may optionally be stored onstorage device 510 either before or after execution byprocessor 504. -
Computer system 500 also includes acommunication interface 518 coupled tobus 502.Communication interface 518 provides a two-way data communication coupling to anetwork link 520 that is connected to alocal network 522. For example,communication interface 518 may be an integrated services digital network (ISDN) card or a modem to provide a data communication connection to a corresponding type of telephone line. As another example,communication interface 518 may be a local area network (LAN) card to provide a data communication connection to a compatible LAN. Wireless links may also be implemented. In any such implementation,communication interface 518 sends and receives electrical, electromagnetic or optical signals that carry digital data streams representing various types of information. - Network link 520 typically provides data communication through one or more networks to other data devices. For example,
network link 520 may provide a connection throughlocal network 522 to ahost computer 524 or to data equipment operated by an Internet Service Provider (ISP) 526.ISP 526 in turn provides data communication services through the world wide packet data communication network now commonly referred to as the “Internet” 528.Local network 522 andInternet 528 both use electrical, electromagnetic or optical signals that carry digital data streams. The signals through the various networks and the signals onnetwork link 520 and throughcommunication interface 518, which carry the digital data to and fromcomputer system 500, are exemplary forms of carrier waves transporting the information. -
Computer system 500 can send messages and receive data, including program code, through the network(s),network link 520 andcommunication interface 518. In the Internet example, aserver 530 might transmit a requested code for an application program throughInternet 528,ISP 526,local network 522 andcommunication interface 518. - The received code may be executed by
processor 504 as it is received, and/or stored instorage device 510, or other non-volatile storage for later execution. In this manner,computer system 500 may obtain application code in the form of a carrier wave. - In the foregoing specification, the invention has been described with reference to specific embodiments thereof. It will, however, be evident that various modifications and changes may be made thereto without departing from the broader spirit and scope of the invention. The specification and drawings are, accordingly, to be regarded in an illustrative rather than a restrictive sense.
Claims (42)
1. A method for database systems to access data from other database systems, the method comprising the steps of:
a first database system storing in a buffer cache first data blocks having a first data block size, wherein said first database system includes said buffer cache and stores data blocks of multiple sizes within said buffer cache;
concurrently with said first database system storing in said buffer cache first data blocks having a first data block size, said first database system storing in said buffer cache a copy of second data blocks in which a second database system stored second database records;
said second data blocks having at least one data block with a second data block size different than said first data block size; and
wherein each block of said first data blocks and of said second data blocks is an atomic unit of storage space allocated within a file to store one or more records of a database.
2. The method of claim 1 , wherein said buffer cache comprises first buffers for storing buffers of said first data block size and second buffers for storing buffers of said second data block size, and wherein said first buffers are of a different size than said second buffers.
3. The method of claim 1 , wherein the step of accessing a copy of second data blocks includes storing user data in said copy of said second data blocks.
4. The method of claim 1 , wherein the method further includes the step of detaching one or more tablespaces from said second database system, wherein said one or more tablespaces include said second data blocks.
5. The method of claim 1 , further including the step of the first database system generating metadata that specifies a plurality of block sizes for data blocks directly accessible to said first database system.
6. The method of claim 5 , wherein:
the first database system generating metadata that specifies a plurality of block sizes for data blocks directly accessible to said first database system;
wherein said metadata defines tablespaces and specifies for each tablespace of said tablespaces a particular data block size for data blocks in said tablespace; and
wherein the method further comprises the step of integrating said copy of said second data blocks within said first database system as at least one tablespace that includes said copy of said second data blocks, wherein the step of integrating includes modifying said metadata to reflect said second data block size for said at least one tablespace.
7. The method of claim 1 , wherein said first database system is a data warehouse and said second database system is a source database system for said data warehouse.
8. The method of claim 7 , further including the step of integrating said copy of said second data blocks within said data warehouse as a tablespace that includes said copy of said second data blocks.
9. A method for database systems to access data from other database systems, the method comprising the steps of:
a first database system directly storing first database records in first data blocks having a first data block size;
concurrently with said first database system directly storing first database records in first data blocks having a first data block size, said first database system directly accessing a copy of second data blocks in which a second database system directly stored second database records;
said second data blocks having at least one data block with a second data block size different than said first data block size; and
wherein each block of said first data blocks and of said second data blocks is an atomic unit of storage space allocated within a file to store one or more records of a database.
10. The method of claim 9 , wherein the method further includes the step of integrating said copy of said second data blocks within said first database system as a tablespace that includes said copy of said second data blocks.
11. The method of claim 9 , wherein the step of accessing a copy of second data blocks includes storing user data in said copy of said second data blocks.
12. The method of claim 9 , wherein the method further includes the step of detaching one or more tablespaces from said second database system, wherein said one or more tablespaces include said second data blocks.
13. The method of claim 9 , wherein each data block of said copy of said second data blocks has said second data block size.
14. The method of claim 9 , further including the step of the first database system generating metadata that specifies a plurality of block sizes for data blocks directly accessible to said first database system.
15. The method of claim 14 , wherein:
said metadata defines tablespaces and specifies for each tablespace of said tablespaces a particular data block size for all data blocks in said tablespace; and
the method further includes the step of integrating said copy of said second data blocks within said first database system as at least one tablespace that includes said copy of said second data blocks, and
wherein the step of integrating includes modifying said metadata to reflect said second data block size for said at least one tablespace.
16. The method of claim 9 , wherein said first database system is a data warehouse and said second database system is a source database system for said data warehouse.
17. The method of claim 16 , further including the step of integrating said copy of said second data blocks within said data warehouse as a tablespace that includes said copy of said second data blocks.
18. The method of claim 9 ,
wherein first data files contain said first data blocks and second data files contain said second data blocks; and
wherein the method further includes the step of generating a mapping:
between said first data files and said first data block size, and
between said second data files and said second data block size.
19. The method of claim 9 ,
wherein a first tablespace contains said first data blocks and a second tablespace contains said second data blocks; and
wherein the method further includes the step of generating a mapping:
between said first tablespace and said first data block size, and
between said second tablespace and said second data block size.
20. The method of claim 9 , wherein:
a first tablespace includes said first data blocks;
a second tablespace includes said second data blocks; and
the method further includes the step of generating metadata that defines the first data block size as a size of data blocks in said first tablespace and defines the second block size as a size of data blocks in said second tablespace.
21. The method of claim 9 ,
wherein said first database system includes a buffer cache in which said first database system stores data blocks of multiple sizes; and
wherein said method further includes the step of concurrently storing said first data blocks and said second data blocks in said buffer cache.
22. A computer-readable medium carrying one or more sequences of instructions for database systems to access data from other database systems, wherein execution of the one or more sequences of instructions by one or more processors causes the one or more processors to perform the steps of:
a first database system directly storing first database records in first data blocks having a first data block size, wherein said first database system includes a buffer cache in which said first database system stores data blocks of multiple sizes;
concurrently with said first database system directly storing first database records in first data blocks having a first data block size, said first database system directly accessing a copy of second data blocks in which a second database system directly stored second database records;
said second data blocks having at least one data block with a second data block size different than said first data block size;
concurrently storing said first data blocks and said second data blocks in said buffer cache, wherein each block of said first data blocks and of said second data blocks is an atomic unit of storage space allocated within a file to store one or more records of a database.
23. The computer-readable medium of claim 22 , wherein said buffer cache comprises first buffers for storing buffers of said first data block size and second buffers for storing buffers of said second data block size, and wherein said first buffers are of a different size than said second buffers.
24. The computer-readable medium of claim 22 , wherein the step of accessing a copy of second data blocks includes storing user data in said copy of said second data blocks.
25. The computer-readable medium of claim 22 , wherein the method further includes the step of detaching one or more tablespaces from said second database system, wherein said one or more tablespaces include said second data blocks.
26. The computer-readable medium of claim 22 , further including the step of the first database system generating metadata that specifies a plurality of block sizes for data blocks directly accessible to said first database system.
27. The computer-readable medium of claim 26 , wherein:
the first database system generating metadata that specifies a plurality of block sizes for data blocks directly accessible to said first database system;
wherein said metadata defines tablespaces and specifies for each tablespace of said tablespaces a particular data block size for data blocks in said tablespace; and
the computer-readable medium further carrying instructions for integrating said copy of said second data blocks within said first database system as at least one tablespace that includes said copy of said second data blocks, wherein the step of integrating includes modifying said metadata to reflect said second data block size for said at least one tablespace.
28. The computer-readable medium of claim 22 , wherein said first database system is a data warehouse and said second database system is a source database system for said data warehouse.
29. The computer-readable medium of claim 28 , further including the step of integrating said copy of said second data blocks within said data warehouse as a tablespace that includes said copy of said second data blocks.
30. A computer-readable medium carrying one or more sequences of instructions for database systems to access data from other database systems, wherein execution of the one or more sequences of instructions by one or more processors causes the one or more processors to perform the steps of:
a first database system directly storing first database records in first data blocks having a first data block size;
concurrently with said first database system directly storing first database records in first data blocks having a first data block size, said first database system directly accessing a copy of second data blocks in which a second database system directly stored second database records;
said second data blocks having at least one data block with a second data block size different than said first data block size; and
wherein each block of said first data blocks and of said second data blocks is an atomic unit of storage space allocated within a file to store one or more records of a database.
31. The computer-readable medium of claim 30 , wherein the computer-readable medium further includes instructions for performing the step of integrating said copy of said second data blocks within said first database system as a tablespace that includes said copy of said second data blocks.
32. The computer-readable medium of claim 30 , wherein the step of accessing a copy of second data blocks includes storing user data in said copy of said second data blocks.
33. The computer-readable medium of claim 30 , wherein the computer-readable medium further includes instructions for performing the step of detaching one or more tablespaces from said second database system, wherein said one or more tablespaces include said second data blocks.
34. The computer-readable medium of claim 30 , wherein each data block of said copy of said second data blocks has said second data block size.
35. The computer-readable medium of claim 30 , further including instructions for performing the step of the first database system generating metadata that specifies a plurality of block sizes for data blocks directly accessible to said first database system.
36. The computer-readable medium of claim 35 , wherein:
said metadata defines tablespaces and specifies for each tablespace of said tablespaces a particular data block size for all data blocks in said tablespace; and
the computer-readable medium further includes instructions for performing the step of integrating said copy of said second data blocks within said first database system as at least one tablespace that includes said copy of said second data blocks, and
wherein the step of integrating includes modifying said metadata to reflect said second data block size for said at least one tablespace.
37. The computer-readable medium of claim 30 , wherein said first database system is a data warehouse and said second database system is a source database system for said data warehouse.
38. The computer-readable medium of claim 37 , further including instructions for performing the step of integrating said copy of said second data blocks within said data warehouse as a tablespace that includes said copy of said second data blocks.
39. The computer-readable medium of claim 30 ,
wherein first data files contain said first data blocks and second data files contain said second data blocks; and
wherein the computer-readable medium further includes instructions for performing the step of generating a mapping:
between said first data files and said first data block size, and
between said second data files and said second data block size.
40. The computer-readable medium of claim 30 ,
wherein a first tablespace contains said first data blocks and a second tablespace contains said second data blocks; and
wherein the computer-readable medium further includes instructions for performing the step of generating a mapping:
between said first tablespace and said first data block size, and
between said second tablespace and said second data block size.
41. The computer-readable medium of claim 30 ,
wherein said first database system includes a buffer cache in which said first database system stores data blocks of multiple sizes; and
wherein said computer-readable medium further includes the step of concurrently storing said first data blocks and said second data blocks in said buffer cache.
42. The computer-readable medium of claim 30 , wherein:
a first tablespace includes said first data blocks;
a second tablespace includes said second data blocks; and
the computer-readable medium further includes instructions for generating metadata that defines the first data block size as a size of data blocks in said first tablespace and defines the second block size as a size of data blocks in said second tablespace.
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US11/347,644 US20060143187A1 (en) | 1997-05-30 | 2006-02-02 | Integrating tablespaces with different block sizes |
Applications Claiming Priority (4)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US08/865,693 US6272503B1 (en) | 1997-05-30 | 1997-05-30 | Tablespace-relative database pointers |
US09/675,195 US6549901B1 (en) | 1997-05-30 | 2000-09-29 | Using transportable tablespaces for hosting data of multiple users |
US09/871,476 US7031987B2 (en) | 1997-05-30 | 2001-05-30 | Integrating tablespaces with different block sizes |
US11/347,644 US20060143187A1 (en) | 1997-05-30 | 2006-02-02 | Integrating tablespaces with different block sizes |
Related Parent Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US09/871,476 Continuation US7031987B2 (en) | 1997-05-30 | 2001-05-30 | Integrating tablespaces with different block sizes |
Publications (1)
Publication Number | Publication Date |
---|---|
US20060143187A1 true US20060143187A1 (en) | 2006-06-29 |
Family
ID=25357533
Family Applications (2)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US09/871,476 Expired - Lifetime US7031987B2 (en) | 1997-05-30 | 2001-05-30 | Integrating tablespaces with different block sizes |
US11/347,644 Abandoned US20060143187A1 (en) | 1997-05-30 | 2006-02-02 | Integrating tablespaces with different block sizes |
Family Applications Before (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US09/871,476 Expired - Lifetime US7031987B2 (en) | 1997-05-30 | 2001-05-30 | Integrating tablespaces with different block sizes |
Country Status (6)
Country | Link |
---|---|
US (2) | US7031987B2 (en) |
EP (1) | EP1393208A2 (en) |
JP (1) | JP2004530216A (en) |
CN (1) | CN1264107C (en) |
CA (1) | CA2455348A1 (en) |
WO (1) | WO2002097676A2 (en) |
Cited By (9)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US8782101B1 (en) * | 2012-01-20 | 2014-07-15 | Google Inc. | Transferring data across different database platforms |
US20140380004A1 (en) * | 2013-06-06 | 2014-12-25 | Oracle International Corporation | Efficient storage and retrieval of fragmented data using pseudo linear dynamic byte array |
US20150193155A1 (en) * | 2014-01-07 | 2015-07-09 | Apple Inc. | Speculative prefetching of data stored in flash memory |
CN104881418A (en) * | 2014-02-28 | 2015-09-02 | 阿里巴巴集团控股有限公司 | Method and device for quickly reclaiming rollback space in MySQL |
US9268798B2 (en) | 2013-04-26 | 2016-02-23 | Oracle International Corporation | Support for cloud-based multi-tenant environments using connection labeling |
US9569472B2 (en) | 2013-06-06 | 2017-02-14 | Oracle International Corporation | System and method for providing a second level connection cache for use with a database environment |
US9600546B2 (en) | 2013-06-06 | 2017-03-21 | Oracle International Corporation | System and method for marshaling massive database data from native layer to java using linear array |
US9747341B2 (en) | 2013-06-06 | 2017-08-29 | Oracle International Corporation | System and method for providing a shareable global cache for use with a database environment |
US9785687B2 (en) | 2013-06-06 | 2017-10-10 | Oracle International Corporation | System and method for transparent multi key-value weighted attributed connection using uni-tag connection pools |
Families Citing this family (117)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US10191922B2 (en) | 1998-11-24 | 2019-01-29 | Oracle International Corporation | Determining live migration speed based on workload and performance characteristics |
US9239763B2 (en) | 2012-09-28 | 2016-01-19 | Oracle International Corporation | Container database |
CA2279028C (en) * | 1999-07-29 | 2002-09-10 | Ibm Canada Limited-Ibm Canada Limitee | Dropped database table recovery |
US8606744B1 (en) | 2001-09-28 | 2013-12-10 | Oracle International Corporation | Parallel transfer of data from one or more external sources into a database system |
US7487168B2 (en) * | 2001-11-01 | 2009-02-03 | Microsoft Corporation | System and method for loading hierarchical data into relational database systems |
US7124140B2 (en) * | 2001-12-10 | 2006-10-17 | Oracle International Corporation | Database system having heterogeneous object types |
US7343585B1 (en) | 2002-01-30 | 2008-03-11 | Oracle International Corporation | Operator approach for generic dataflow designs |
US20030158944A1 (en) * | 2002-02-19 | 2003-08-21 | International Business Machines Corporation | Software control in a business transaction environment |
US7043491B1 (en) | 2002-05-08 | 2006-05-09 | Oracle International Corporation | Partition exchange technique for operating a data warehousing system |
US7020656B1 (en) | 2002-05-08 | 2006-03-28 | Oracle International Corporation | Partition exchange loading technique for fast addition of data to a data warehousing system |
US6889231B1 (en) | 2002-08-01 | 2005-05-03 | Oracle International Corporation | Asynchronous information sharing system |
US7653632B2 (en) * | 2002-10-01 | 2010-01-26 | Texas Instruments Incorporated | File system for storing multiple files as a single compressed file |
US7299216B1 (en) * | 2002-10-08 | 2007-11-20 | Taiwan Semiconductor Manufacturing Company, Ltd. | Method and apparatus for supervising extraction/transformation/loading processes within a database system |
US7036044B1 (en) * | 2002-11-15 | 2006-04-25 | Microsoft Corporation | Identifying appropriate undo during a forward pass through a log |
US7441033B2 (en) | 2003-08-14 | 2008-10-21 | Oracle International Corporation | On demand node and server instance allocation and de-allocation |
US7873684B2 (en) * | 2003-08-14 | 2011-01-18 | Oracle International Corporation | Automatic and dynamic provisioning of databases |
US7516221B2 (en) | 2003-08-14 | 2009-04-07 | Oracle International Corporation | Hierarchical management of the dynamic allocation of resources in a multi-node system |
US8365193B2 (en) | 2003-08-14 | 2013-01-29 | Oracle International Corporation | Recoverable asynchronous message driven processing in a multi-node system |
CN100547583C (en) | 2003-08-14 | 2009-10-07 | 甲骨文国际公司 | Database automatically and the method that dynamically provides |
US7664847B2 (en) | 2003-08-14 | 2010-02-16 | Oracle International Corporation | Managing workload by service |
US7437460B2 (en) | 2003-08-14 | 2008-10-14 | Oracle International Corporation | Service placement for enforcing performance and availability levels in a multi-node system |
US20060064400A1 (en) | 2004-09-21 | 2006-03-23 | Oracle International Corporation, A California Corporation | Methods, systems and software for identifying and managing database work |
US7552171B2 (en) | 2003-08-14 | 2009-06-23 | Oracle International Corporation | Incremental run-time session balancing in a multi-node system |
US7747717B2 (en) | 2003-08-14 | 2010-06-29 | Oracle International Corporation | Fast application notification in a clustered computing system |
US7953860B2 (en) | 2003-08-14 | 2011-05-31 | Oracle International Corporation | Fast reorganization of connections in response to an event in a clustered computing system |
US7437459B2 (en) | 2003-08-14 | 2008-10-14 | Oracle International Corporation | Calculation of service performance grades in a multi-node environment that hosts the services |
US7225209B2 (en) * | 2003-11-06 | 2007-05-29 | International Business Machines Corporation | Computer-implemented method for allocating new additional area for the dataset in storage based on the size of the new additional area wherein if the new area number does not exceed clipping threshold, the size of a new additional area being greater than the size of each previously allocated additional area of the dataset |
US8311974B2 (en) | 2004-02-20 | 2012-11-13 | Oracle International Corporation | Modularized extraction, transformation, and loading for a database |
US7941397B2 (en) * | 2004-02-25 | 2011-05-10 | International Business Machines Corporation | Dynamically capturing data warehouse population activities for analysis, archival, and mining |
US8554806B2 (en) * | 2004-05-14 | 2013-10-08 | Oracle International Corporation | Cross platform transportable tablespaces |
US7571173B2 (en) * | 2004-05-14 | 2009-08-04 | Oracle International Corporation | Cross-platform transportable database |
US7624106B1 (en) | 2004-09-29 | 2009-11-24 | Network Appliance, Inc. | Method and apparatus for generating user-level difference information about two data sets |
US9489424B2 (en) | 2004-12-20 | 2016-11-08 | Oracle International Corporation | Cursor pre-fetching |
US7779418B2 (en) | 2004-12-30 | 2010-08-17 | Oracle International Corporation | Publisher flow control and bounded guaranteed delivery for message queues |
US7818386B2 (en) | 2004-12-30 | 2010-10-19 | Oracle International Corporation | Repeatable message streams for message queues in distributed systems |
JP4143611B2 (en) * | 2005-02-04 | 2008-09-03 | インターナショナル・ビジネス・マシーンズ・コーポレーション | Backup generation device, recovery processing device, backup generation method, recovery processing method, and program |
US9176772B2 (en) | 2005-02-11 | 2015-11-03 | Oracle International Corporation | Suspending and resuming of sessions |
US7827141B2 (en) * | 2005-03-10 | 2010-11-02 | Oracle International Corporation | Dynamically sizing buffers to optimal size in network layers when supporting data transfers related to database applications |
US7562077B2 (en) * | 2005-03-28 | 2009-07-14 | Netapp, Inc. | Method and apparatus for generating and describing block-level difference information about two snapshots |
US7694088B1 (en) * | 2005-03-31 | 2010-04-06 | Symantec Operating Corporation | System and method for efficient creation of aggregate backup images |
US7610314B2 (en) * | 2005-10-07 | 2009-10-27 | Oracle International Corporation | Online tablespace recovery for export |
US7680793B2 (en) | 2005-10-07 | 2010-03-16 | Oracle International Corporation | Commit-time ordered message queue supporting arbitrary read and dequeue patterns from multiple subscribers |
US7526409B2 (en) | 2005-10-07 | 2009-04-28 | Oracle International Corporation | Automatic performance statistical comparison between two periods |
US8196150B2 (en) | 2005-10-07 | 2012-06-05 | Oracle International Corporation | Event locality using queue services |
US9361137B2 (en) * | 2006-03-10 | 2016-06-07 | International Business Machines Corporation | Managing application parameters based on parameter types |
US7739267B2 (en) * | 2006-03-10 | 2010-06-15 | International Business Machines Corporation | Classification and sequencing of mixed data flows |
US7689582B2 (en) * | 2006-03-10 | 2010-03-30 | International Business Machines Corporation | Data flow system and method for heterogeneous data integration environments |
US7689576B2 (en) * | 2006-03-10 | 2010-03-30 | International Business Machines Corporation | Dilation of sub-flow operators in a data flow |
US8620970B2 (en) * | 2006-10-03 | 2013-12-31 | Network Appliance, Inc. | Methods and apparatus for changing versions of a filesystem |
US8099725B2 (en) * | 2006-10-11 | 2012-01-17 | International Business Machines Corporation | Method and apparatus for generating code for an extract, transform, and load (ETL) data flow |
US8909599B2 (en) | 2006-11-16 | 2014-12-09 | Oracle International Corporation | Efficient migration of binary XML across databases |
US8160999B2 (en) * | 2006-12-13 | 2012-04-17 | International Business Machines Corporation | Method and apparatus for using set based structured query language (SQL) to implement extract, transform, and load (ETL) splitter operation |
US8219518B2 (en) * | 2007-01-09 | 2012-07-10 | International Business Machines Corporation | Method and apparatus for modelling data exchange in a data flow of an extract, transform, and load (ETL) process |
US8566560B2 (en) * | 2008-02-01 | 2013-10-22 | Dell Products L.P. | System and method for configuring storage resources for database storage |
US8407436B2 (en) * | 2009-02-11 | 2013-03-26 | Hitachi, Ltd. | Methods and apparatus for migrating thin provisioning volumes between storage systems |
US9165086B2 (en) | 2010-01-20 | 2015-10-20 | Oracle International Corporation | Hybrid binary XML storage model for efficient XML processing |
US8838563B2 (en) * | 2010-07-08 | 2014-09-16 | Xconnect Global Networks Limited | Method and system for routing a telephone call |
US8626778B2 (en) | 2010-07-23 | 2014-01-07 | Oracle International Corporation | System and method for conversion of JMS message data into database transactions for application to multiple heterogeneous databases |
US8510270B2 (en) | 2010-07-27 | 2013-08-13 | Oracle International Corporation | MYSQL database heterogeneous log based replication |
US9298878B2 (en) | 2010-07-29 | 2016-03-29 | Oracle International Corporation | System and method for real-time transactional data obfuscation |
US8930330B1 (en) | 2011-06-27 | 2015-01-06 | Amazon Technologies, Inc. | Validation of log formats |
US10915549B2 (en) | 2012-09-28 | 2021-02-09 | Oracle International Corporation | Techniques for keeping a copy of a pluggable database up to date with its source pluggable database in read-write mode |
US10635674B2 (en) | 2012-09-28 | 2020-04-28 | Oracle International Corporation | Migrating a pluggable database between database server instances with minimal impact to performance |
US9396220B2 (en) * | 2014-03-10 | 2016-07-19 | Oracle International Corporation | Instantaneous unplug of pluggable database from one container database and plug into another container database |
US8959420B1 (en) * | 2012-12-19 | 2015-02-17 | Datadirect Networks, Inc. | Data storage system and method for data migration between high-performance computing architectures and data storage devices using memory controller with embedded XOR capability |
US9514007B2 (en) | 2013-03-15 | 2016-12-06 | Amazon Technologies, Inc. | Database system with database engine and separate distributed storage service |
US9672237B2 (en) | 2013-03-15 | 2017-06-06 | Amazon Technologies, Inc. | System-wide checkpoint avoidance for distributed database systems |
US10180951B2 (en) | 2013-03-15 | 2019-01-15 | Amazon Technologies, Inc. | Place snapshots |
US11030055B2 (en) | 2013-03-15 | 2021-06-08 | Amazon Technologies, Inc. | Fast crash recovery for distributed database systems |
US9501501B2 (en) | 2013-03-15 | 2016-11-22 | Amazon Technologies, Inc. | Log record management |
CN104125155A (en) * | 2013-04-26 | 2014-10-29 | 上海斐讯数据通信技术有限公司 | Forwarding database optimal configuration method for switches |
US10747746B2 (en) | 2013-04-30 | 2020-08-18 | Amazon Technologies, Inc. | Efficient read replicas |
US9317213B1 (en) | 2013-05-10 | 2016-04-19 | Amazon Technologies, Inc. | Efficient storage of variably-sized data objects in a data store |
US9760596B2 (en) | 2013-05-13 | 2017-09-12 | Amazon Technologies, Inc. | Transaction ordering |
US9208032B1 (en) | 2013-05-15 | 2015-12-08 | Amazon Technologies, Inc. | Managing contingency capacity of pooled resources in multiple availability zones |
US10303564B1 (en) | 2013-05-23 | 2019-05-28 | Amazon Technologies, Inc. | Reduced transaction I/O for log-structured storage systems |
US9305056B1 (en) | 2013-05-24 | 2016-04-05 | Amazon Technologies, Inc. | Results cache invalidation |
US9047189B1 (en) | 2013-05-28 | 2015-06-02 | Amazon Technologies, Inc. | Self-describing data blocks of a minimum atomic write size for a data store |
US9830372B2 (en) | 2013-07-24 | 2017-11-28 | Oracle International Corporation | Scalable coordination aware static partitioning for database replication |
US9460008B1 (en) | 2013-09-20 | 2016-10-04 | Amazon Technologies, Inc. | Efficient garbage collection for a log-structured data store |
US9519664B1 (en) | 2013-09-20 | 2016-12-13 | Amazon Technologies, Inc. | Index structure navigation using page versions for read-only nodes |
US10216949B1 (en) | 2013-09-20 | 2019-02-26 | Amazon Technologies, Inc. | Dynamic quorum membership changes |
US9507843B1 (en) | 2013-09-20 | 2016-11-29 | Amazon Technologies, Inc. | Efficient replication of distributed storage changes for read-only nodes of a distributed database |
US9280591B1 (en) | 2013-09-20 | 2016-03-08 | Amazon Technologies, Inc. | Efficient replication of system transactions for read-only nodes of a distributed database |
US9699017B1 (en) | 2013-09-25 | 2017-07-04 | Amazon Technologies, Inc. | Dynamic utilization of bandwidth for a quorum-based distributed storage system |
US9552242B1 (en) | 2013-09-25 | 2017-01-24 | Amazon Technologies, Inc. | Log-structured distributed storage using a single log sequence number space |
US10223184B1 (en) | 2013-09-25 | 2019-03-05 | Amazon Technologies, Inc. | Individual write quorums for a log-structured distributed storage system |
US9760480B1 (en) | 2013-11-01 | 2017-09-12 | Amazon Technologies, Inc. | Enhanced logging using non-volatile system memory |
US10387399B1 (en) | 2013-11-01 | 2019-08-20 | Amazon Technologies, Inc. | Efficient database journaling using non-volatile system memory |
US9880933B1 (en) | 2013-11-20 | 2018-01-30 | Amazon Technologies, Inc. | Distributed in-memory buffer cache system using buffer cache nodes |
US9223843B1 (en) | 2013-12-02 | 2015-12-29 | Amazon Technologies, Inc. | Optimized log storage for asynchronous log updates |
US10303663B1 (en) | 2014-06-12 | 2019-05-28 | Amazon Technologies, Inc. | Remote durable logging for journaling file systems |
US9886466B2 (en) | 2015-03-24 | 2018-02-06 | International Business Machines Corporation | Optimizing space management of tablespaces in database systems |
CN105224677B (en) * | 2015-10-16 | 2018-10-30 | 上海晶赞科技发展有限公司 | A kind of database operation method and device |
US10657116B2 (en) * | 2015-10-19 | 2020-05-19 | Oracle International Corporation | Create table for exchange |
US10360269B2 (en) | 2015-10-23 | 2019-07-23 | Oracle International Corporation | Proxy databases |
WO2017070580A1 (en) | 2015-10-23 | 2017-04-27 | Oracle International Corporation | Ability to group multiple container databases as a single container database cluster |
US10572551B2 (en) | 2015-10-23 | 2020-02-25 | Oracle International Corporation | Application containers in container databases |
US10635658B2 (en) | 2015-10-23 | 2020-04-28 | Oracle International Corporation | Asynchronous shared application upgrade |
US10789131B2 (en) | 2015-10-23 | 2020-09-29 | Oracle International Corporation | Transportable backups for pluggable database relocation |
US11068437B2 (en) | 2015-10-23 | 2021-07-20 | Oracle Interntional Corporation | Periodic snapshots of a pluggable database in a container database |
US10606578B2 (en) | 2015-10-23 | 2020-03-31 | Oracle International Corporation | Provisioning of pluggable databases using a central repository |
EP3365807B1 (en) | 2015-10-23 | 2019-08-07 | Oracle International Corporation | Application containers for container databases |
US10579478B2 (en) | 2015-10-23 | 2020-03-03 | Oracle International Corporation | Pluggable database archive |
US10289617B2 (en) | 2015-12-17 | 2019-05-14 | Oracle International Corporation | Accessing on-premise and off-premise datastores that are organized using different application schemas |
US10387387B2 (en) | 2015-12-17 | 2019-08-20 | Oracle International Corporation | Enabling multi-tenant access to respective isolated data sets organized using different application schemas |
US10540217B2 (en) | 2016-09-16 | 2020-01-21 | Oracle International Corporation | Message cache sizing |
US10474653B2 (en) | 2016-09-30 | 2019-11-12 | Oracle International Corporation | Flexible in-memory column store placement |
CN107402850B (en) * | 2017-07-31 | 2021-02-09 | 苏州浪潮智能科技有限公司 | Redundancy method and device for database data files |
US12007941B2 (en) | 2017-09-29 | 2024-06-11 | Oracle International Corporation | Session state tracking |
US11386058B2 (en) | 2017-09-29 | 2022-07-12 | Oracle International Corporation | Rule-based autonomous database cloud service framework |
US11914571B1 (en) | 2017-11-22 | 2024-02-27 | Amazon Technologies, Inc. | Optimistic concurrency for a multi-writer database |
US11645261B2 (en) | 2018-04-27 | 2023-05-09 | Oracle International Corporation | System and method for heterogeneous database replication from a remote server |
US11936739B2 (en) | 2019-09-12 | 2024-03-19 | Oracle International Corporation | Automated reset of session state |
US11341163B1 (en) | 2020-03-30 | 2022-05-24 | Amazon Technologies, Inc. | Multi-level replication filtering for a distributed database |
US12008014B2 (en) | 2021-07-30 | 2024-06-11 | Oracle International Corporation | Data guard at PDB (pluggable database) level |
CN114443654B (en) * | 2022-01-14 | 2024-01-26 | 苏州浪潮智能科技有限公司 | Method and system for on-line modifying length of database table space data block |
Citations (26)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US4841433A (en) * | 1986-11-26 | 1989-06-20 | American Telephone And Telegraph Company, At&T Bell Laboratories | Method and apparatus for accessing data from data attribute tables |
US5222235A (en) * | 1990-02-01 | 1993-06-22 | Bmc Software, Inc. | Databases system for permitting concurrent indexing and reloading of data by early simulating the reload process to determine final locations of the data |
US5438509A (en) * | 1991-02-07 | 1995-08-01 | Heffron; Donald J. | Transaction processing in a distributed data processing system |
US5678043A (en) * | 1994-09-23 | 1997-10-14 | The Regents Of The University Of Michigan | Data compression and encryption system and method representing records as differences between sorted domain ordinals that represent field values |
US5862325A (en) * | 1996-02-29 | 1999-01-19 | Intermind Corporation | Computer-based communication system and method using metadata defining a control structure |
US5864853A (en) * | 1994-09-14 | 1999-01-26 | Kabushiki Kaisha Toshiba | Portable file system operable under various computer environments |
US5873088A (en) * | 1990-08-31 | 1999-02-16 | Fujitsu Limited | Derived data base processing system enabling one program to access a plurality of data basis |
US5899997A (en) * | 1996-04-03 | 1999-05-04 | Transparency Systems, Inc. | Object-oriented query mechanism |
US5937415A (en) * | 1995-12-13 | 1999-08-10 | Sybase, Inc. | Data base development system with methods facilitating copying of data from one data source to another |
US5944818A (en) * | 1996-06-28 | 1999-08-31 | Intel Corporation | Method and apparatus for accelerated instruction restart in a microprocessor |
US5970488A (en) * | 1997-05-05 | 1999-10-19 | Northrop Grumman Corporation | Real-time distributed database system and method |
US6070160A (en) * | 1995-05-19 | 2000-05-30 | Artnet Worldwide Corporation | Non-linear database set searching apparatus and method |
US6397223B1 (en) * | 1999-07-08 | 2002-05-28 | Mitsubishi Denki Kabushiki Kaisha | File management method using transposed file |
US20020138316A1 (en) * | 2001-03-23 | 2002-09-26 | Katz Steven Bruce | Value chain intelligence system and methods |
US20030115439A1 (en) * | 2001-12-19 | 2003-06-19 | Hewlett Packard Company | Updating references to a migrated object in a partition-based distributed file system |
US20040068509A1 (en) * | 2001-01-19 | 2004-04-08 | Garden Peter William | Data transfer and/or transformation system and method |
US20040068696A1 (en) * | 2001-02-05 | 2004-04-08 | Claude Seyrat | Method and system for compressing structured descriptions of documents |
US20040143791A1 (en) * | 2003-01-17 | 2004-07-22 | Yuichi Ito | Converting XML code to binary format |
US20040153459A1 (en) * | 2003-01-21 | 2004-08-05 | Gary Whitten | System and method for transferring a database from one location to another over a network |
US20040268305A1 (en) * | 2003-06-26 | 2004-12-30 | Microsoft Corporation | Extensible metadata |
US20050278289A1 (en) * | 2004-06-14 | 2005-12-15 | Thomas Gauweiler | Binary XML |
US20050278616A1 (en) * | 2004-06-09 | 2005-12-15 | Eller Bill J | Extensible binary mark-up language for efficient XML-based data communications and related systems and methods |
US20060168513A1 (en) * | 2005-01-25 | 2006-07-27 | Microsoft Corporation | Method and system for binary serialization of documents |
US20070044012A1 (en) * | 2005-08-19 | 2007-02-22 | Microsoft Corporation | Encoding of markup language data |
US20070129953A1 (en) * | 2002-10-09 | 2007-06-07 | Business Objects Americas | Methods and systems for information strategy management |
US20080077606A1 (en) * | 2006-09-26 | 2008-03-27 | Motorola, Inc. | Method and apparatus for facilitating efficient processing of extensible markup language documents |
Family Cites Families (18)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CA2055295C (en) * | 1991-11-12 | 2000-05-23 | Jean Gilles Fecteau | Logical mapping of data objects using data spaces |
US5555403A (en) * | 1991-11-27 | 1996-09-10 | Business Objects, S.A. | Relational database access system using semantically dynamic objects |
JP3490742B2 (en) * | 1993-09-08 | 2004-01-26 | 松下電器産業株式会社 | Memory management device |
US5491810A (en) * | 1994-03-01 | 1996-02-13 | International Business Machines Corporation | Method and system for automated data storage system space allocation utilizing prioritized data set parameters |
US5497486A (en) * | 1994-03-15 | 1996-03-05 | Salvatore J. Stolfo | Method of merging large databases in parallel |
US5822749A (en) * | 1994-07-12 | 1998-10-13 | Sybase, Inc. | Database system with methods for improving query performance with cache optimization strategies |
US5870746A (en) * | 1995-10-12 | 1999-02-09 | Ncr Corporation | System and method for segmenting a database based upon data attributes |
US6035298A (en) * | 1995-10-19 | 2000-03-07 | British Telecommunications Public Limited Company | Accessing plural independent databases having plural database schemas |
US5758345A (en) * | 1995-11-08 | 1998-05-26 | International Business Machines Corporation | Program and method for establishing a physical database layout on a distributed processor system |
US5852715A (en) * | 1996-03-19 | 1998-12-22 | Emc Corporation | System for currently updating database by one host and reading the database by different host for the purpose of implementing decision support functions |
US5970502A (en) * | 1996-04-23 | 1999-10-19 | Nortel Networks Corporation | Method and apparatus for synchronizing multiple copies of a database |
US6101497A (en) * | 1996-05-31 | 2000-08-08 | Emc Corporation | Method and apparatus for independent and simultaneous access to a common data set |
US5832525A (en) * | 1996-06-24 | 1998-11-03 | Sun Microsystems, Inc. | Disk fragmentation reduction using file allocation tables |
US5819298A (en) * | 1996-06-24 | 1998-10-06 | Sun Microsystems, Inc. | File allocation tables with holes |
US5832509A (en) * | 1996-12-17 | 1998-11-03 | Chrysler Corporation | Apparatus and method for adjusting data sizes in database operations |
US6032158A (en) * | 1997-05-02 | 2000-02-29 | Informatica Corporation | Apparatus and method for capturing and propagating changes from an operational database to data marts |
US5890167A (en) * | 1997-05-08 | 1999-03-30 | Oracle Corporation | Pluggable tablespaces for database systems |
US5943668A (en) * | 1997-06-30 | 1999-08-24 | International Business Machines Corporation | Relational emulation of a multi-dimensional database |
-
2001
- 2001-05-30 US US09/871,476 patent/US7031987B2/en not_active Expired - Lifetime
-
2002
- 2002-05-29 CN CNB028110331A patent/CN1264107C/en not_active Expired - Lifetime
- 2002-05-29 EP EP02731964A patent/EP1393208A2/en not_active Withdrawn
- 2002-05-29 WO PCT/US2002/016885 patent/WO2002097676A2/en active Application Filing
- 2002-05-29 JP JP2003500786A patent/JP2004530216A/en active Pending
- 2002-05-29 CA CA002455348A patent/CA2455348A1/en not_active Abandoned
-
2006
- 2006-02-02 US US11/347,644 patent/US20060143187A1/en not_active Abandoned
Patent Citations (26)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US4841433A (en) * | 1986-11-26 | 1989-06-20 | American Telephone And Telegraph Company, At&T Bell Laboratories | Method and apparatus for accessing data from data attribute tables |
US5222235A (en) * | 1990-02-01 | 1993-06-22 | Bmc Software, Inc. | Databases system for permitting concurrent indexing and reloading of data by early simulating the reload process to determine final locations of the data |
US5873088A (en) * | 1990-08-31 | 1999-02-16 | Fujitsu Limited | Derived data base processing system enabling one program to access a plurality of data basis |
US5438509A (en) * | 1991-02-07 | 1995-08-01 | Heffron; Donald J. | Transaction processing in a distributed data processing system |
US5864853A (en) * | 1994-09-14 | 1999-01-26 | Kabushiki Kaisha Toshiba | Portable file system operable under various computer environments |
US5678043A (en) * | 1994-09-23 | 1997-10-14 | The Regents Of The University Of Michigan | Data compression and encryption system and method representing records as differences between sorted domain ordinals that represent field values |
US6070160A (en) * | 1995-05-19 | 2000-05-30 | Artnet Worldwide Corporation | Non-linear database set searching apparatus and method |
US5937415A (en) * | 1995-12-13 | 1999-08-10 | Sybase, Inc. | Data base development system with methods facilitating copying of data from one data source to another |
US5862325A (en) * | 1996-02-29 | 1999-01-19 | Intermind Corporation | Computer-based communication system and method using metadata defining a control structure |
US5899997A (en) * | 1996-04-03 | 1999-05-04 | Transparency Systems, Inc. | Object-oriented query mechanism |
US5944818A (en) * | 1996-06-28 | 1999-08-31 | Intel Corporation | Method and apparatus for accelerated instruction restart in a microprocessor |
US5970488A (en) * | 1997-05-05 | 1999-10-19 | Northrop Grumman Corporation | Real-time distributed database system and method |
US6397223B1 (en) * | 1999-07-08 | 2002-05-28 | Mitsubishi Denki Kabushiki Kaisha | File management method using transposed file |
US20040068509A1 (en) * | 2001-01-19 | 2004-04-08 | Garden Peter William | Data transfer and/or transformation system and method |
US20040068696A1 (en) * | 2001-02-05 | 2004-04-08 | Claude Seyrat | Method and system for compressing structured descriptions of documents |
US20020138316A1 (en) * | 2001-03-23 | 2002-09-26 | Katz Steven Bruce | Value chain intelligence system and methods |
US20030115439A1 (en) * | 2001-12-19 | 2003-06-19 | Hewlett Packard Company | Updating references to a migrated object in a partition-based distributed file system |
US20070129953A1 (en) * | 2002-10-09 | 2007-06-07 | Business Objects Americas | Methods and systems for information strategy management |
US20040143791A1 (en) * | 2003-01-17 | 2004-07-22 | Yuichi Ito | Converting XML code to binary format |
US20040153459A1 (en) * | 2003-01-21 | 2004-08-05 | Gary Whitten | System and method for transferring a database from one location to another over a network |
US20040268305A1 (en) * | 2003-06-26 | 2004-12-30 | Microsoft Corporation | Extensible metadata |
US20050278616A1 (en) * | 2004-06-09 | 2005-12-15 | Eller Bill J | Extensible binary mark-up language for efficient XML-based data communications and related systems and methods |
US20050278289A1 (en) * | 2004-06-14 | 2005-12-15 | Thomas Gauweiler | Binary XML |
US20060168513A1 (en) * | 2005-01-25 | 2006-07-27 | Microsoft Corporation | Method and system for binary serialization of documents |
US20070044012A1 (en) * | 2005-08-19 | 2007-02-22 | Microsoft Corporation | Encoding of markup language data |
US20080077606A1 (en) * | 2006-09-26 | 2008-03-27 | Motorola, Inc. | Method and apparatus for facilitating efficient processing of extensible markup language documents |
Cited By (11)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US8782101B1 (en) * | 2012-01-20 | 2014-07-15 | Google Inc. | Transferring data across different database platforms |
US9268798B2 (en) | 2013-04-26 | 2016-02-23 | Oracle International Corporation | Support for cloud-based multi-tenant environments using connection labeling |
US20140380004A1 (en) * | 2013-06-06 | 2014-12-25 | Oracle International Corporation | Efficient storage and retrieval of fragmented data using pseudo linear dynamic byte array |
US9569472B2 (en) | 2013-06-06 | 2017-02-14 | Oracle International Corporation | System and method for providing a second level connection cache for use with a database environment |
US9600546B2 (en) | 2013-06-06 | 2017-03-21 | Oracle International Corporation | System and method for marshaling massive database data from native layer to java using linear array |
US9720970B2 (en) * | 2013-06-06 | 2017-08-01 | Oracle International Corporation | Efficient storage and retrieval of fragmented data using pseudo linear dynamic byte array |
US9747341B2 (en) | 2013-06-06 | 2017-08-29 | Oracle International Corporation | System and method for providing a shareable global cache for use with a database environment |
US9785687B2 (en) | 2013-06-06 | 2017-10-10 | Oracle International Corporation | System and method for transparent multi key-value weighted attributed connection using uni-tag connection pools |
US20150193155A1 (en) * | 2014-01-07 | 2015-07-09 | Apple Inc. | Speculative prefetching of data stored in flash memory |
US9582204B2 (en) * | 2014-01-07 | 2017-02-28 | Apple Inc. | Speculative prefetching of data stored in flash memory |
CN104881418A (en) * | 2014-02-28 | 2015-09-02 | 阿里巴巴集团控股有限公司 | Method and device for quickly reclaiming rollback space in MySQL |
Also Published As
Publication number | Publication date |
---|---|
WO2002097676A3 (en) | 2003-12-18 |
CN1526107A (en) | 2004-09-01 |
US20020143733A1 (en) | 2002-10-03 |
WO2002097676A2 (en) | 2002-12-05 |
JP2004530216A (en) | 2004-09-30 |
CN1264107C (en) | 2006-07-12 |
US7031987B2 (en) | 2006-04-18 |
EP1393208A2 (en) | 2004-03-03 |
CA2455348A1 (en) | 2002-12-05 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US7031987B2 (en) | Integrating tablespaces with different block sizes | |
US6804671B1 (en) | Pluggable tablespaces for database systems | |
US7571173B2 (en) | Cross-platform transportable database | |
US6243718B1 (en) | Building indexes on columns containing large objects | |
US6134543A (en) | Incremental maintenance of materialized views containing one-to-one lossless joins | |
US6321234B1 (en) | Database server system with improved methods for logging transactions | |
US6134558A (en) | References that indicate where global database objects reside | |
US6738790B1 (en) | Approach for accessing large objects | |
US5999943A (en) | Lob locators | |
US6125360A (en) | Incremental maintenance of materialized views containing one-to-N lossless joins | |
US6457021B1 (en) | In-memory database system | |
US6820095B1 (en) | Import/export and repartitioning of partitioned objects | |
AU764720B2 (en) | Method and system for fast memory-resident processing of transaction data | |
US8433684B2 (en) | Managing data backup of an in-memory database in a database management system | |
US7533136B2 (en) | Efficient implementation of multiple work areas in a file system like repository that supports file versioning | |
US7293040B2 (en) | System and methodology for database migration between platforms | |
US5995973A (en) | Storing relationship tables identifying object relationships | |
US20120323971A1 (en) | Optimizing data storage and access of an in-memory database | |
US7418544B2 (en) | Method and system for log structured relational database objects | |
US6549901B1 (en) | Using transportable tablespaces for hosting data of multiple users | |
US8554806B2 (en) | Cross platform transportable tablespaces | |
US20050278346A1 (en) | System Providing Methodology for Replication Subscription Resolution | |
US6366902B1 (en) | Using an epoch number to optimize access with rowid columns and direct row access | |
US20120066263A1 (en) | Incremental data transfer in a database management system | |
US20010018684A1 (en) | System and method for accessing non-relational data by relational access methods |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
STCB | Information on status: application discontinuation |
Free format text: EXPRESSLY ABANDONED -- DURING EXAMINATION |