This action might not be possible to undo. Are you sure you want to continue?
Allocated memory for DB2; the main memory allocated to DB Manager to cahce table and index data pages as they are read from disk or modified. DB Manage decides when to bring data from disk into buffer pool. When old data is not being used, it can be written back out to disk.
Logical layer between physical tables w/data and the database; maps logical database design to physical storage. Two types of table spaces: • • (SMS) System Managed Space: OS file system allocates and manages the space where the table is stored (DMS) Database Managed Space: db manager controls storage space; special purpose file system.
Allocates storage for the table space; It is the physical storage. It can be directory name, device or a file name. All database and table data is assigned to table spaces. A single table space can span multiple containers, but each container can ONLY belong to one table space.
Container_0 Table Space Extent Pages
Is a unit of space within a container of a table space. DB Objects are stored in pages within DB2 which are grouped into allocation units.
Rows of table data are organized in page blocks. Four sizes exist (4K, 8K, 16K, 32K) In a page of table data , ~ 75 bytes are reserved for DB2, the remaining is used for user data. As you increase the page size, the following items also increase: • • • Columns in the table Maximum row length Maximum table size
Big Block Reads:
If several pages (extent) are retrieved in a single request, then big-block read occurs. If the rows in the pages are in the extent retrieved, then no physical I/O required.
Ability of DB Manager to read pages in advance pages being referenced by a query. Use I/O Servers to perform page reading.
As pages are read and modified, they accumulate. Page cleaner tasks write out modified pages to guarantee availability of buffer pool pages for use by read requests.
The table descriptor provides information about the table, particularly the data definition from the CREATE TABLE statement that created the object.
Catalog Table Space:
Catalog is where DB2 keeps all its metadata about database objects.
Temporary Table Spaces:
Space for intermediate tables as it waits to determine the final result set
Table descriptors for tables, views, and aliases; a descriptor stores information about a table, view, or alias in a condensed internal format. When an SQL statement references a table, it causes an insert of a table descriptor into the cache, so that subsequent SQL statements referencing that same table can use that descriptor and avoid reading from disk.
Package Cache: (see Package)
The package cache hit ratio tells you whether or not the package cache is being used effectively. If the hit ratio is high (more than 0.8), the cache is performing well. A smaller ratio may indicate that the package cache should be increased. The package and section information required for the execution of dynamic and static SQL statements are placed in the package cache as required. This information is required whenever a dynamic or static statement is being executed. The package cache exists at a database level. This means that agents with similar environments can share the benefits of another agent's work. For static SQL statements, this can mean avoiding catalog access.
In a hash join, one table (selected by the optimizer) is scanned and rows are copied into memory buffers drawn from the sort heap allocation. The memory buffers are divided into partitions based on a hash code computed from the columns of the join predicates. Rows of the other table involved in the join are matched to rows from the first table by comparing the hash code. If the hash codes match, the actual join predicate columns are compared. Consideration of the performance implications of coding your predicates in different ways
A join predicate is applied to identify the records that shall be joined. If the predicate evaluates to True, then the combined record occurs in the joined table; otherwise, it does not. The join predicate can be any predicate supported by SQL, for example in WHERE and ON clauses. A join is a relation composition. That is the fundamental operation in relational algebra
DPCs (Deferred Procedures Call):
Interrupts that run at a lower priority than standard interrupts.
User mode is a restricted processing mode designed for applications, environment subsystems, and integral subsystems.
Privileged is designed or O/S components and allows access to hardware & memory
May result from requesting data in a size that is too large to fit into a single I/O
Logical & Physical:
• • Logical Reads is the number of Logical I/O requests made by DB2 for the physical file (or table). Physical Reads is the actual number of Physical I/O operations performed to satisfy the Logical I/O requests.
The values of physical disk counters are sums of the values of the logical disks (or partitions) into which they are divided.
MDL (Memory Descriptor List) Read Hits:
Read requests to the file system cache that hit the cache; so it does not require disk accesses in order to provide memory access to the page.
Data Map Hits:
The percentage of data maps in the file system cache that could be resolved without having to retrieve a page from the disk, because the page was already in physical memory.
A logical grouping of memory that fulfills the needs of a particular component. For example, the utility heap memory is used by DB2 utilities such as backup, restore, and load.
Indexes provide quick access to data and can enforce uniqueness on the rows in the table.
An event that occurs when the value of a performance variable exceeds or falls below a user-defined threshold value. The action that occurs as a result of a threshold trigger can be: Logging information in an alert log file. Displaying information in an alert log window. Generating an audio alarm. Issuing a message window. Invoking a predefined command or program.
A database must have at least one buffer pool, and can have a number of buffer pools depending on the workload characteristics, database page sizes used.
Using the Hidden Buffer pools:
When the main buffer pools are configured too large, it is possible that they will not fit into the addressable memory space. (We will talk about addressable memory later.) That means DB2 cannot start the database, because a database must have at least one buffer pool. If the database is not started, you cannot connect to the database and change the buffer pool sizes. For this reason, DB2 pre-allocates these four small buffer pools. Should the main buffer pools fail to start, DB2 will start the database with the small buffer pools.
Sorting & Memory:
Sorting is required when no index satisfies the requested ordering of fetched rows, or the optimizer determines that a sort is less expensive than an index scan. There are two kinds of sorts: private sorts and shared sorts. • • Private sorts take place in an agent's private agent memory Shared sorts take place in the database's shared memory
The following formula calculates approximately how much memory the database shared memory set requires:
Database shared memory = (Main bufferpools + 4 hidden bufferpools + database heap + utility heap + locklist + package cache + catalog cache) + (number of estore pages * 100 bytes) + approx. 10% overhead
Agent Private Memory:
Each DB2 agent process needs to acquire memory to perform work. It will use memory to optimize, build and execute access plans on behalf of the application, to perform sorts, to record cursor information such as location and state, to gather statistics, etc. Agent private memory is allocated for a DB2 agent when the agent is assigned as the result of a connect request or a new SQL request in a parallel environment.
When an agent becomes idle,
it retains its agent private memory. This is designed to improve performance, because the agent will have its private memory ready when it is called again. If there are many idle agents and all of them retain their private memory, it is possible that the system runs out of memory. To avoid this, DB2 has a registry variable which limits the amount of memory each idle agent can retain. Example: All database requests are serviced by DB2 agents or subagents. For example, when an application connects to a database, a DB2 agent is assigned to it. When the application issues any database requests, such as a SQL query, the agent goes out and performs all the tasks that are required to complete the query - It works on behalf of the application. Each agent, or subagent, is considered a DB2 process, and it acquires a certain amount of memory to perform work. This memory is referred to as the agent private memory - It cannot be shared with any other agents.
Boundaries of Private & Shared Memory:
In addition to its own private memory, in which the agent performs its "private" tasks such as private sorts, using the sortheap; the agent also requires database level resources such as the buffer pools, the locklist and the log buffers. These resources are found within the database shared memory. The way DB2 works is that everything within the database shared memory is shared by all DB2 agents or subagents connected to the same database. Therefore this memory set is called shared memory, as opposed to private memory. Example: For example, agent x connecting to database A uses the resources within the database shared memory of database A. Now a second agent, Agent y, also connects to database A. Agent y will share the
database memory of database A with agent x. (Of course, both agent x and y have their own agent private memory, which is not shared.)
What is a package?
Basically, it’s a database object contained with optimized SQL. Each SQL statement must go through the DB2 optimizer before it can be executed. The optimizer generates a data access plan (which is used to locate the data when a query is executed), and the access plan is stored in a package. The package itself is stored in the system catalog if the SQL statement is a static statement coded in an application, or in the package cache, if the SQL statement is a dynamic statement.
System Catalog Optimizer Package Data Access Plan
You can view the access plan for one or more SQL statements with Explain. It's possible to run an embedded SQL application using only the package. When you precompile the application, a package is created containing access plans for the SQL statements coded in the application. That package is stored in the database that was used to precompile the application. You can also precompile an application and have the access plan information stored in an external file, which can then be bound to any database you want to use the application with or the package can be stored in a bind file. The binding process generates the package and stores it in the database specified — this is referred to a deferred binding.) A program module that contains embedded dynamic SQL has associated package and sections but the sections act only as placeholders for SQL statements that are dynamically prepared.
Package Section or Section:
A section is a compiled form of a SQL statement. Every section corresponds to one statement. An optimized access plan will be stored in a section.
Dynamic SQL allows a programmer or end user to create a SQL statement's specifics at runtime and pass the statement to the database. The database then returns data into the program variables, which are bound at SQL runtime.
A static SQL statement is written and not meant to be changed. Although static SQL statements can be stored as files ready to be executed later or as stored procedures in the database, static SQL does not quite offer the flexibility that is allowed with dynamic SQL. THINK: Stored Procedures The problem with static SQL is that even though numerous queries may be available to the end user, there is a good chance that none of these "canned" queries will satisfy the users' needs on every occasion. Comparing Dynamic vs. Static SQL Statements1
An application using dynamic SQL has a higher start-up (or initial) cost per SQL statement due to the need to compile the SQL statements before using them. Once compiled, the execution time for dynamic SQL compared to static SQL should be equivalent and, in some cases, faster due to better access plans being chosen by the optimizer.
Each time a dynamic statement is executed, the initial compilation cost becomes less of a factor. If multiple users are running the same dynamic application with the same statements, only the first application to issue the statement realizes the cost of statement compilation.
Differences between Static & Dynamic:
Dynamic SQL is often used by ad hoc query tools, which allow a SQL statement to be created on-the-fly by a user to satisfy the particular query requirements for that particular situation. After the statement is customized according to the user's needs, the statement is sent to the database, checked for syntax errors and privileges required to execute the statement, and compiled in the database where the statement is carried out by the database server. Although dynamic SQL provides more flexibility for the end user's query needs, the performance may not compare to that of a stored procedure whose code has already been analyzed by the SQL optimizer.
A call-level interface (CLI):
CLI is used to embed SQL code in a host program, such as ANSI C. It is one of the methods that allows a programmer to embed SQL in different procedural programming languages. When using a call-level interface, you simply pass the text of a SQL statement into a variable using the rules of the host programming language. You can execute the SQL statement in the host program through the use of the variable into which you passed the SQL text.
Direct SQL is where a SQL statement is executed from some form of an interactive terminal. The SQL results are returned directly to the terminal that issued the statement. Most of this book has focused on direct SQL. Direct SQL is also referred to as interactive invocation or direct invocation.
Embedded SQL is SQL code used within other programs, such as Pascal, FORTRAN, COBOL, and C. SQL code is actually embedded in a host programming language, as discussed previously, with a call-level interface. Embedded SQL statements in host programming language codes are commonly preceded by EXEC SQL and terminated by a semicolon in many cases. Other termination characters include END-EXEC and the right parenthesis.
condition under which a transaction cannot proceed because it is dependent |on exclusive resources that are locked by another transaction, which in turn |is dependent on exclusive resources that are in use by the original transaction
Fenced vs. Not Fenced Resources:
Fenced resource executes in a separate process from the database agent. Not fenced resource executes in the same database process as the database agent.
File Buffer Cache
System buffer cache hit
Buffer Cache / Hit Ratio / Read & Write Request
On a file read request, the file system first attempts to read the requested data from the buffer cache. If the data is not already present in the buffer cache, it is read from disk and cached in the buffer cache. Similarly, writes to a file are cached so that future reads can be satisfied without necessitating a disk access, and to reduce the frequency of disk writes. The use of a file system buffer cache can be extremely effective when the cache hit rate is high. It also enables the use of sequential read-ahead and write-behind policies to reduce the frequency of physical disk I/O’s. Another benefit is in making file writes asynchronous, since the application can continue execution without waiting for the disk write to complete. Figure 3 shows the sequence of actions for a write request under cached I/O. Note: While the file system buffer cache improves I/O performance, it also consumes a significant portion of system memory.
Dynamic SQL Processing
Global Package Cache Dynamic SQL SQL statement is assembled and completed @ runtime Executable Access Plan
Compiler invoked if executable exists. If executable does not exist, compiler not invoked.
SQL Monitoring Diagram
System Catalog Tables Package: SQL executable form (Access Plan)
Access Paths How to get the data What is my strategy? Index Usage Sort Methods Lock Semantics Join Methods
• • • •
Data that needs to be defined in some sequence or order DB2 attempts to perform the ordering via index usage. If an index can’t be used, the sort will occur. A sort involves: • Sort Phase o Overflowed – data sorted cannot fit entirely on the sort heap it overflows into temporary database tables o Non-Overflowed – fits and performs better
Sorted Data Temp Tables
Return of the results of the sort phase o Piped – if sorted information can return directly w/o requiring a temp table to store a final, sorted list of data. This is better! o Non-piped – if results require a temp table to be returned
Figure: Non-Piped returns
See SORTHEAP database configuration parameter
Block of memory allocated each time a sort is performed.
A set of SQL statements (series of instructions) that execute in a single operation. A transaction is completed when either an explicit COMMIT or ROLLBACK is encountered.
The total number of commits initiated by the database manager
DB2 Locking mechanism attempts to avoid resource conflicts yet still provide full data integrity. Locks are released when resource is no longer required at the end of the transaction.
The number of locks that have been escalated from several row locks to table locks.
As transactions are processed, they are tracked within the log files. DB2 tracks all statements that are issued within its logs. DB2 Uses write ahead logging to ensure that changes to the database will be applied. Changes are written to the logs first then later applied to the physical database tables.
.NET and DB2 Model
This action might not be possible to undo. Are you sure you want to continue?
We've moved you to where you read on your other device.
Get the full title to continue reading from where you left off, or restart the preview.