WL#4180: Persistent object versions
Affects: Server-Prototype Only — Status: Un-Assigned
Implement persistent object versions, that are stored along with object definition for the following objects: * tables * views * stored procedures * stored functions Rationale: * provide a persistent version for validation of prepared statements (WL#4165). The current suggestion of WL#4165 is to use non-persistent object versions, since they require no changes in the data dictionary storage format. The drawback, however, is that non-persistent versions are prone to "false negatives" during statement validation (that is, render some valid statements as invalid). * implement a truly online ALTER TABLE. Online ALTER TABLE today must wait for all old transactions to finish to be able to remove the old version of the table from the table definition cache. Currently the table definition cache is a hash with key being
. . If each table has a version, the table definition cache can include it into the key, or keep two versions of the table in the cache in some other way, and thus it will be possible to ship the old version of TABLE_SHARE to "old" transactions, and the new version of it to "new" transactions, i.e. transactions that started after online ALTER TABLE completion. Requirements ------------ 1. objects of different types may have the same version value 2. objects of the same type with different names may have the same version value 3. objects of the same type *and* having the same name (i.e. a table that was dropped and created anew) may (but does not have to) have the same version value but only if other metadata is identical. 4. in all other cases, object versions should never be equal Less strict requirements will lead to "false positives" in statement validation of WL#4165. Choice of object version ------------------------ 1) Global counter Implement a system table that stores a global counter incremented upon each DDL statement. Advantages: - allows to track relative age of objects, i.e. say that this stored procedure is older than this view - an object with the same name that was dropped and created anew gets a new version Disadvantages: - each DDL statement needs access to the system table with the global counter 2) Local counter. Store a local counter along with the definition of the object. The counter may start at 0, and then be incremented with each alteration of an object. Not acceptable as violates requirement #3. Listed here only because is a popular suggestion. 3) Version value derived from object metadata 3a. MD5 of object definition. Advantages: * does not have to be persistent -- and therefore allows for backward compatibility with data dictionaries of 5.0 and 5.1. * yields the same value for the same metadata Disadvantages: * size is 32 bytes. Considered neglectible. * cost of calculation: O(metadata length) Considered neglectible. 4) UUID * size: 36 bytes * calculation cost: O(1) + cost of high-precision timer 5) timestamp (high-precision, probably) * this is a simplified version of the 4th choice (timestamp is a part of UUID) 6) Simplified UUID, made as a combination of the current time (unixtime since the start of an epoch) and a pseudo-random number, to resolve possible collisions within timer resolution (1 second) 7) A two-part version number, where first part only changes when table layout has changed (column order, names and types). The second part is built using one of the algorithms listed above. The first part can be used to track "incompatible" changes to a table or a view. 8) At the architecture board in Stockholm, March 2008 it was decided to use the following object version format: 1 byte (approx.) - format type 1 byte (approx.) - length of the version. Could be collapsed with format type blob - version body Version body: two-part number that consists of high and low part. High part changes after offline ALTER, low part changes when after online ALTER This object version should be introduced as part or after WL#2760 (New Data Dictionary) References ----------- BUG#15638 need an id for db objects
Copyright (c) 2000, 2020, Oracle Corporation and/or its affiliates. All rights reserved.