DB2 resources are objects, system privileges, and utilities that must be controlled. DB2 resources include:
Each program that accesses DB2 data is associated with an application plan. Before the application plan is created, the program is precompiled. During this process, DB2 extracts SQL statements from the source code and places them in database request modules (DBRMs). When DB2 creates a plan, it binds the plan to the program. At this time, DB2 chooses the access paths for the SQL statements in the DBRMs and places this information in the DB2 directory.
When you bind a plan to a program, you can specify the owner of a plan. The owner of a plan must be authorized to perform every SQL statement in the plan. The owner’s authorization is checked during the bind. To use a plan, you must own the plan or be authorized to execute the plan. DB2 controls who can bind and who can execute the plan.
Buffer pools are areas in main storage that temporarily store pages of table spaces or indexes. Pages are units of storage that DB2 writes to or reads from DASD in one operation. Buffer pools improve performance by enabling the system to keep rows of a table in main storage and not wait to retrieve them from DASD. If the rows change, the buffer must be written back to the table space. Through SQL GRANT statements, DB2 governs whether use of a buffer pool is allowed or prevented. A user cannot own a buffer pool.
A collection is something you associate a package with when you bind it. It is a logical grouping of packages. Collections are not owned like resources that contain data such as databases, tables, and so on.
A database names a logical collection of tables, indexes, and table spaces. DB2 groups these objects into a database to let you control access to these objects as a single unit.
Examples of database privileges are the abilities to use DBADM, DBCTRL, or DBMAINT, to create a table space, to make an image copy of a database for backup, and to recover the database. See “What are DB2 Privileges and Authorities?” for a complete list of these privileges. A user can own a database.
Distinct types are user‑defined data types that are used to describe what input and output data looks like. You control what functions or procedures can use a distinct type to ensure that data is being processed correctly.
A function is similar to a subprogram. It can be used to manipulate data directly in an SQL request.
A JAVA archive file (JAR) is a file that contains a group of JAVA classes that can be used in JAVA applications. JAR files are available beginning with DB2 Version 7.1
A package enables you to break down large plans that take a long time to bind into separate entities. A package consists of one DBRM. You can bind one or more packages into a plan. Ownership of a package is similar to ownership of a plan (see above).
A role is very similar to a secondary authid. It is an alternate authid that can be assigned to a user when the user is accessing DB2 via a connection defined as a trusted context. Roles are available beginning with DB2 Version 9.1.
You associate functions, stored procedures, and distinct types with a schema. It is a logical grouping of these resources. Like collections, it cannot be owned.
You can use this object to create a sequence of numbers in table data according to the specifications in the sequence definition. Sequences are available beginning with DB2 Version 8.1.
A storage group is a set of DASD volumes that store table spaces. You can store parts of a database in different storage groups. Through SQL GRANT statements, DB2 governs whether use of a storage group is allowed or prevented. A user can own a storage group.
Stored procedures are compiled programs stored at a local or remote DB2 server. They can be invoked by a DB2 client with the SQL CALL statement.
System privileges and utilities represent resources that are not directly related to physical or logical entities such as databases, tables, or views. Rather they represent authorities to perform specific functions on a DB2 subsystem. Two examples of system privileges are SYSADM and SYSOPR. Other examples include the abilities to stop and start databases, run traces, and issue display commands. See “What are DB2 Privileges and Authorities?” for a complete list of system privileges and utilities. System privileges and utilities are not owned like resources that contain data such as databases, tables, and so on.
A table is the physical collection of rows and columns of data. All data in DB2 is presented in tables. Each table has the same ordered set of columns. Rows correspond to records in a hierarchical database while columns correspond to fields.
A view is the logical subset of a table’s data or the joining of data from multiple tables. Views look just like tables. They are presented to DB2 exactly the same as a table. They can contain some or all columns from one or more base tables. DB2 security administrators use views to authorize only those rows and columns in a table that a user can access. By granting access to only the view, you exclude a user from other rows and columns outside the view.
Six types of accesses to tables and views are possible, ranging from read‑only (SELECT) through various types of update requests (DELETE, INSERT, and so on). A user can own a table.
Table spaces are collections of tables. These are the physical data sets that reside on direct access storage devices (DASD) as VSAM linear data sets. Table spaces consist of pages, which are units of storage that DB2 writes to or reads from DASD in one operation. Through SQL GRANT statements, DB2 governs whether use of a table space is allowed or prevented. A user can own a table space.
A trusted context is a security entity defined in a DB2 subsystem that identifies a connection to the DB2 subsystem with specific attributes. When a connection is made with those attributes, other attributes defined in the trusted context will also apply to the connection. Trusted contexts are available beginning with DB2 Version 9.1.
|
Copyright © 2011 CA Technologies.
All rights reserved.
|
|