Oracle International Corporation

Sundeep Abraham

Zhen Hua Liu

Geeta Arora

Douglas James McMahon

Beda Christoph Hammerschmidt

Hui Joe Chang

Ying Lu

Vikas Arora

Sriram Krishnamurthy

Joshua Jeffrey Spiegel

Hui Zhang

Srikrishnan Suresh

Alfonso Colunga Sosa

Juan R Loaiza

Ravi Murthy

Muralidhar Krishnaprasad

Tirthankar Lahiri

Ananth Raghavan

Nimar Singh Arora

James W Warner

Ajit Mylavarapu

Aurosish Mishra

Sukhada Pendse

Shubha Bose

Lik Wong

Sivasankaran Chandrasekar

Srinath Krishnaswamy

Mehul Dilip Bastawala

Yasuhiro Matsuda

Edwina Lu

Rajendra Pingte

Ravikanth Kasamsetty

Wesley Lin

Mohammad Faisal

Shashank Gugnani

JSON Duality Views are object views that return JDV objects. JDV objects are virtual because they are not stored in a database as JSON objects. Rather, JDV objects are stored in shredded form across tables and table attributes (e.g. columns) and returned by a DBMS in response to database commands that request a JDV object from a JSON Duality View. Through JSON Duality Views, changes to the state of a JDV object may be specified at the level of a JDV object. JDV objects are updated in a database using optimistic lock.

Natively supporting JSON duality view in a database management system

Herein is a self-tuning database management system (DBMS) storing JavaScript object notation (JSON) documents and operating a JSON datatype as native to the DBMS. In an embodiment, a computer hosts a DBMS that executes a data definition language (DDL) statement that defines, in a database dictionary of the DBMS, a JSON document column of a database table that stores JSON documents as instances of the JSON datatype that is native in the DBMS. The DBMS may autonomously set or adjust configuration settings that control behaviors such as a default width of a JSON document column, in lining or not of the JSON document column, kind and scope and duration of indexing of the JSON document column, and/or caching of the JSON document column such as in an in memory columnar unit (IMCU). The DBMS may use the various configuration settings to control how JSON documents and the native JSON datatype are stored and/or processed.

Technique of efficiently, comprehensively and autonomously support native JSON datatype in RDBMS for both OLTP and OLAP

Efficiently replicating XML data among databases includes techniques for (a) replicating XML data involved with an insert operation; (b) replicating XML data involved with an update operation; (c) leveraging existing relational replication techniques for XML data stored in shredded form using object-relational constructs; and (d) replicating XQuery Data Model sequences. Each technique reduces the amount of information that would otherwise need to be transmitted over a network for XML data replication purposes.

Efficient replication of XML data in a relational database management system

Systems, methods, and other embodiments associated with selectively acquiring and utilizing query statistics are described. One example method includes selectively acquiring statistics associated with search queries submitted to a search process during a sample period. The statistics may be associated with an index and tokens associated with the index and search queries. The method may also include selecting tokens and/or queries to optimize based, at least in part, on the statistics. In one example, whether and/or how the tokens and/or queries are optimized may depend on estimating index fragmentation based, at least in part, on the statistics.

Query statistics

Instances of complex types are logically replicated. In general, the logical replication of complex types involves converting a complex type instance from its storage format into a logical representation written in a markup language, like XML. The logical representation is then propagated to a destination (or destinations), which converts the logical representation to a storage format used at the destination for that complex type.

Using XML for flexible replication of complex types

Schema conversion approaches convert images of complex objects. The schema conversion is performed on images of complex objects belonging to a root class, whether those objects are instances of the root class or instances of a subclass of the root class. A complex object is an object that is comprised of a collection of objects or that has another object as an attribute. The approaches use change vectors to represent changes to make to an image to convert it between the target schema version and source schema version. Change vectors are generated based on schema version records, each of which describes the properties of a schema version, including the attributes in the schema version and the data type of each of the attributes. The approaches evolve changes that includes addition, modification and deletion of object attributes. They convert from an earlier schema version to a later schema version, and vice versa, i.e. from a later schema version to a earlier schema version.

Schema evolution of complex objects

Growing community of inventors

Belmont, CA, United States of America

Sundeep Abraham