EP1627334A1 - Undrop objects and dependent objects in a database system - Google Patents
Undrop objects and dependent objects in a database systemInfo
- Publication number
- EP1627334A1 EP1627334A1 EP04785596A EP04785596A EP1627334A1 EP 1627334 A1 EP1627334 A1 EP 1627334A1 EP 04785596 A EP04785596 A EP 04785596A EP 04785596 A EP04785596 A EP 04785596A EP 1627334 A1 EP1627334 A1 EP 1627334A1
- Authority
- EP
- European Patent Office
- Prior art keywords
- recycle bin
- objects
- database
- storage space
- dependent objects
- 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.)
- Granted
Links
- 230000001419 dependent effect Effects 0.000 title claims abstract description 70
- 238000010926 purge Methods 0.000 claims abstract description 33
- 238000000034 method Methods 0.000 claims abstract description 31
- 238000004590 computer program Methods 0.000 claims description 8
- 238000005192 partition Methods 0.000 abstract description 22
- 230000008569 process Effects 0.000 description 8
- 230000009286 beneficial effect Effects 0.000 description 7
- 239000002131 composite material Substances 0.000 description 3
- 238000010586 diagram Methods 0.000 description 3
- 230000007246 mechanism Effects 0.000 description 3
- 238000012986 modification Methods 0.000 description 2
- 230000004048 modification Effects 0.000 description 2
- 238000012545 processing Methods 0.000 description 2
- 238000013459 approach Methods 0.000 description 1
- 238000003491 array Methods 0.000 description 1
- 230000000694 effects Effects 0.000 description 1
- 238000013507 mapping Methods 0.000 description 1
- 230000008520 organization Effects 0.000 description 1
- 230000002085 persistent effect Effects 0.000 description 1
- 238000012552 review Methods 0.000 description 1
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/23—Updating
- G06F16/2379—Updates performed during online database operations; commit processing
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F2216/00—Indexing scheme relating to additional aspects of information retrieval not explicitly covered by G06F16/00 and subgroups
- G06F2216/09—Obsolescence
Definitions
- the present invention relates to computer systems. More specifically, the invention relates to providing the capability to undrop objects and dependent objects in a database system.
- DBMS database management system
- Information in a database can be stored utilizing numerous types of objects. For example, information can be stored in tables and access to tables can be facilitated by indices.
- Other commons objects include nested tables, partial tables, index organized tables (IOTs), large objects (LOBs), constraints, triggers, and the like.
- a user may decide to purge or delete an object. For example, the user may feel that the object is no longer necessary, to make more storage space available or it may be accidental. Regardless of the reason for the purge, a user occasionally changers her mind and desires to have the object back.
- the current state of the database is stored periodically. Additionally, a list of transactions that are performed on the database since that state are also stored. When a user desires to retrieve an object that has been purged, the database is rolled back to the last stored state. After the rollback, the transactions that were performed after the state was stored can be executed from the list of transactions.
- this solution can retrieve a purged object, it has a disadvantage that it is relatively time consuming. More importantly, it has the disadvantage that during the rollback and roll forward of the database, new transactions typically can not be excepted by the database. Thus, the database is in effect shut down during the retrieval of a purged object.
- the present invention provides innovative techniques for undropping objects and dependent objects in a database.
- a user desires to drop or get rid of an object, the object is moved or placed in a recycle bin. Objects that depend on this object may
- the invention provides a method of allowing undrop in a database system.
- a command to drop an object in a database is received.
- the object is moved to a recycle bin and if there depend objects that are dependent on the object, the dependent objects are moved to the recycle bin.
- the object is moved out of the recycle bin.
- the invention provides a method of allowing undrop in a database system.
- a command to drop an object in a database is received.
- the object is moved to a recycle bin and if there are dependent objects that depend on the object, the dependent objects are moved to the recycle bin.
- the object is moved is out of the recycle bin. If more space is needed, the object is purged to provide more storage space.
- FIG. 1 shows an example of a three-tiered architecture for a database management s stem.
- FIG. 2 illustrates a block diagram of a computer system that can be utilized in association with embodiments of the invention.
- FIG. 3 shows a block diagram of some exemplary objects in a database.
- FIG. 4 shows a flowchart of a process of undropping an object in a database including dependent objects if they are present.
- FIG. 5 shows a flowchart of a process that illustrates multiple ways an object can be removed from a recycle bin.
- FIG. 6 shows a flowchart of a process of purging objects from the recycle bin to obtain more storage space.
- FIG. 7 shows an example of a schema of a table that can be utilized to implement a recycle bin in a database system.
- FIG. 8 shows an example of entries in a table of FIG. 7 for an object (e.g., a table) and dependent object that have been dropped in the recycle bin.
- object e.g., a table
- a fairly common database management system architecture is the three-tiered architecture that is shown in FIG. 1.
- a central storage 1 that stores a database 3.
- Database 3 is typically stored on one or more hard drives, which is typically part of a larger computer system.
- the information can be stored on database 3 in a variety of formats with relational database management systems relying heavily on tables to store the information.
- Database servers 5 are instances of a program that interacts with database 3. Each instance of the database server can, among other things, independently query database 3 and store information therein. Database servers 5 may not include user friendly interfaces, such as graphical user interfaces.
- one or more application server 7 can provide the user interfaces to database server 5.
- application server 7 can be a web application server on the Internet (or other network).
- Application server 7 can provide user friendly mechanisms for accessing database 3 through database server 5.
- a web browser 9 can be utilized to access application server 7.
- FIG. 2 shows a block diagram of components that can be present in computer systems that implement embodiments of the invention.
- a computer system 101 includes a processor 103 that executes instructions from computer programs (including operating systems). Although processors typically have memory caches also, processor 103 utilizes memory 105, which can store instructions or computer code and data.
- a fixed storage 107 can store computer programs and data such that it is typically persistent and provides more storage when compared to memory 105.
- a common fixed storage for databases is multiple (e.g., arrays) hard drives.
- a removable storage 109 is
- OID-2002-113-01 provides mobility to computer programs and/or data that are stored thereon.
- removable storage are floppy disks, tape, CD/ROM, flash memory devices, and the like.
- Memory 103, fixed storage 107 and removable storage 109 provide examples of computer readable storage media that can be utilized to store and retrieve computer programs incorporating computer codes that implement the invention, data for use with the invention, and the like. Additionally, a data signal embodied in a carrier wave (e.g., in a network including the Internet) can be the computer readable storage medium.
- An input 111 allows a user to interface with the system. Input can be done through the use of a keyboard, a mouse, buttons, dials, or any other input mechanism.
- An output 113 allows the system to provide output to the user. Output can be provided through a monitor, display screen, LEDs, printer or any other output mechanism.
- a network interface 115 allows the system to interface with a network to which it is connected.
- the system bus architecture of computer system 101 is represented by arrows 117.
- the components shown in FIG. 2 can be found in many computer systems. However, components can be added, deleted and combined.
- fixed storage 107 could be a file server that is accessed through a network connection.
- FIG. 2 is for illustration purposes and not limitation.
- FIG. 3 shows objects and dependent objects that may be present in a database.
- a table 201 is shown to include a large object (LOB) 203.
- LOB large object
- Tables are a common object that are used to store information in a database. The information is typically stored in fields of the table and can include data types such as numbers, strings, pointers, nested tables, and the like.
- There are many kinds of tables in addition to a generic table such as nested tables, partitioned tables, IOTs, and the like.
- LOB 203 is shown to represent another type of data that may be stored in a table.
- LOBs can store information such as binary images and sound files.
- indices 205 and 207 are shown. Indices typically utilize key fields to more efficiently access a table.
- LOB 203 and indices 205 and 207 are examples of dependent objects because they are dependent on another object (table 201 in this case). They are dependent objects because without the object to which they depend, the dependent objects may be of little or no value.
- LOB 203 is an example of a dependent object that typically can not be reconstructed once purged.
- Other examples of dependent objects include constraints and triggers, but the invention can be advantageously applied to work with any type of dependent object.
- Databases are typically much more complex than is show in FIG. 3. However, the figure will be beneficial in describing embodiments of the invention.
- FIG. 4 shows a flowchart of a process of undropping an object from a database.
- steps can be added, deleted, combined, or reordered without departing from the sprit and scope of the invention.
- a command is received to drop an object.
- the command is typically received from a user and may be input through an interface such as a graphical user interface or a command line.
- the user is indicating that she believes that the object (e.g., a table) will no longer be needed.
- the object is moved to a recycle bin at a step 303.
- the recycle bin is repository that stores objects that have been dropped until a user undrops them, a user explicitly purges them or the database purges them in order to acquire more storage space.
- the moving of the object can be performed by changing variables that define what is in the recycle bin.
- the recycle bin is implemented as a dictionary table.
- an entry is made in this table and these objects can be undropped.
- the space for the objects in the recycle bin may still be allocated to the appropriate user even though they are dropped. Further details of one embodiment will be described below in reference to FIGS. 7 and 8.
- a step 305 it is determined whether there are any dependent objects that depend on the object that has been dropped. If there are dependent objects, the dependent objects are moved to the recycle bin at a step 307. For example, referring back to FIG. 3, if a user indicated that table 201 should be dropped, the system would identify LOB 203 and indices 205 and 207 as dependent objects on table 201 so they would be moved to the recycle bin.
- the object upon receiving a command to undrop the object, the object is moved out of the recycle bin at a step 309. By moving the object out of the recycle bin, the database system has been able to undrop a table without requiring the database to be effectively shut down during the retrieval.
- any dependent objects that are present in the recycle bin can also be moved out of the recycle bin (i.e., undropped).
- a reconstructable dependent object may have been purged from the recycle
- FIG. 5 OID-2002-113-01 bin in order to acquire more storage space.
- the reconstructable dependent object can be reconstructed when the object to which it depends is undropped, when the reconstructable object is needed, when the database system has a lull in processing requirements, or at any other time.
- FIG. 4 showed an example of how an object and dependent objects may be moved to the recycle bin.
- FIG. 5 shows ways in which objects may be moved out of the recycle bin. More specifically, FIG. 5 shows a flowchart of a process showing ways objects and dependent objects can be removed from the recycle bin.
- a user can execute commands to remove objects and dependent objects from the recycle bin. For example, the user can explicitly purge an object or dependent object from the recycle bin at a step 353. Once the object or dependent object is purged, it may be necessary to perform a roll back and roll forward in order to retrieve the object or dependent object if the user changes her mind. Additionally, the user may undrop an object or dependent object at a step 355. By undropping the object or dependent object, the object or dependent object is moved out of the recycle bin and is available as if it was never dropped.
- the database may select an object to purge at a step 357.
- the database may purge dependent objects that depend on the selected object at a step 359.
- the selected object is purged.
- the database selects the object and dependent objects (if any) to purge if more storage space is needed.
- a user can be involved in this process to, for example, select the object or objects to be purged.
- FIG. 6 shows a flowchart of a process of obtaining more storage space by purging one or more objects in the recycle bin.
- a request for an amount of storage space is received.
- the oldest object is selected to be purged at a step 403. Although in some embodiments, the oldest object is selected, other embodiments can use any number of characteristics to select an object to be purged.
- a step 405 it is determined whether the selected object is partitioned. If the selected object is not partitioned, the object is purged at a step 407. Objects that depend on the purged object can also be purged. However, if the dependent objects are not required to
- OID-2002-113-01 be purged at this time because the purging of the object at step 407 provided the requested the storage space, the purging of dependent objects can be postponed to a later time.
- a daemon runs in the background and identifies dependent objects in the recycle bin that have been marked as purgeable but have not yet been purged. The daemon can then purge these dependent objects when it is more convenient.
- step 409 it is determined whether more storage space is still needed and if it is, the flow returns to step 403. Otherwise, the requested storage space has been made available.
- one or more partitions are purged at a step 411. In some embodiments, all of the partitions are purged. However, if less than all of the partitions need to be purged in order to obtain the requested storage space, only those partitions are purged immediately. As described above, the other partitions can be marked as purgeable and a daemon can purge these partitions from the recycle bin at a later time. Thus, a portion (e.g., one or more partitions) of an object can be marked for a future purge. As can be seen by only purging the objects or partitions that are needed to obtain the requested storage space, the user (or database) is only waiting as long as necessary to obtain the storage space.
- the user does not need to wait for dependent objects or partitions to be purged for storage space that she does not need. For this reason, in some embodiments, when a user explicitly purges an object, the object, all dependent objects and all partitions are purged immediately (i.e., not deferred for purging by a daemon) since it is the user that has issued the command and should incur the processing delay.
- the recycle bin can be implemented as a table.
- the table can include an entry for every object that has been dropped.
- FIG. 7 shows an example of a schema for a table to implement the recycle bin and the following will describe the specific fields in the table.
- OBJ# stores the original object number for the dropped object. This field is used to identify the object in the dictionary tables. OBJ# is unique for all the objects in the database and hence forms the unique identifier for the object. In case of partitions, a new object will be created at the time it is moved to the recycle bin, and hence a new OB J# can be assigned to it. This new OBJ# can then be used to identify the subject partition. In some embodiments, if a partition is undropped, then it will be recovered as a new object.
- OID-2002-113-01 OWNER# is used to store the USER# for the original owner of the object.
- the owner information can be modified for that object. If the user undrops the object, it should be restored back to the original owner, which can be facilitated with this field.
- ORIGLNAL_NAME holds the original name of the object. The object's name can be changed when its moved to the recycle bin. The original name of the object is maintained just for the user's convenience.
- OPERATION specifies the DDL operation which was performed over the object. This field can be used to distinguish whether the object was dropped or truncated so that it can be handled appropriately. This field can hold one of the following 2 valid values: 0 - Object was dropped (DROP) and 1- Object was truncated (TRUNCATE).
- TYPE# stores the object type of the dropped object.
- LOB LOB index
- domain index IOT top index
- IOT overflow segment IOT mapping table
- trigger constraint
- table partition table composite partition, index partition, index composite partition, LOB partition, LOB composite partition, and the like.
- TS# provides the Table Space number for the object which is dropped and now moved to the recycle bin. This can be beneficial to try to free up space for the Tablespace which is on the verge of filling up. Reclaiming the space from the Tablespace which still has large amount of space to space may not solve the problem of space pressure, and hence it would be beneficial to reclaim space from the recycle bin only for the table space which is almost full and needs some space.
- FILE# stores the File Number for the segment header for the object. Along with the TS# and BLOCK#, a unique SEG$ entry can be obtained. BLOCK# provides the Block Number for the segment header for the object. Along with the TS# and FILE#, a unique SEG$ entry can be obtained. This field can be utilized to efficiently access the segment header in case of space pressure.
- DROPTEVIE stores the system time when the object was dropped. The value of this field can be used to calculate the time for which the object has been present in the recycle bin. In case of space pressure, objects can be reclaimed from the recycle bin in the order they were dropped. Thus, this field is even used to maintain a time based ordering of the objects in the recycle bin.
- DROPSCN provides the SCN which caused the drop of the object. This may be useful for Flash Back queries.
- FLAGS keeps the various flags for the object in the recycle bin.
- One of the bits in this field can be used for keeping track whether the object can be undropped. If an incremental approach for space reclamation, it's quite possible that only few extents belonging to an object are freed up and remaining extents are still present in the recycle bin. An object can be undropped if no extent allocated to that object has been freed up. If even one extent belonging to an object is freed, then it should not be undropped.
- BO stores the OBJ# for the base table which caused this object to be dropped and placed in the recycle bin.
- PURGEOBJ provides the OBJ# for the object which will be purged (e.g., either the index or table) under space pressure if it is desirable to purge this particular object from the system and release space.
- BASE_TS# stores the TableSpace number for the base object (e.g., table).
- BASE_OWNER# holds the user number for the owner of the base object.
- SPACE provides the size of the object. This field can be used to see how much space is utilized by the objects in the recycle bin (e.g., in number of blocks).
- CON# stores the constraint ID in case of the indexes which are built due to a constraint. Otherwise this will be NULL.
- SPARE 1, SPARE2 and SPARE3 may be utilized in future implementations.
- FIG. 8 shows entries for an object and dependent object that have been dropped.
- the entries indicate that a table TABLE 1 and an index INDEX 1 (dependent object) have been dropped. These entries were added to the table when TABLE 1 was dropped.
- the RELATED field indicates that LNDEX1 is related to TABLE 1.
- MDEXl is in the recycle bin because TABLE 1 was dropped.
Abstract
Description
Claims
Applications Claiming Priority (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US10/445,793 US8521789B2 (en) | 2003-05-27 | 2003-05-27 | Undrop objects and dependent objects in a database system |
PCT/US2004/010616 WO2004107215A1 (en) | 2003-05-27 | 2004-04-07 | Undrop objects and dependent objects in a database system |
Publications (2)
Publication Number | Publication Date |
---|---|
EP1627334A1 true EP1627334A1 (en) | 2006-02-22 |
EP1627334B1 EP1627334B1 (en) | 2012-09-26 |
Family
ID=33450939
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
EP04785596A Expired - Lifetime EP1627334B1 (en) | 2003-05-27 | 2004-04-07 | Undrop objects and dependent objects in a database system |
Country Status (7)
Country | Link |
---|---|
US (1) | US8521789B2 (en) |
EP (1) | EP1627334B1 (en) |
JP (1) | JP2007501476A (en) |
CN (1) | CN1791873B (en) |
AU (1) | AU2004244168B2 (en) |
CA (1) | CA2522047A1 (en) |
WO (1) | WO2004107215A1 (en) |
Families Citing this family (12)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US6920460B1 (en) * | 2002-05-29 | 2005-07-19 | Oracle International Corporation | Systems and methods for managing partitioned indexes that are created and maintained by user-defined indexing schemes |
US7634510B2 (en) * | 2004-10-05 | 2009-12-15 | Oracle International Corporation | Method and system for time-based reclamation of objects from a recycle bin in a database |
US7636737B2 (en) * | 2005-12-20 | 2009-12-22 | Microsoft Corporation | Web site multi-stage recycling |
CN101546311B (en) * | 2008-03-27 | 2012-05-02 | 北京铭万互联科技有限公司 | Data processing method and data processing device for recycle bin |
US8380702B2 (en) * | 2009-03-10 | 2013-02-19 | Oracle International Corporation | Loading an index with minimal effect on availability of applications using the corresponding table |
CN102750198B (en) * | 2011-04-20 | 2016-01-20 | 腾讯科技(深圳)有限公司 | A kind of backup method of social network sites content and system |
US9046998B2 (en) * | 2012-09-14 | 2015-06-02 | Empire Technology Development Llc | Cloud-based trash-can |
WO2014094259A1 (en) * | 2012-12-19 | 2014-06-26 | 华为技术有限公司 | Method and device for processing storage space object |
US9063967B2 (en) * | 2013-01-10 | 2015-06-23 | Pure Storage, Inc. | Performing copies in a storage system |
WO2016053231A1 (en) | 2014-09-29 | 2016-04-07 | Hewlett Packard Enterprise Development Lp | Retain data above threshold |
US20180018356A1 (en) * | 2016-07-13 | 2018-01-18 | Deepspace Storage Systems Inc. | Relational database online storage manager |
CN112181938A (en) * | 2019-07-05 | 2021-01-05 | 杭州海康威视数字技术股份有限公司 | Database cleaning method, device and computer readable storage medium |
Family Cites Families (13)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US83064A (en) * | 1868-10-13 | Improved gearing for grindstones | ||
US6246410B1 (en) | 1996-01-19 | 2001-06-12 | International Business Machines Corp. | Method and system for database access |
US5767851A (en) | 1996-01-29 | 1998-06-16 | Sun Microsystems, Inc. | Method and apparatus for emulating an environment's drag and drop functionality in a host environment |
US5802514A (en) | 1996-04-09 | 1998-09-01 | Vision Software Tools, Inc. | Automated client/server development tool using drag-and-drop metaphor |
JPH10240592A (en) * | 1996-12-27 | 1998-09-11 | Fujitsu Ltd | Device and method for showing dependency relation of file |
CN1201950A (en) | 1998-05-08 | 1998-12-16 | 中国人民解放军济南医学高等专科学校 | Method for deleting and restoring lines of table in database |
CA2279028C (en) | 1999-07-29 | 2002-09-10 | Ibm Canada Limited-Ibm Canada Limitee | Dropped database table recovery |
US6591295B1 (en) | 1999-11-05 | 2003-07-08 | Oracle International Corp. | Methods and apparatus for using multimedia data stored in a relational database in web applications |
US6611836B2 (en) | 2000-12-26 | 2003-08-26 | Simdesk Technologies, Inc. | Server-side recycle bin system |
JP2002278821A (en) * | 2001-03-22 | 2002-09-27 | Sharp Corp | System and method for managing data and program for providing computer with data managing system |
JP2002366410A (en) * | 2001-06-06 | 2002-12-20 | Fujitsu Ltd | Trash box server and trash box processing program |
JPWO2003001422A1 (en) * | 2001-06-26 | 2004-10-14 | 俊行 谷 | How to provide transaction information |
JP4284896B2 (en) * | 2001-08-02 | 2009-06-24 | コニカミノルタビジネステクノロジーズ株式会社 | File management program, computer-readable recording medium storing file management program, and file management method |
-
2003
- 2003-05-27 US US10/445,793 patent/US8521789B2/en active Active
-
2004
- 2004-04-07 CN CN200480013535.7A patent/CN1791873B/en not_active Expired - Lifetime
- 2004-04-07 WO PCT/US2004/010616 patent/WO2004107215A1/en active Application Filing
- 2004-04-07 CA CA002522047A patent/CA2522047A1/en not_active Abandoned
- 2004-04-07 JP JP2006532383A patent/JP2007501476A/en active Pending
- 2004-04-07 EP EP04785596A patent/EP1627334B1/en not_active Expired - Lifetime
- 2004-04-07 AU AU2004244168A patent/AU2004244168B2/en not_active Expired
Non-Patent Citations (1)
Title |
---|
See references of WO2004107215A1 * |
Also Published As
Publication number | Publication date |
---|---|
CN1791873B (en) | 2014-01-15 |
JP2007501476A (en) | 2007-01-25 |
CA2522047A1 (en) | 2004-12-09 |
US20040243624A1 (en) | 2004-12-02 |
AU2004244168A1 (en) | 2004-12-09 |
AU2004244168B2 (en) | 2009-11-26 |
EP1627334B1 (en) | 2012-09-26 |
WO2004107215A1 (en) | 2004-12-09 |
US8521789B2 (en) | 2013-08-27 |
CN1791873A (en) | 2006-06-21 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US8051045B2 (en) | Archive indexing engine | |
US8620884B2 (en) | Scalable blob storage integrated with scalable structured storage | |
US8868624B2 (en) | Blob manipulation in an integrated structured storage system | |
US5347653A (en) | System for reconstructing prior versions of indexes using records indicating changes between successive versions of the indexes | |
US5999943A (en) | Lob locators | |
US7472140B2 (en) | Label-aware index for efficient queries in a versioning system | |
US7418544B2 (en) | Method and system for log structured relational database objects | |
US6631366B1 (en) | Database system providing methodology for optimizing latching/copying costs in index scans on data-only locked tables | |
US6460048B1 (en) | Method, system, and program for managing file names during the reorganization of a database object | |
US8682859B2 (en) | Transferring records between tables using a change transaction log | |
US9430331B1 (en) | Rapid incremental backup of changed files in a file system | |
CA2302303A1 (en) | System for accessing database tables mapped into memory for high performance | |
US7953749B2 (en) | Providing the timing of the last committed change to a row in a database table | |
US20100235348A1 (en) | Loading an index with minimal effect on availability of applications using the corresponding table | |
EP1627334B1 (en) | Undrop objects and dependent objects in a database system | |
US20050076018A1 (en) | Sorting result buffer | |
US9418154B2 (en) | Push-model based index updating | |
US20090106324A1 (en) | Push-model based index deletion | |
US7634510B2 (en) | Method and system for time-based reclamation of objects from a recycle bin in a database | |
EP1505516A1 (en) | Metadata based query | |
US8510269B2 (en) | Uninterrupted database index reorganization/movement | |
Zabback et al. | Office documents on a database kernel—filing, retrieval, and archiving | |
CN115827653A (en) | Pure column type updating method and device for HTAP and mass data | |
Mittra | Special Features of Oracle 8i and a Glimpse into Oracle 9i | |
Nrvхg | Technical report IDI-TR-11/2002 |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
PUAI | Public reference made under article 153(3) epc to a published international application that has entered the european phase |
Free format text: ORIGINAL CODE: 0009012 |
|
17P | Request for examination filed |
Effective date: 20051209 |
|
AK | Designated contracting states |
Kind code of ref document: A1 Designated state(s): DE FR GB NL |
|
DAX | Request for extension of the european patent (deleted) | ||
RBV | Designated contracting states (corrected) |
Designated state(s): DE FR GB NL |
|
17Q | First examination report despatched |
Effective date: 20060314 |
|
GRAP | Despatch of communication of intention to grant a patent |
Free format text: ORIGINAL CODE: EPIDOSNIGR1 |
|
GRAS | Grant fee paid |
Free format text: ORIGINAL CODE: EPIDOSNIGR3 |
|
GRAA | (expected) grant |
Free format text: ORIGINAL CODE: 0009210 |
|
AK | Designated contracting states |
Kind code of ref document: B1 Designated state(s): DE FR GB NL |
|
REG | Reference to a national code |
Ref country code: GB Ref legal event code: FG4D |
|
REG | Reference to a national code |
Ref country code: DE Ref legal event code: R096 Ref document number: 602004039482 Country of ref document: DE Effective date: 20121122 |
|
REG | Reference to a national code |
Ref country code: NL Ref legal event code: VDEP Effective date: 20120926 |
|
PG25 | Lapsed in a contracting state [announced via postgrant information from national office to epo] |
Ref country code: NL Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT Effective date: 20120926 |
|
PLBE | No opposition filed within time limit |
Free format text: ORIGINAL CODE: 0009261 |
|
STAA | Information on the status of an ep patent application or granted ep patent |
Free format text: STATUS: NO OPPOSITION FILED WITHIN TIME LIMIT |
|
26N | No opposition filed |
Effective date: 20130627 |
|
REG | Reference to a national code |
Ref country code: DE Ref legal event code: R097 Ref document number: 602004039482 Country of ref document: DE Effective date: 20130627 |
|
REG | Reference to a national code |
Ref country code: FR Ref legal event code: ST Effective date: 20131231 |
|
PG25 | Lapsed in a contracting state [announced via postgrant information from national office to epo] |
Ref country code: FR Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES Effective date: 20130430 |
|
REG | Reference to a national code |
Ref country code: DE Ref legal event code: R079 Ref document number: 602004039482 Country of ref document: DE Free format text: PREVIOUS MAIN CLASS: G06F0017300000 Ipc: G06F0016000000 |
|
PGFP | Annual fee paid to national office [announced via postgrant information from national office to epo] |
Ref country code: GB Payment date: 20230302 Year of fee payment: 20 |
|
P01 | Opt-out of the competence of the unified patent court (upc) registered |
Effective date: 20230523 |
|
PGFP | Annual fee paid to national office [announced via postgrant information from national office to epo] |
Ref country code: DE Payment date: 20230307 Year of fee payment: 20 |
|
REG | Reference to a national code |
Ref country code: DE Ref legal event code: R071 Ref document number: 602004039482 Country of ref document: DE |