Patent application number | Description | Published |
20080270609 | COMPUTER-READABLE MEDIUM TO MULTIPLEX MULTIPLE APPLICATION SERVER REQUESTS OVER A SINGLE DATABASE CONNECTION - In a system for avoiding section collision for application server requests over a single database connection, the database server assigns query identifiers to each instance of the same cursor opened for the same processing level within an application, allowing multiple instances of the same cursor to be processed in parallel without section collision. The application server assigns a command source identifier to each statement sent over a single database connection to uniquely identify the application source of the statement. This applies for multiples of the same statement sent by different application sources within the same application, for a single statement containing multiple application sources, and for multiple statements from different applications multiplexed over a single database connection. These statements can be processed separately from and in parallel with the each other without section collision. | 10-30-2008 |
20080271114 | SYSTEM FOR PROVIDING AND UTILIZING A NETWORK TRUSTED CONTEXT - A system for establishing a connection between a data server and a middleware server is disclosed. The system includes defining a plurality of trust attributes corresponding to a trusted context between the middleware server and the data server and validating the plurality of trust attributes against a plurality of attributes corresponding to the middleware server. The plurality of attributes provided in a connection request. The system also includes establishing the trusted context based on the validating the plurality of trust attributes. | 10-30-2008 |
20090070304 | LOW-OVERHEAD BUILT-IN TIMESTAMP COLUMN FOR RELATIONAL DATABASE SYSTEMS - An improved automatically updated timestamp for database systems is disclosed. The automatically updated timestamp can be provided in a hidden timestamp column for a table, where the value of the timestamp column can be retrieved with a query that calls the column by name. Optionally, the timestamp column can be provided for each table in the database system to ensure its availability to applications. For cases where a timestamp for each row in a table is not desired, an automatically updated timestamp can be provided for a data page. This timestamp can be retrieved from an update timestamp recorded on disk and in the buffer pool or from a log relative byte address. Although this is a page-level timestamp, its use may be desirable for infrequently updated tables or where space on the disk and buffer pool is at a premium. | 03-12-2009 |
20100082630 | PERSISTING EXTERNAL INDEX DATA IN A DATABASE - Systems, methods, and computer program products to persist external index data in a database are disclosed. In an embodiment, a method includes maintaining a database including a first data table that is configured to store data in a database format and a second data table that is configured to store index data. The index data represents an index of a first portion of the first data table, and the index maintained externally to the database by an index manager. The method also includes generating a data update representing a modification to the first data table and communicating the data update to the index manager. The method further includes receiving index update data from the index manager representing a modification to the index as a result of the data update and applying the index update data to the second data table. | 04-01-2010 |
20110295909 | TECHNIQUE TO INTRODUCE ADVANCED FUNCTIONAL BEHAVIORS IN A DATABASE MANAGEMENT SYSTEM WITHOUT INTRODUCING NEW DATA TYPES - A row property provides a mechanism for implementing advanced functional behavior in a relational database management system (RDBMS) without introducing new data types. A row property is part of a table definition, such that, when a table is defined in the RDBMS, at least one row property is specified for one or more associated columns of rows of the table, wherein the row property has an associated functional behavior that is predefined within the RDBMS. The columns associated with the row property are generally of existing data types supported by an RDBMS. A row property may be invoked when the RDBMS processes a language statement that references the row property. When the row property is invoked, the RDBMS executes programming logic associated with the row property, in order to perform the advanced functional behavior using data stored in the associated columns. | 12-01-2011 |
20120197919 | Masking Sensitive Data of Table Columns Retrieved From a Database - Access to a data element stored within a database object is controlled. A request is received from a user to perform an operation in relation to the database object, the operation including retrieval of information from the data element of the database object. Prior to retrieving information from the data element, a determination is made whether at least a portion of the information from the data element is subject to masking in accordance with an access policy. In response to determining that information from the data element is subject to masking, the request is modified to require that information from the data element be retrieved in a masked condition. | 08-02-2012 |
20120233148 | MANAGING MATERIALIZED QUERY TABLES (MQTS) OVER FINE-GRAINED ACCESS CONTROL (FGAC) PROTECTED TABLES - Provided are techniques for creating one or more fine-grained access control rules that are associated with a base table. A materialized query table is created from the base table without applying the one or more fine-grained access control rules associated with the base table when obtaining data from the base table. A fine-grained access control protection indicator is turned on for the materialized query table. In response to receiving a direct access request to the materialized query table in a query referencing the materialized query table, access is provided to the data in the materialized query table by applying one or more fine-grained access control rules associated directly with the materialized query table to the data in the materialized query table before returning the data. | 09-13-2012 |
20120259824 | MAINTAINING INDEX DATA IN A DATABASE - In a particular embodiment, a method includes storing, at a staging table of a database, a data update generated based on a transaction performed with respect to a data table that is associated with one or more indexes. Each index of the one or more indexes is maintained externally to the database. The method further includes maintaining the data update at the staging table at least until index update data is received at the database. The index update data represents a modification, based on the data update, to a particular index of the one or more the indexes. | 10-11-2012 |
20130086088 | Query Transformation for Masking Data Within Database Objects - According to one embodiment of the present invention, a system processes a database query, and comprises a computer system including at least one processor. The system identifies one or more expressions within the database query utilizing a database object with value masking. Masking requirements are determined for each identified expression and the database object utilized by that identified expression is replicated to provide masked and actual versions of that database object in response to the masking requirements for that expression including masked values and actual values of that database object. The value masking of the database object is applied to the identified expressions within the database query based on the determined masking requirements to produce search results with masked values for the database query. Embodiments of the present invention further include a method and computer program product for processing a database query in substantially the same manner described above. | 04-04-2013 |
20130262435 | ADAPTIVE QUERY EXECUTION PLAN ENHANCEMENT - An adaptive query execution plan enhancement is provided by: selecting a sample of literal sets from an execution history of a query statement; determining a plurality of access paths by applying each literal set in the sample to the query statement; for each given access path of the plurality of access paths, determining a total execution cost by applying each literal set in the sample to the given access path; and selecting a preferred access path from the plurality of access paths based on the total execution costs for each given access path. A plurality of preferred access paths for a plurality of query statements in an application workload is collected and may be presented as a query execution plan enhancement recommendation to users. | 10-03-2013 |
20130325826 | MATCHING TRANSACTIONS IN MULTI-LEVEL RECORDS - A method for identifying matching transactions between two log files where each transaction includes one or more statements. Each log file record records the execution of a statement and includes a transaction identifier. Each record in turn in one log file is compared to an advancing window of records in the other log file. A first table contains associations of statements to transactions and transactions to statements for records in the window. If a match is found between a record in the one file and a record in the window, information associating partial transactions in the one file to potential transactions of the records in the window is added to a second table. If an end-of-transaction record is read from the one file, a best match is found between the ended transaction and the potential transactions based on information in the first and second tables. | 12-05-2013 |
20130325829 | MATCHING TRANSACTIONS IN MULTI-LEVEL RECORDS - A method for identifying matching transactions between two log files where each transaction includes one or more statements. Each log file record records the execution of a statement and includes a transaction identifier. Each record in turn in one log file is compared to an advancing window of records in the other log file. A first table contains associations of statements to transactions and transactions to statements for records in the window. If a match is found between a record in the one file and a record in the window, information associating partial transactions in the one file to potential transactions of the records in the window is added to a second table. If an end-of-transaction record is read from the one file, a best match is found between the ended transaction and the potential transactions based on information in the first and second tables. | 12-05-2013 |
20130339964 | REPLAYING OF WORK ACROSS CLUSTER OF DATABASE SERVERS - The replaying of work across a database servers includes: receiving a global time by each of a plurality of replay dispatchers; calculating, for each given replay dispatcher, a time offset using a local time for the given replay dispatcher and the global time; receiving, for each given replay dispatcher, a replay workload comprising a plurality of replay records and a global replay start time, wherein each of the plurality of replay records comprises an expected wait time; calculating, for each given replay dispatcher, a wait time for each given replay record based on the expected wait time for the given replay record, the global replay start time, and the time offset for the given replay dispatcher; and submitting, for each given replay dispatcher, the replay records to a target database server for processing in an order according to the calculated wait times. | 12-19-2013 |
20140188783 | SAMPLING TRANSACTIONS FROM MULTI-LEVEL LOG FILE RECORDS - A log file contains operation records, each operation record is of a certain type, and each operation record is associated with a transaction. A plurality of operation records is read from the log file into a record store. Records of the plurality of operation records of each operation record type are sampled at a predefined sampling rate. Operation records in the plurality of operations records are identified that are associated with completed transactions of which the sampled operation records are associated. The identified operation records are then extracted from the record store into a data store. | 07-03-2014 |
20140195505 | SAMPLING TRANSACTIONS FROM MULTI-LEVEL LOG FILE RECORDS - A log file contains operation records, each operation record is of a certain type, and each operation record is associated with a transaction. A plurality of operation records is read from the log file into a record store. Records of the plurality of operation records of each operation record type are sampled at a predefined sampling rate. Operation records in the plurality of operations records are identified that are associated with completed transactions of which the sampled operation records are associated. The identified operation records are then extracted from the record store into a data store. | 07-10-2014 |
20140236976 | MATCH WINDOW SIZE FOR MATCHING MULTI-LEVEL TRANSACTIONS BETWEEN LOG FILES - A predefined number of matches is identified between records in a first file and records in a second file. For the matches, determine the span of the actual range of record positions in the second file relative to the positions of the operation records in the first file within which all matches were found. If the actual span is smaller than the span of a current defined range of record positions by at least a first threshold value, decrease the span of the current defined range. If the actual span is within a second threshold value of the span of the current defined range, increase the span of the current defined range. If an amount above a third threshold value of operation records in the first file are not matched to operation records in the second file, increasing the span of the current defined range. | 08-21-2014 |
20140279945 | MATCHING TRANSACTIONS IN MULTI-LEVEL RECORDS - Identifying matching transactions. First and second log files contain operation records of transactions in a transaction workload, each file recording a respective execution of the transaction workload, the method comprising. A first record location in the first file and an associated window of a defined number of sequential second record locations in the second file are advanced one record location at a time. Whether each operation record of a complete transaction at a first record location has a matching operation record at one of the record locations in the associated window of second record locations is determined. If so, the complete transaction in the first file and the transaction that includes the matching operation records in the second file are identified as matching transactions. | 09-18-2014 |
20140337283 | COMPARING DATABASE PERFORMANCE WITHOUT BENCHMARK WORKLOADS - Database operation records are sequentially read from two or more log files. If the transaction identifier is new and the record is not an end-of-transaction record, an open transactions list entry is created. If the transaction identifier is new and the record is an end-of-transaction record, a transaction type list entry is created or updated. If the transaction identifier is not new and is not an end-of-transaction record, an open transactions list entry is updated. If the transaction identifier is not new and the record is an end-of-transaction record, a transaction type list entry is created or updated. When all log file records are read, analytical comparison between the information associated with two or more of the log files in data fields in the transaction type list entries is performed. | 11-13-2014 |
20140337364 | COMPARING DATABASE PERFORMANCE WITHOUT BENCHMARK WORKLOADS - Database operation records are sequentially read from two or more log files. If the transaction identifier is new and the record is not an end-of-transaction record, an open transactions list entry is created. If the transaction identifier is new and the record is an end-of-transaction record, a transaction type list entry is created or updated. If the transaction identifier is not new and is not an end-of-transaction record, an open transactions list entry is updated. If the transaction identifier is not new and the record is an end-of-transaction record, a transaction type list entry is created or updated. When all log file records are read, analytical comparison between the information associated with two or more of the log files in data fields in the transaction type list entries is performed. | 11-13-2014 |