Database system event triggers

[0002] The present invention relates to database management systems, and more particularly, to database management systems in which selectable system events trigger programmable actions upon satisfaction of programmable conditions.

[0003] Databases are organized arrangements of information on computer systems convenient for storing and retrieving information. Database management systems provide resources for conveniently creating, maintaining, deleting and protecting access to databases. In a relational database system a single database is made up of one or more related tables, each table having information arranged in rows and columns. Each column represents a kind of information and each row stores values for all the columns in the table.

[0004] Users interact with a database using a query language such as the Structure Query Language (SQL). SQL is a powerful non-procedural language which serves as the industry standard for relational database management systems. Data Manipulation Language (DML) statements are SQL statements that retrieve or manipulate data in tables. DML statements are the most frequently used SQL statements. Data Definition Language (DDL) statements are SQL statements that define, alter the structure of, and drop tables.

[0005] In a database management system, a trigger is an object that specifies a series of actions to be automatically performed when a specific event occurs. According to industry standards, DML statements are the events that cause user-defined triggers to be activated (or “fired”). For example, in a relational database, user-defined triggers may be designed to fire when a row of a database table or a table view is updated, inserted, or deleted. Accordingly, each user-defined trigger is typically associated with a single database table. That is, in a conventional database management system, the scope of the user-defined trigger is the table level of the database.

[0006] The series of actions specified by a trigger is typically written as instructions in a high-level database language such as SQL or PL/SQL (a procedural language extension of SQL available from Oracle Corporation of Redwood Shores, Calif.). In conformance with industry standards, these instructions must be able to access the data values of table columns corresponding to an affected row before the triggering DML statement was applied (the “old values”) and after the modification was applied (the “new values”).

[0007] Since triggers are objects, database customers can define, remove, and store triggers associated with a database table, and the database management system keeps track of which triggers have been defined for which table by storing that information as metadata (information about data) associated with the table in a data dictionary for the database. Consequently, triggers enable database customers to implement additional functionality in their databases for such purposes as enforcement of business rules and security.

[0008] Conventional trigger mechanisms can be wasteful of system resources. Specifically, triggers often include conditions. When a trigger is fired, the condition associated with the trigger is evaluated. If the condition is satisfied, then some specified action is performed. If the condition is not satisfied, then no action is performed. Thus, the number of times a trigger fires may be magnitudes greater than the number of times the action associated with the trigger actually has to be performed.

[0009] When the triggering event has occurred, substantial system resources are required to evaluate the condition. For example, to evaluate any allowed SQL condition, code encompassing about 20,000 instructions must be executed. This consumption of resources is exacerbated as the number of triggers associated with each event increases. For example, if a database has 1000 users, and each has defined 3 triggers for a “delete” operation on the same table, then 3000 triggers fire when a delete event occurs on that table, and 3000 conditions have to be evaluated, each requiring the execution of code with 20,000 instructions. This evaluation load is the same whether or not the conditions are satisfied. Thus it is possible to consume substantial resources just to conclude that few or no actions are to be executed.

[0010] Trigger conditions and actions are procedures typically stored with table metadata in a data dictionary within the database. Trigger events are confined to table and view level DML operations insert, update, delete. When a user defines a trigger, the user specifies the event name. The event name must be chosen from a short list of selectable events. The selectable events are INSERT, UPDATE and DELETE. The user must then specify the table name, e.g., EMPLOYEE if the employee table is to have the trigger. Then the user provides the condition as an SQL expression and the action as a stored procedure.

[0011] The trigger is then fired when the user executes an SQL statement that performs the selected DML operation on the specified table. When the table is referenced in an SQL statement as the result of a database tool or a user application process run at a later time by the same or a different user, the table metadata is loaded into memory, including a map of all the table triggers and events on which they fire. The trigger events are compared to the SQL statement to see if the trigger is applicable, i.e., if the SQL statement includes the DML operation that is the event for the trigger, e.g. the trigger is for INSERT and the SQL statement includes the INSERT operation for this table. If the trigger is applicable, then the condition and action statements are loaded into a cache in dynamic memory from disk, if not already there, compiled if necessary, and combined with the rest of the compiled SQL statement. Then when the compiled SQL statement is executed, the trigger condition is evaluated using the available old and/or new values on the row. If the condition is satisfied, the action is executed, again using the old or new values if needed.

[0012] There are many database system states and system operations for which the conventional system does not allow customers to define triggers. These states and operations can be important to the customer but have a scope beyond that of the table level. For example, a user of several databases may wish to respond to a particular database starting up. As another example, the owner of a table in a database may want to respond to a particular user logging on. As further examples, the user may wish to respond to the amount of available volatile storage, to the occurrence of a particular DDL statement, to the occurrence of an error condition, or to the state of a queue of DML operations. With the conventional database management system, the customer can not define triggering events based on such states and operations beyond the scope of the table level.

[0013] One technique for customers to define actions that are performed upon the occurrence of such important situations involves polling the database by periodically sending requests from a database application to the database server that manages the database. In polling, the state of the database (as recorded, for example, in dynamic performance tables) is provided to the database application in response to a specific request for that information. The information thus provided to the database application may then be used by the database application to determine whether to issue certain commands to the database server.

[0014] With polling, the request is repeated at regular intervals of time dependent upon a polling frequency. If the polling frequency is very high, the polling will consume many system resources and interfere with the performance of the database being tracked. If the polling frequency is very low, important events may be discovered too late, or missed altogether. Thus polling can be expensive, unreliable, or both.

[0015] There is a need to reduce the consumption of system resources in applying triggers fired at the table level upon DML operations. There is also a need for users to respond to system states and operations beyond the scope of the table level, without resorting to polling.

[0016] Techniques are provided for database management using triggers of different scopes. According to one technique, data are received that indicate a selected scope for a trigger. The selected scope for the trigger is selected from several selectable scopes of database management. Each scope is associated with a set of one or more events. Data are also received that indicate a selected event that belongs to the set of one or more events. Trigger metadata for the trigger are stored, including data identifying the selected scope and the selected event.

[0017] In another aspect of the invention, a technique for executing a process in a database management system includes maintaining metadata about a particular scope. The particular scope is associated with a set of one or more events. The metadata about the particular scope includes one or more triggers associated with the particular scope. When the process causes a new event in the set of one or more events to occur, the technique checks flags that indicate which events in the set are associated with at least one trigger. If the flags indicate that the new event is associated with a trigger, then the trigger is fired.

[0018] In another aspect of the invention, a technique for executing a process in a database management system includes maintaining metadata about multiple scopes, each scope associated with a set of one or more events. A hierarchical relationship exists among the scopes. The metadata about the scopes includes a hierarchy indicating the hierarchical relationship. The technique also maintains metadata about each particular scope. The metadata about each particular scope includes the set of one or more events associated with the particular scope, one or more triggers associated with the particular scope, and flags that indicate which events in the set of one or more events associated with the particular scope are associated with at least one trigger. The process is associated with a first scope. The flags for the first scope are loaded into a private cache for the process. Also loaded into the private cache are the flags for a second scope. The second scope occurs at a higher level in the hierarchy than the level of the first scope.

[0019] In another aspect of the invention, a trigger map for a certain scope is stored on a computer-readable medium and used for database management. The trigger map includes flags that correspond to selectable events for the scope. A flag is “on” if a trigger is defined for that event at that scope.

[0020] In another aspect of the invention, a computer-readable medium bears information used for database management. This information includes a field indicating the number of triggers in a cache and at least one trigger specification area. The trigger specification area holds data which indicates one of several selectable events for firing the trigger.

[0021] The present invention is illustrated by way of example, and not by way of limitation, in the figures of the accompanying drawings and in which like reference numerals refer to similar elements and in which:

[0022] FIG. 1 is a block diagram of a computer system on which an embodiment of the invention may be implemented.

[0023] FIG. 2 is a block diagram of memory allocation on a computer system utilized by an embodiment of the present invention.

[0024] FIG. 3 is a flowchart for a method to create triggers of indicated scope according to one embodiment of the invention.

[0025] FIG. 4 is a block diagram of flags in a trigger map according to an embodiment of the invention.

[0026] FIG. 5 is a flowchart for a first portion of a method to use triggers of indicated scope according to an embodiment of the invention.

[0027] FIG. 6 is a flowchart for a second portion of a method to use triggers of indicated scope according to an embodiment of the invention.

[0028] FIG. 7 is a flowchart for details of step 630 of FIG. 6, according to an embodiment of the invention.

[0029] FIG. 8 is a block diagram of memory allocation in a shared cache for triggers of indicated scope according to an embodiment of the invention.

[0030] Techniques for providing database system event triggers are described. In the following description, for the purposes of explanation, numerous specific details are set forth in order to provide a thorough understanding of the present invention. It will be apparent, however, to one skilled in the art that the present invention may be practiced without these specific details. In other instances, well-known structures and devices are shown in block diagram form in order to avoid unnecessarily obscuring the present invention.

[0031] As mentioned above, in conventional database systems, triggers are associated with a table or view. That is, triggers have a table scope only. According to one aspect of the present invention, triggers are defined not only for events associated with tables and views, i.e., at the table scope, but also for events that occur at other scopes. Further, techniques are provided that allow users to define and use triggers that fire on events that include non-DML operations, such as: database startup and shutdown, a user logging onto and off the database, DDL operations, errors or exceptions generated during process execution, invocation of a stored procedure, database statistics achieving certain values, calls into a database server, and calls to an enterprise manager.

[0032] According to one embodiment, triggers that fire on non-DML operations are not handled in the same way as triggers defined for table level DML statements. For example, consider a trigger defined with a database scope when a user logs on to the database. This trigger is not associated with a particular table and must be fired before a user's SQL statement operation on a table is processed by being parsed and compiled. That is, the trigger cannot be fired at compile time like DML triggers. Thus, triggers not associated with DML operations on tables (non-DML events) are supported using techniques to load trigger maps, determine if the trigger is applicable, and load the conditions and actions of applicable triggers at run time, rather than at compile time. Those techniques shall be described in greater detail hereafter.

[0033] FIG. 1 is a block diagram that illustrates a computer system 100 upon which an embodiment of the invention may be implemented. Computer system 100 includes a bus 102 or other communication mechanism for communicating information, and a processor 104 coupled with bus 102 for processing information. Computer system 100 also includes a main memory 106, such as a random access memory (RAM) or other dynamic storage device, coupled to bus 102 for storing information and instructions to be executed by processor 104. Main memory 106 also may be used for storing temporary variables or other intermediate information during execution of instructions to be executed by processor 104. Computer system 100 further includes a read only memory (ROM) 108 or other static storage device coupled to bus 102 for storing static information and instructions for processor 104. A storage device 110, such as a magnetic disk or optical disk, is provided and coupled to bus 102 for storing information and instructions.

[0034] Computer system 100 may be coupled via bus 102 to a display 112, such as a cathode ray tube (CRT), for displaying information to a computer user. An input device 114, including alphanumeric and other keys, is coupled to bus 102 for communicating information and command selections to processor 104. Another type of user input device is cursor control 116, such as a mouse, a trackball, or cursor direction keys for communicating direction information and command selections to processor 104 and for controlling cursor movement on display 112. This input device typically has two degrees of freedom in two axes, a first axis (e.g., x) and a second axis (e.g., y), that allows the device to specify positions in a plane.

[0035] The invention is related to the use of computer system 100 for database system event triggers. According to one embodiment of the invention, triggers are identified and fired by computer system 100 in response to processor 104 executing one or more sequences of one or more instructions contained in main memory 106. Such instructions may be read into main memory 106 from another computer-readable medium, such as storage device 110. Execution of the sequences of instructions contained in main memory 106 causes processor 104 to perform the process steps described herein. In alternative embodiments, hard-wired circuitry may be used in place of or in combination with software instructions to implement the invention. Thus, embodiments of the invention are not limited to any specific combination of hardware circuitry and software.

[0036] The term “computer-readable medium” as used herein refers to any medium that participates in providing instructions to processor 104 for execution. Such a medium may take many forms, including but not limited to, non-volatile media, volatile media, and transmission media. Non-volatile media includes, for example, optical or magnetic disks, such as storage device 110. Volatile media includes dynamic memory, such as main memory 106. Transmission media includes coaxial cables, copper wire and fiber optics, including the wires that comprise bus 102. Transmission media can also take the form of acoustic or light waves, such as those generated during radio-wave and infra-red data communications.

[0037] Common forms of computer-readable media include, for example, a floppy disk, a flexible disk, hard disk, magnetic tape, or any other magnetic medium, a CD-ROM, any other optical medium, punchcards, papertape, any other physical medium with patterns of holes, a RAM, a PROM, and EPROM, a FLASH-EPROM, any other memory chip or cartridge, a carrier wave as described hereinafter, or any other medium from which a computer can read.

[0038] Various forms of computer readable media may be involved in carrying one or more sequences of one or more instructions to processor 104 for execution. For example, the instructions may initially be carried on a magnetic disk of a remote computer. The remote computer can load the instructions into its dynamic memory and send the instructions over a telephone line using a modem. A modem local to computer system 100 can receive the data on the telephone line and use an infra-red transmitter to convert the data to an infra-red signal. An infra-red detector can receive the data carried in the infra-red signal and appropriate circuitry can place the data on bus 102. Bus 102 carries the data to main memory 106, from which processor 104 retrieves and executes the instructions. The instructions received by main memory 106 may optionally be stored on storage device 110 either before or after execution by processor 104.

[0039] Computer system 100 also includes a communication interface 118 coupled to bus 102. Communication interface 118 provides a two-way data communication coupling to a network link 120 that is connected to a local network 122. For example, communication interface 118 may be an integrated services digital network (ISDN) card or a modem to provide a data communication connection to a corresponding type of telephone line. As another example, communication interface 118 may be a local area network (LAN) card to provide a data communication connection to a compatible LAN. Wireless links may also be implemented. In any such implementation, communication interface 118 sends and receives electrical, electromagnetic or optical signals that carry digital data streams representing various types of information.

[0040] Network link 120 typically provides data communication through one or more networks to other data devices. For example, network link 120 may provide a connection through local network 122 to a host computer 124 or to data equipment operated by an Internet Service Provider (ISP) 126. ISP 126 in turn provides data communication services through the world wide packet data communication network now commonly referred to as the “Internet” 128. Local network 122 and Internet 128 both use electrical, electromagnetic or optical signals that carry digital data streams. The signals through the various networks and the signals on network link 120 and through communication interface 118, which carry the digital data to and from computer system 100, are exemplary forms of carrier waves transporting the information.

[0041] Computer system 100 can send messages and receive data, including program code, through the network(s), network link 120 and communication interface 118. In the Internet example, a server 130 might transmit a requested code for an application program through Internet 128, ISP 126, local network 122 and communication interface 118. In accordance with the invention, one such downloaded application provides for triggers as described herein.

[0042] The received code may be executed by processor 104 as it is received, and/or stored in storage device 110, or other non-volatile storage for later execution. In this manner, computer system 100 may obtain application code in the form of a carrier wave.

[0043] Multi-processing computer systems are systems that include multiple processing units that are able to execute instructions in parallel relative to each other. To take advantage of parallel processing capabilities, different aspects of a task may be assigned to different processing units. A multi-processing computer system may consist of one or more computers like the computer 100 and host 124 in data communication over one or more network links 120, and/or a single machine that has multiple processors.

[0044] Multiprocessing systems typically shuttle data between the main memory available to the computer system and the various processors on the system. FIG. 2 represents multiple processes 201-204, etc., running on a multi-processing computer system 200 on which total available main memory 280 is apportioned to the processes 201-204, etc.

[0045] In many multiprocessing systems, a relatively small portion of volatile memory, called a private cache, is closely associated with a single process. For example, in FIG. 2, private caches 221-224 are associated with processes 201-204, respectively. Information stored in a given private cache is the most efficiently accessed information for the process associated with that private cache. For example, the information in private cache 221 is the most efficient information for the process 201 to use. Information shared by several processes, or less frequently used, or both, is typically stored in a shared cache 290 in volatile memory. Even less frequently used information is not maintained in volatile memory, but is only loaded into volatile memory on an “as needed” basis from slower, non-volatile memory devices like disks.

[0046] A database typically includes one or more logical structures for arrangement of the data and processes to operate on those structures. For example, the logical structures of a typical relational database system include the database which comprises one or more related database objects arranged into one or more schemas. A schema is a collection of database objects that are available to a user. Schema objects include such structures as tables, views, stored procedures, and database links. Tables hold all of the user-accessible data arranged in rows and columns. A view is a custom presentation of the data in one or more tables. A stored procedure is a set of SQL and PL/SQL statements grouped together as an executable unit to perform a specific task. A database link describes a path from one database to another in a distributed database.

[0047] In general, a database management system includes one or more database servers that manage one or more databases. Each database server makes available a set of processes to provide the functions for database creation, maintenance and use, as needed. A database user uses tools provided with the database management system, or sends commands to the database server using an application programs consisting of one or more user processes, or both. Both the tools and the database applications call upon the database server processes. The database management system may also provide system level processes that operate on more than one database. Such system level processes include, for example an enterprise manager that provides a graphical user interface to illustrate the number and state of database instances running on a computer system.

[0048] As used herein, the term “process” refers to a mechanism that can execute a series of steps to complete a unit of activity. A process can be the result of a single SQL statement or a complex program written in a high level procedural programming language. The scope of a process refers to the largest database system structure on which the process operates. A typical database system includes processes that have a table scope, a schema scope, a database scope and a system scope.

[0049] For the various processes to properly use the data in the database management system, information is needed about the structures in which the data are arranged, including information about the relationships between the structures. Such information is called metadata. Thus, information about the system is called system metadata, information about a database is called database metadata, information about a user is called user metadata, information about a table is called table metadata, and information about the columns is called column metadata. These sets of metadata are typically stored in association with the data in the database on non-volatile memory. The portion of the database that stores metadata about the database and its schema, tables and columns is frequently referred to as the “data dictionary” of the database.

[0050] According to an embodiment of the present invention, when defining a trigger, the user is presented with controls that allow the user to select the event that will fire the trigger from a set of selectable events. In the preferred embodiment, the selectable events include non-DML operations.

[0051] The set of selectable events vary with the scope of a trigger. For example, for triggers having a database scope, the selectable events include STARTUP, SHUTDOWN, LOGON, LOGOFF, ERROR, CREATE, ALTER, DROP, INSERT, UPDATE, DELETE. For triggers having a schema scope, the selectable events include LOGON, LOGOFF, ERROR, CREATE, ALTER, DROP, INSERT, UPDATE, DELETE, but not STARTUP or SHUTDOWN.

[0052] For triggers having a system scope, the selectable events are CALL OPSYS, CALL OEM, STARTUP, SHUTDOWN, LOGON, LOGOFF, ERROR, CREATE, ALTER, DROP, INSERT, UPDATE, DELETE, where the first two events represent a call to the operating system, and a call to the Oracle Enterprise Manager, respectively, which are not in the database level selectable events.

[0053] For triggers having a row scope, the selectable events are ERROR, SELECT, INSERT, UPDATE, DELETE. Note that both DML and non DML operations are among the selectable events. Note that both table level operations and operations with other scopes are among the selectable events.

[0054] The specific scopes, and their corresponding list of selectable events, given above are merely exemplary. The actual set of selectable events for which triggers may be defined, and how those events are categorized into scopes, may vary from implementation to implementation. The present invention is not limited to any particular set of scopes or selectable events.

[0055] FIG. 3 is a flowchart depicting the method 300 that enables a user to define a trigger according to an embodiment of the present invention. The user starts a process, such as a database management tool, to create or alter a trigger, in step 302. The user is prompted to specify the scope of the trigger, such as system level, database level, schema level, table level or row level, in step 304. Significantly, step 304 is unnecessary in conventional trigger definition techniques because the scope of all triggers is always the table level.

[0056] In step 306, the user is then prompted to chose one of the selectable events for triggers at that level. The choice of selectable events in step 306 is much more extensive than in conventional database systems. In step 308, the user is prompted to provide the statements, such as SQL statements, that specify the conditions that must be satisfied before the trigger action is executed. In step 310, the user provides a procedure as an action to execute if the conditions of the trigger are satisfied.

[0057] In step 312, a trigger map associated with the scope is created or altered. In step 314, the trigger map of trigger flags for that scope is stored with the metadata for that scope, along with the conditions and actions. For example, in the preferred embodiment, the trigger map for the schema scope is stored in the data dictionary with the schema metadata. Trigger maps will be described in more detail below.

[0058] In general, the trigger map for a given scope consists of a set of flags, each flag corresponding to one of the selectable events in that scope. The flag is set to “on” if that event has a trigger defined for that scope. FIG. 4 illustrates an example of trigger flags for a portion of a database scope trigger map. In this example, each flag 431-437, etc., is a binary bit with a “1” indicating that a trigger has been defined and a “0” indicating a trigger has not been defined. The position of the flag indicates the corresponding event, as shown by labels 441-447, etc. For example, the first flag 431 contains a “0” indicating the first event, STARTUP, label 341, does not have a trigger defined. The fifth flag 435 contains a “1” indicating the fifth event, ERROR, label 445, does have a trigger defined.

[0059] FIG. 5 is a flowchart indicating how trigger maps are used when a database system process is executing at run time. The process is started by a user in step 532. In step 534, the process accesses the metadata for the scope of the process and in step 536 loads the trigger flags into the private cache for the process. For example, if the process 201 started by user Scott is a database level process for database FOO, then the process 201 accesses the data dictionary for the database FOO and loads the database FOO scope flags into its private cache 221. Since user Scott has initiated the process, the process is limited by the same privileges as would be Scott. The Scott schema defines the limits and privileges of the user Scott. Thus, in step 538 the process accesses the metadata for the scope of the Scott schema, and in step 540, the process loads the trigger flags for the Scott schema into the private cache for the process. The metadata for the Scott schema are stored in the data dictionary. The process continues in step 542. Note that only the flags are loaded into private cache, the trigger conditions and actions are not yet loaded from the metadata.

[0060] In the above example, the trigger flags for two different scopes are loaded, the database scope and the schema scope. This is because, in this example, there is a hierarchical relationship between the scope of the schema and the scope of the database. In particular, each database contains one or more schemas, one schema for each user of the database.

[0061] In general, scopes may be related by a hierarchy. One example hierarchy typically found among database objects, is a multiple parent hierarchy, in which a child scope may have more than one parent scope. A scope without a parent is the top parent scope in the hierarchy. The parent also can have many children. Each succeeding generation of scopes from the top parent scope constitutes a different level of scopes in the hierarchy. A branch is a group of scopes in the hierarchy that can be connected from the lowest child in the group to the highest parent in the group by a single line traversing between each pair of levels.

[0062] In general, for scopes related by a hierarchy, the trigger flags are loaded for all scopes at and above the level of scope in which the process is acting. In one embodiment only flags for higher level scopes on the same branch need be loaded. In the above example, the process operates at the schema level for Scott. Thus, trigger flags are loaded for schema and database scopes. If a system scope were established, it would be the top parent scope, and its flags would also be loaded.

[0063] FIG. 6 is a flow diagram which shows how the triggers are fired. At this point any process that is running, in step 542, has the trigger maps of one or more scopes residing in its private cache. For example, the trigger flags for the database FOO and the schema Scott are resident in the private cache 221 of the database FOO process 201. When any of the selectable events occurs during the process, as in step 612, the process checks the trigger maps in the private cache in step 614, to determine if the flag for this event is “on” in step 616. If the flag for this event is not “on,” no trigger is defined for the event, and therefore the process continues normally at step 542 without firing a trigger.

[0064] It is important to note that, if the trigger is not fired, very little processing resources have been consumed. The limited number of defined events means the trigger map requires very few bits of storage. The location of the trigger map in private cache makes checks extremely efficient. In general, the trigger maps are loaded for all scopes of the process and larger scopes. This way a system scope set of triggers will be implemented by all processes on all databases on the system, as would be expected. Because the trigger maps are so small, this is not a heavy burden on the process or its private cache.

[0065] If the flag for this event is indeed on, a defined trigger is applicable, and the applicable trigger is fired at step 630. If control is returned to the process after the trigger is fired, the process continues in step 542.

[0066] FIG. 7 is a flow diagram showing details of firing the trigger in step 630. The trigger firing begins in step 702. In step 704, the firing mechanism checks to determine whether the applicable trigger is already in shared cache 290. If the trigger conditions and actions are not yet in shared cache 290, then, at least the trigger conditions are loaded into shared cache 290 from the metadata, and the number of triggers in shared cache is incremented in step 706. For example, if the applicable trigger's conditions and actions are not in the shared cache 290 already, the trigger's conditions and actions are loaded into the shared cache 290 from the data dictionary. In the preferred embodiment, the trigger is not loaded into shared cache until the first time a trigger is fired. This way, system resources are only consumed by the trigger conditions and actions if the trigger is fired. Consequently, hundreds of triggers may be defined without consuming substantial runtime system resources until absolutely necessary.

[0067] A sample structure for loading the trigger into shared cache 290 is illustrated in FIG. 8. For each trigger map of a given scope, a trigger specification area of memory 800 is set aside in the shared cache 290. This area stores the number 850 of triggers of that scope loaded into the shared cache 290. For each loaded trigger, the trigger type 801, 802 is stored, as is a region holding a block of code 811, 812 for the stored procedures of the conditions and actions.

[0068] For example, FIG. 8 shows that the number 850 of applicable triggers in shared cache 290 is “2.” In this example, a CREATE statement was the first event to be executed by the process 201 with an “on” flag in its trigger map, such as shown in FIG. 4. Since the CREATE flag is on, the CREATE type trigger is applicable and the CREATE type trigger is fired. Thus, the CREATE type trigger is stored into shared cache 290 at region 801 and the conditions and actions are loaded into shared cache 290 at location 811 as the first trigger, “Trigger 1,” of the database FOO scope process.

[0069] If several CREATE operations subsequently occur in process 201, no additional triggers need be loaded into shared cache. The needed type 801, and conditions and actions 811 are already there. In fact, if some other process with access to the same shared cache 290 (e.g. process 202) performs a CREATE operation on database FOO, that process also can find the necessary type 801 and conditions and actions 811 in the shared cache 290.

[0070] Similarly, in this example, an ERROR occurred during the process 201 before any other event whose flag is “on” in the trigger map shown in FIG. 4. Since the ERROR flag is “on,” the ERROR type trigger was applicable and the ERROR type trigger was fired. Thus the ERROR type trigger is stored in shared cache at location 802 and the conditions and actions are loaded into shared cache at region 812 as the second trigger, “Trigger 2,” of the database FOO scope process.

[0071] Referring again to FIG. 7, after the trigger conditions and actions are found in shared cache 290, the conditions are evaluated in step 708. When an event occurs, the event may have one or more attributes. For example, an error event has an error number as an attribute. Depending on the error number, the condition associated with the trigger may not be satisfied, and therefore the action associated with the trigger is not executed. As another example, an UPDATE event has as attributes the old values in each column of the row being updated and the new values in each column as a result of the update. Any of these attributes can be used in evaluating the conditions in step 708.

[0072] In step 710, it is determined whether the conditions of the trigger are satisfied. If the conditions of the trigger are not satisfied, the firing of the trigger ends in step 714. Processing control may be returned to the process which continues at step 542. If the conditions of the trigger are satisfied, the trigger actions are executed in step 712.

[0073] In another embodiment, further processing resources are conserved if the conditions and actions are separately loaded as needed. In this embodiment, when a trigger is fired and the trigger conditions and actions are not yet in shared cache 290, only the conditions are loaded into shared cache 290 at 811, 812 with the number of triggers 850 and the trigger type 801, 802. If the conditions are not satisfied in step 710, then the actions are not needed and are never loaded into shared cache 290. Only if the conditions are satisfied, in step 712 are the actions loaded into shared cache 290 at location 811, 812.

[0074] Further details on the operation and some additional advantages of the techniques described herein will be described next with the following examples.

[0075] Using one embodiment of the present invention, the large consumption of computational resources required for 1000 users to each set three triggers on a database table can be substantially reduced. As described in the background section for the conventional triggers, where 1000 users each set three triggers for a DELETE operation on a table, 3000 triggers were fired upon a DELETE operation to that table, and 3000 conditions had to be evaluated, each evaluation employing a 20,000 line procedure. Using the present invention, each DELETE event trigger can be defined for the schema, rather than for the table, and the table name can be used as a condition. Substantial computational resources can be saved, as explained below.

[0076] In this example, a schema scope trigger map is set up in the data dictionary for the schema of a user Scott. The selectable schema events in this example are LOGON, LOGOFF, ERROR, CREATE, ALTER, DROP, INSERT, UPDATE, DELETE in order, as in the embodiment described above. The Scott schema trigger map consists of the nine one bit flags “000000001” previously stored in the Scott schema in the data dictionary. When the user Scott logs onto the database, the Scott schema is employed, and when Scott starts process 201, the Scott schema trigger map is loaded from the Scott schema in the data dictionary into the private cache 221 of the process 201. When process 201 executes a DELETE operation, the Scott schema map in private cache 221 is checked, the DELETE flag is determined to be “on” and the DELETE Trigger is Applicable. The trigger is fired and the process 201 goes to shared cache 290 to find the DELETE type triggers in the Scott schema area. If none are there, the DELETE type triggers are loaded from the Scott schema in the data dictionary into the shared cache 290. In this example, three DELETE type triggers are found in the Scott schema portion of the data dictionary and loaded into the shared cache 290. Then the three conditions are evaluated and, if the conditions are satisfied, the actions are executed. If the DELETE type triggers are only intended for one particular table in the database, say an EMPLOYEE table, then the conditions include a test for the table name of the table being operated on by the delete operation. The table name is an event attribute of the DELETE event.

[0077] In this example, when Scott deletes a value from the table EMPLOYEE, only the three triggers defined by Scott are fired. The other 2997 triggers are not even fired, since they are defined for other schemas. Only three conditions then have to be evaluated using the 20,000 line procedure. Evaluating only three conditions, using the present techniques, rather than evaluating 3000 conditions, as in the conventional system, saves substantial computational resources.

[0078] In this example, when a user initiates a process, the schema scope trigger map loaded into private cache is not only the schema trigger map of the user, but also the schema level trigger map of the owner of the database object being acted upon. For example, when the user Scott initiates a process, the Scott schema trigger map is loaded into the private cache. Later, when the process attempts to perform an operation on the table EMPLOYEE, owned by Laurie, not only is the EMPLOYEE table trigger map, if any, loaded into private cache, but also the Laurie schema trigger map is loaded as well. In this way, Laurie can define one trigger that protects all her database objects. She need not copy those triggers into each table view and index that she owns.

[0079] According to an embodiment of the invention, a mechanism is provided that allows users to define two types of schema level triggers, where a different schema trigger map is used for each of the two types of schema level triggers. Specifically, a first set of schema level triggers may be defined for events that occur when the user associated with a selected schema initiates a process, and a second set of schema level triggers may be defined for events that occur when a database object owned by a selected schema is acted upon (by any user).

[0080] For example, Laurie can have two schema trigger maps (and associated triggers with conditions and actions). A first map corresponds to triggers for use by processes initiated by Laurie, and a second map corresponds to triggers for processes initiated by any users that act upon a database object owned by Laurie. Thus, in this embodiment, the “schema” scope is implemented as two separate and distinct scopes: one scope is a schema-actor scope the other scope is schema-owner scope.

[0081] In this example, a user wants to fire a trigger when the event is that a particular database statistic has exceeded a threshold value. For example, a database administrator wants to send an electronic mail message (email) to the administrator's mailbox when shared memory use exceeds 75% of the amount allocated for a database, the number of bytes in the data files of the database exceed a particular size, or more than 25 users are logged on.

[0082] This kind of statistical information may be maintained by the database system, for example, in dynamic performance tables. Database administrators can query these tables, create views on these tables, and grant access to those views to others by creating public synonyms.

[0083] In one embodiment, a mechanism is provided that allows users to create triggers associated with operations relating to the statistical information maintained by the database system. Such triggers are referred to herein as “statistics” triggers. The scope of statistics triggers is referred to as the “statistics scope”. A user may define a statistics trigger, for example, by selecting the scope of a trigger to be “statistics scope”, and selecting the event for the trigger to be the UPDATE event. Such a trigger would fire when the database system updates the dynamic performance tables that store the database statistics. The attributes of the statistics scope UPDATE event include the synonym name of the view, and the new values of particular statistics provided by the view.

[0084] In another embodiment, the above statistics scope trigger is combined with a table scope UPDATE trigger on a one row table. In this embodiment, a statistics scope threshold trigger is fired on an UPDATE event for statistics views. The actions of the threshold trigger update the one row table only if a particular statistic exceeds a given threshold. Thus every time there is a UPDATE of a statistics view, the threshold trigger fires. When the value finally exceeds a given threshold, then the one row table is updated. The UPDATE trigger on the one row table then fires. In this way cascading triggers create the effect of a trigger firing upon a particular statistic exceeding a given threshold.

[0085] For some applications it is useful to be able to limit access of a particular user to only given rows of a table. For example, a salesperson's access to a table of clients may be restricted to the clients of that particular salesperson. A particular user's access is controlled through views; that is, a user is given access to a view on the table, and the view is defined only for certain rows. However, each view requires database resources to define and maintain, and different views are needed in this example for each salesperson. It would be more efficient to control access to the data in the table on a row level. In this example, triggers are used to provide row-level access control, i.e., fine grained security.

[0086] Fine grained access control allows a database administrator to implement security policies with functions and then associate those functions with tables or views. The policy is implemented by adding a WHERE condition (a predicate) to the SQL statements received from a user. Additional details on the use of predicates to provide fine grained access are provided in the pending U.S. patent application Ser. No. 09/167,092, filed Oct. 5, 1998 “Database Fine-Grained Access Control” by Chon Hei Lei and Douglas James McMahon, hereby incorporated by reference in its entirety. Each database application can have its own application specific context. Predicates can be based on context values. For example, the WHERE condition can be one expression for a salesperson and a different expression for a staff member in human resources. Alternatively, the WHERE condition can depend on the salesperson's actual employee number. Users cannot arbitrarily change their context.

[0087] A database scope trigger on a LOGIN event can set the initial context for logged in users. For example, in the trigger action a user's employee number can be queried based on the user ID, and the returned value can be set as an “employee number” context value. Alternatively, the user's title can be queried, and the returned title, “salesperson,” set as a “job title” context value.

[0088] Triggers defined using the techniques described herein can be used in many other ways as well, too numerous to list. Additional examples include the following.

[0089] Probes are used to report where different procedures are running and collect this information into memory. At logoff, this information is lost. A database scope trigger may be defined to write this information to printer or disk upon a LOGOFF event.

[0090] Cascaded triggers are used to catch an unauthorized person attempting to log on as a valid user. One database scope trigger is set for each ERROR with a condition that tests whether the error attribute indicates a login error. If so, a table indicating user name, location and time is updated. A second trigger fires on the updating of that table with the condition that the number of entries is greater than a threshold. The action of this second trigger is some remedial action, such as notifying a database administrator of the attempted unauthorized entry.

[0091] A database scope CREATE trigger can be used to generate extra columns on each table, such as used by Trusted Oracle to monitor who is changing tables.

[0092] A system scope STARTUP trigger can have as an action to send e-mail to a system administrator that any database has come on line or that a particular database has come on line.

[0093] Selectable events are defined for events about which a group of subscribers want notification. Triggers are then defined at the appropriate scope, where the trigger action is sending publication of the event to the subscribers.

[0094] In the foregoing specification, the invention has been described with reference to specific embodiments thereof. It will, however, be evident that various modifications and changes may be made thereto without departing from the broader spirit and scope of the invention. The specification and drawings are, accordingly, to be regarded in an illustrative rather than a restrictive sense.