| Patent application number | Description | Published |
|---|
| 20080243865 | Maintaining global state of distributed transaction managed by an external transaction manager for clustered database systems - In accordance with an embodiment of the present invention, a transaction tracking mechanism is provided by a database server cluster to keep track of a global state of a distributed transaction. The global state of the distributed transaction comprises one or more statuses that are associated with one or more transaction branches that are part of the distributed transaction. The global state may be associated with a global lock. Through using the global state in association with the global lock, problems such as partial commits, data inconsistency, access contentions and deadlocks may be avoided when the database server cluster processes the distributed transaction. | 10-02-2008 |
| 20080281846 | High performant row-level data manipulation using a data layer interface - Performing an operation directly on data stored in a database table provides for avoiding generation and processing of SQL statements. A Data Layer interface, comprising a set of APIs, allows internal database server components to call directly to the Data Layer for making fast row changes to a table. According to an embodiment, before making any row change to a table through this Data Layer interface, a shared state data structure is created to hold the metadata about the table. A single shared state can be used for all DML changes to a particular table regardless of what columns are updated or inserted during each DML operation. When a process needs to change a row, the process uses a mutable state based on the shared state of the table. | 11-13-2008 |
| 20090024578 | Delta Operations On A Large Object In A Database - A computer modifies data inside a database large object (LOB) of unknown structure without modifying other data in the remainder of the LOB. Insertion of new data at a specified location in the LOB does not require movement of existing data in the LOB. Instead, the computer is programmed to insert new data at a physical end of the LOB, and modify metadata based on the specified location. Similarly, deletion of existing data from a specified location in the LOB is performed without movement of other data in the LOB, by updating the metadata. The computer uses the metadata when reading from the LOB, so that the new data is automatically read whenever the specified location is accessed. The computer may optionally output a handle that is static, relative to other insertions and deletions, to identify specific data within the LOB, for use in building indexes on the LOB. | 01-22-2009 |
| 20090030956 | Proactive space allocation in a database system - A method and apparatus for proactively allocating space to a logical layer of a database is provided. Allocation of space to a logical layer of a database is an expensive operation that should be minimized. The allocation of space includes discovering free space in all the higher layers in the logical storage hierarchy. It also includes cross-domain system calls and cleansing disk-write operations. In prior approaches, the allocation processes were triggered on-demand, only a certain logical layer was discovered to be at full capacity when an insert-row operation was attempted. In one embodiment of the invention, space needs are statistically predicted based on prior rates of space consumption. The database server pre-allocates space as needed, based on the statistical predictions. Rates of consumption are examined periodically. Space is pre-allocated before any logical layer reaches full capacity by a combination of proactive background processes; foreground-triggered, background processes; and classic foreground allocation. | 01-29-2009 |
| 20090037366 | ONLINE INDEX BUILDS AND REBUILDS WITHOUT BLOCKING LOCKS - Techniques are provided for processing a CREATE INDEX statement that avoids one or more locks on the underlying table. The processing of such a statement may be divided into a build phase and a cooperation phase. During the build phase, a journal table is created and published. A snapshot of the table is obtained after the last DML transaction (that was pending at the time the journal table was published) commits. The index is built based on the state of the table as of the snapshot. Any changes to the table while the index is built are recorded in the journal table. During the cooperation phase, the index is partially published. A subsequent DML statement determines whether any changes in the journal table affect the same data as the subsequent DML statement. If so, then those changes are applied to the index followed by the subsequent DML statement. | 02-05-2009 |
| 20090037498 | IN-MEMORY SPACE MANAGEMENT FOR DATABASE SYSTEMS - A framework for in-memory space management for content management database systems is provided. A per-instance in-memory dispenser is partitioned. An incoming transaction takes a latch on a partition and obtains sufficient block usage to perform and complete the transaction. Generating redo information is decoupled from transaction level processing and, instead, is performed when block requests are loaded into the in-memory dispenser or synced therefrom to a per-instance on-disk structure. | 02-05-2009 |
| 20090037499 | METHOD AND MECHANISM FOR IMPLEMENTING DYNAMIC SPACE MANAGEMENT FOR LARGE OBJECTS - Disclosed is a system and method for implementing space management for large objects stored in the computing system. According to some approaches, storage of large objects are managed by dynamically creating contiguous chunks of storage space of varying lengths. The length of each chunk may vary depending upon object size being stored, fragmentation of the storage space, available free space, and/or expected length of the object. | 02-05-2009 |
| 20090106281 | ON-LINE TRANSACTION PROCESSING (OLTP) COMPRESSION AND RE-COMPRESSION OF DATABASE DATA - A computer is programmed to compress data of a database in response to database modification language (DML) statements generated by on-line transaction processing (OLTP) systems. In several embodiments, data that is initially added to a database block is left uncompressed until a predetermined condition is satisfied, which happens infrequently (relative to OLTP transactions on the block). When satisfied, the computer automatically compresses all uncompressed data in the block, which increases the amount of unused space in the block. New data is thereafter added uncompressed to the partially compressed block, until satisfaction of a predetermined condition whereby the partially compressed block is again compressed, i.e. re-compressed. Adding of new data to a partially compressed block and its compression are repeated unless another predetermined condition is met, in response to which the block is not further re-compressed, thereby to recognize a limit on the benefit from compression. | 04-23-2009 |
| 20090164525 | Online Recovery of User Tables Using Flashback Table - A method and apparatus for updating databases are disclosed. In response to a flashback request, a database object is restored to a state as of a specified flashback time. The changes introduced into the database object are reversed in a sequence starting with a change introduced into the database object immediately before issuance of the flashback request and ending with a change introduced into the database object immediately after the specified flashback time. | 06-25-2009 |
| 20090292679 | CASCADING INDEX COMPRESSION - Techniques for compressing branch nodes in an index are provided. The branch nodes may be part of a main index of a multi-level index that also includes one or more journal indexes. A Bloom filter may be generated and associated with, e.g., a branch node in the main index. The Bloom filter is used to determine whether, without accessing any leaf blocks, a particular key value exists, e.g., in leaf blocks associated with the branch node. | 11-26-2009 |
| 20090292947 | CASCADING INDEX COMPRESSION - Techniques for maintaining a cascading index are provided. In one approach, one or more branch node compression techniques are applied to the main index of a cascading index. In an approach, a Bloom filter is generated and associated with, e.g., a branch node in the main index. The Bloom filter is used to determine whether, without accessing any leaf blocks, a particular key value exists, e.g., in leaf blocks associated with the branch node. In an approach, a new redo record is generated in response to a merge operation between two levels of the cascading index. The new redo record comprises (a) one or more addresses of blocks that are affected by the merge operation, (b) data is that being “pushed down” to a lower level of the cascading index, and (c) one or more addresses of blocks that are written to disk storage as a result of the merge operation. | 11-26-2009 |
| 20100030781 | METHOD AND APPARATUS FOR AUTOMATICALLY CLASSIFYING DATA - One embodiment of the present invention provides a system for automatically classifying data in a database. During operation, the system receives and executes a database operation. Next, the system automatically determines if any data was modified as a result of executing the database operation. If so, for each data item that was modified, the system automatically determines if the data item is associated with a classification-rule. If so, the system automatically reclassifies the data item according to the classification-rule. If not, the system leaves a classification of the data item unchanged. | 02-04-2010 |
| 20100036803 | ADAPTIVE FILTER INDEX FOR DETERMINING QUERIES AFFECTED BY A DML OPERATION - Techniques are disclosed for creating and using a filter index in order to identify registered queries whose result sets are likely to have been changed by changes made to tables. The filter index entries are based on filter conditions. The filter conditions are created based on predicates contained in the registered queries. The filter conditions may include exclusive predicates and join predicates. Join predicates that join a table T | 02-11-2010 |
| 20100036831 | GENERATING CONTINUOUS QUERY NOTIFICATIONS - Techniques are described to allow a query to be registered as a persistent stored entity within the database, and to generate notifications as and when the query result changes continuously as long as the query continues to be registered with the database. According to one aspect, for a table referenced in a query, a filter condition is generated based, at least in part, on a predicate of the query. Then, the database server determines whether the filter condition is satisfied by either a before image of a row, or an after image of the row, that was modified by a transaction. If the filter condition is satisfied by either the before image or the after image, then the query is added to a first set of queries whose result sets may have been affected by the transaction. From among the first set of queries, a second set of queries that have result sets that were actually affected by the transaction is determined. Notifications are then sent based on the second set of queries. | 02-11-2010 |
| 20100278446 | STRUCTURE OF HIERARCHICAL COMPRESSED DATA STRUCTURE FOR TABULAR DATA - A highly flexible and extensible structure is provided for physically storing tabular data. The structure, is referred to as a compression unit, and may be used to physically store tabular data that logically resides in any type of table-like structure. According to one embodiment, compression units are recursive. Thus, a compression unit may have a “parent” compression unit to which it belongs, and may have one or more “child” compression units that belong to it. In one embodiment, compression units include metadata that indicates how the tabular data is stored within them. The metadata for a compression unit may indicate, for example, whether the data within the compression unit is stored in row-major or column major-format (or some combination thereof), the order of the columns within the compression unit (which may differ from the logical order of the columns dictated by the definition of their logical container), a compression technique for the compression unit, the child compression units (if any), etc. | 11-04-2010 |
| 20100281004 | STORING COMPRESSION UNITS IN RELATIONAL TABLES - A database server stores compressed units in data blocks of a database. A table (or data from a plurality of rows thereof) is first compressed into a “compression unit” using any of a wide variety of compression techniques. The compression unit is then stored in one or more data block rows across one or more data blocks. As a result, a single data block row may comprise compressed data for a plurality of table rows, as encoded within the compression unit. Storage of compression units in data blocks maintains compatibility with existing data block-based databases, thus allowing the use of compression units in preexisting databases without modification to the underlying format of the database. The compression units may, for example, co-exist with uncompressed tables. Various techniques allow a database server to optimize access to data in the compression unit, so that the compression is virtually transparent to the user. | 11-04-2010 |
| 20100281079 | COMPRESSION ANALYZER - Techniques are described herein for automatically selecting the compression techniques to be used on tabular data. A compression analyzer gives users high-level control over the selection process without requiring the user to know details about the specific compression techniques that are available to the compression analyzer. Users are able to specify, for a given set of data, a “balance point” along the spectrum between “maximum performance” and “maximum compression”. The point thus selected is used by the compression analyzer in a variety of ways. For example, in one embodiment, the compression analyzer uses the user-specified balance point to determine which of the available compression techniques qualify as “candidate techniques” for the given set of data. The compression analyzer selects the compression technique to use on a set of data by actually testing the candidate compression techniques against samples from the set of data. After testing the candidate compression techniques against the samples, the resulting compression ratios are compared. The compression technique to use on the set of data is then selected based, in part, on the compression ratios achieved during the compression tests performed on the sample data. | 11-04-2010 |
| 20110029569 | DDL AND DML SUPPORT FOR HYBRID COLUMNAR COMPRESSED TABLES - Techniques for storing and manipulating tabular data are provided. According to one embodiment, a user may control whether tabular data is stored in row-level or column-major format. Furthermore, the user may control the level of data compression to achieve an optimal balance between query performance and compression ratios. Tabular data from within the same table may be stored in both column-major and row-major format and compressed at different levels. In addition, tabular data can migrate between column-major format and row-major format in response to various events. For example, in response to a request to update or lock a row stored in column-major format, the row may be migrated and subsequently stored into row-major format. In one embodiment, table partitions are used to enhance data compression techniques. For example, compression tests are performed on a representative table partition, and a compression map is generated and applied to other table partitions. | 02-03-2011 |
