Materialized views can be created either through the CREATE MATERIALIZED VIEW statement or the Oracle Enterprise Manager (OEM). The CREATE MATERIALIZED VIEW statement can also be used for populating the materialized views. A materialized view can be derived from an existing user-defined materialized view. In this case, the ON PREBUILT TABLE clause of the CREATE MATERIALIZED VIEW is used. However, if a user-defined materialized view does not exist, a materialized view can be populated by using either the BUILD IMMEDIATE or BUILD DEFERRED clause of the CREATE MATERIALIZED VIEW statement, depending upon whether the materialized view has to be populated immediately or at some later time, respectively. However, the BUILD DEFERRED materialized view cannot be used until a refresh is performed on it. As soon as the first refresh is performed on the BUILD DEFERRED materialized view, it is enabled, provided the ENABLE QUERY REWRITE clause is specified.

Materialized views are used for query rewrites in expensive data warehouse environments, where the queries are complicated and involve multiple joins. However, materialized views cannot use the query rewrite feature by themselves unless the QUERY_REWRITE_ENABLED initialization parameter is set to TRUE and the ENABLE QUERY REWRITE clause is specified at the time of creation of the materialized view that has to be made available for query rewrites. If the above clause was not specified, or the DISABLE QUERY REWRITE clause was used instead at the time of creation of the materialized view, then the query rewrite feature for the materialized view can be enabled using the ALTER MATERIALIZED VIEW statement.

Materialized views are refreshed to synchronize the data in the master site of the materialized view and the materialized view itself. Materialized views can be refreshed one at a time or in bulk by using refresh groups. Materialized views can be refreshed either on demand (the ON DEMAND mode of refreshing) or each time a transaction that brought some changes in the base tables of the materialized view, commits (the ON COMMIT mode of refreshing). The ON DEMAND mode has two modes under it – the manual complete mode and the manual force mode. The manual complete mode refreshes the underlying materialized view by recalculating the defining query of the associated materialized view. Manual force mode attempts to perform a fast refresh of the materialized view. If it cannot perform a fast refresh, it does a complete refresh instead. A user can also specify which type of refresh is to be performed on the materialized view. The following refresh options are available:

• Complete
• Fast
• Force
• Never

Complete – In this case, the materialized view is refreshed by executing the defining query of the materialized view. This replaces the data in the materialized view by the result set of the query. If a complete refresh is performed on the master materialized view, then a complete refresh should be performed on each materialized view associated with the above master view. If this is not done, then Oracle returns an error.

Fast – In this case, the materialized view logs, a SQL*Loader direct path, or a partition maintenance operation are used to update the rows that have changed since the last refresh operation. Hence, this refreshing option is incremental rather than total.

Force – In this case, the first attempt to refresh a materialized view is made through a fast refresh. However, if this refresh option fails, then a complete refresh is performed on the materialized view.

Never – In this case, the specified materialized view is never refreshed by Oracle.

There are three components of the frequency to refresh the materialized views, which are as follows:

1. Build type (immediate/deferred)
2. Refresh options (fast/force)
3. Frequency (manual/on commit)

The three types of materialized views as follows:

Read only

• It cannot be updated.
• Complex materialized views support the read only component of the frequency.

Updateable

• It can be updated even when disconnected from the master site.
• It is refreshed on demand.
• It consumes fewer resources.
• It requires Advanced Replication option to be installed.

Writeable

• It is created with the for update clause.
• All the changes are lost when the view is refreshed.
• It requires Advanced Replication option to be installed.

A resource consumer group is a logical grouping of user sessions on the basis of the resource requirements of each user session. Hence, there can be more than one resource consumer group with each having different resource requirements. Every user session can only belong to a single resource consumer group at an instance. At times, the resource requirement of a session is not met by the resource consumer group to which it belongs. In such cases, the session can automatically switch to a different resource consumer group depending on administrator settings.

• Download free practice test for ocp-dba10g OCP DBA 10g exam.
• Download free practice test for Oracle OCP DBA 9i exam.
• Download practice question and study guide for ocm-10g for exam.
• Pass RAC Certified Expert 10g in first attampt.
• Get certified in first attempt download 1Z0-033 - Oracle9i DB: Performance Tuning simulation.
• Click here to download 1Z0-043 test study guide and practice question.
• Download practice question and study guide for 1Z0-045 for exam.
• Become Oracle OCP: Oracle Database 11g: Administration II certified.

Latches are data structures used for protecting memory structures that are needed for a short period of time, e.g., the least recently used (LRU) list. Request for latches are not queued for execution. Following are the two modes of latches:

• Willing-to-wait mode
• Immediate mode

If a process requests a latch in the willing-to-wait mode and the latch is not immediately available, then the process waits for the latch. However, if the process requests for a latch in the immediate mode and the latch is not immediately available, then the process continues with its processing.

The objective of this test is to test the analytical skills of the user as a Database Administrator, using Oracle9i as the back-end tool. The test requires a thorough grasp of database concepts, familiarity with the GUI tools, scripts, views, and packages available in Oracle9i. This includes being able to identify the potential tuning areas with the help of the available tools and packages. The user should be able to analyze which tool or package should be used in which case. This requires a lot of practice with the tools and packages. The user should also be able to use PL/SQL-based queries for identifying potential bottlenecks in the performance of the system.

The user of this PrepKit is required to first brush up his fundamental knowledge in database. This includes getting acquainted with the key terms that appear in the test structure. He should know the function of each and every term that appears in the test structure of this test. For this purpose, this PrepKit comes in handy, as it explains in detail, the functionality of the key terms used in this test. The facts made for this PrepKit are so made that they not only mould the basic concepts, but also help in further solving the tricky questions that are asked in the test. The user of this PrepKit can always find the relevant details on a topic by following the links that are given at suitable points in the questionnaire prepared for this test. The questions are also prepared in a manner that they are tougher than those asked in the real test. This would help the user of this PrepKit to take the test with ease and confidence. This is done keeping in mind that if you have to hit the bulls eye, you’ll have to aim a bit higher.

The questions asked in this PrepKit are mostly scenario-based, which will present to the user of this PrepKit with the problems faced by a database administrator in the real world.

The user is urged to take the diagnostic tests only after clearing his fundamentals and in no case before that. This will enable him to test the depth of his fundamentals and get an idea about the types of questions asked in the test.

After clearing his basics, the user should try to get familiar with the tools and packages available in Oracle9i and try to resolve the issues using them. He should then switch onto using the query-based approach, using PL/SQL statements, for identifying and resolving the tuning issues. Although the queries are not a frequent part of the real test, this will enable a user to solve such questions with confidence as this part is the least prepared by most of the candidates who take this test. Also, queries form an integral part of an administrator’s arsenal, and therefore, brushing up his skills with queries will help him in his future prospect as a database administrator of a company.

Although this PrepKit has been prepared as per the latest requirements of the test, the user is yet urged to check the requirements of the test, well in advance, before taking the test.

ONLINE is an option of the ALTER INDEX REBUILD statement, which is used to minimize locking contentions that may arise at the time of rebuilding an index. Locking contentions generally arise when several operations are being simultaneously performed with the index rebuilding operation, on a table corresponding to the index.

An active session pool is a feature that allows a user to control the maximum number of active sessions permissible within a resource consumer group. As more active sessions are created within a resource consumer group, the resource consumption increases accordingly. This may lead to a situation where a single resource consumer group is engaging the entire available resources, whereas other groups are starving. To avoid this situation, the active session pool queues the active sessions that are created beyond the permissible limit, without actually executing them. A queued active session is executed only after an existing active session ends. The active session pool follows the first-in-first-out queuing principle. There is only one active session pool for each resource consumer group.

Direct path loading is a method of data loading where the direct path application program interface (API) passes the data to be loaded to the load engine on the server. The load engine builds a column array from the data. It then uses the array structure to format data blocks and build index keys. The data blocks so formatted are written directly to the database. In direct path loading, data conversion occurs on the client side rather than on the server side. Direct path loading is generally faster than conventional loading because of the following reasons:

• Contention with other users is minimized because the processes perform their own I/O instead of using the buffer cache.
• Direct path loading employs multiblock asynchronous I/O for writing to the datafiles.
• Partial blocks are not employed by direct path loading. Hence, there is no overhead of finding them.

Direct path loading is generally used when the data to be loaded is quite large or the data is to be loaded in parallel for enhanced performance. Integrity constraints are employed in direct path loading, e.g., the NOT NULL constraint. Integrity constraints depending upon other rows or tables, e.g., the referential constraint, are disabled before the direct path loading and are re-enabled afterwards.

Materialized views can be created either through the CREATE MATERIALIZED VIEW statement or the Oracle Enterprise Manager (OEM). The CREATE MATERIALIZED VIEW statement can also be used for populating the materialized views. A materialized view can be derived from an existing user-defined materialized view. In this case, the ON PREBUILT TABLE clause of the CREATE MATERIALIZED VIEW is used. However, if a user-defined materialized view does not exist, a materialized view can be populated by using either the BUILD IMMEDIATE or BUILD DEFERRED clause of the CREATE MATERIALIZED VIEW statement, depending upon whether the materialized view has to be populated immediately or at some later time, respectively. However, the BUILD DEFERRED materialized view cannot be used until a refresh is performed on it. As soon as the first refresh is performed on the BUILD DEFERRED materialized view, it is enabled, provided the ENABLE QUERY REWRITE clause is specified.

Materialized views are used for query rewrites in expensive data warehouse environments, where the queries are complicated and involve multiple joins. However, materialized views cannot use the query rewrite feature by themselves unless the QUERY_REWRITE_ENABLED initialization parameter is set to TRUE and the ENABLE QUERY REWRITE clause is specified at the time of creation of the materialized view that has to be made available for query rewrites. If the above clause was not specified, or the DISABLE QUERY REWRITE clause was used instead at the time of creation of the materialized view, then the query rewrite feature for the materialized view can be enabled using the ALTER MATERIALIZED VIEW statement.

Materialized views are refreshed to synchronize the data in the master site of the materialized view and the materialized view itself. Materialized views can be refreshed one at a time or in bulk by using refresh groups. Materialized views can be refreshed either on demand (the ON DEMAND mode of refreshing) or each time a transaction that brought some changes in the base tables of the materialized view, commits (the ON COMMIT mode of refreshing). The ON DEMAND mode has two modes under it – the manual complete mode and the manual force mode. The manual complete mode refreshes the underlying materialized view by recalculating the defining query of the associated materialized view. Manual force mode attempts to perform a fast refresh of the materialized view. If it cannot perform a fast refresh, it does a complete refresh instead. A user can also specify which type of refresh is to be performed on the materialized view. The following refresh options are available:

• Complete
• Fast
• Force
• Never

Complete – In this case, the materialized view is refreshed by executing the defining query of the materialized view. This replaces the data in the materialized view by the result set of the query. If a complete refresh is performed on the master materialized view, then a complete refresh should be performed on each materialized view associated with the above master view. If this is not done, then Oracle returns an error.

Fast – In this case, the materialized view logs, a SQL*Loader direct path, or a partition maintenance operation are used to update the rows that have changed since the last refresh operation. Hence, this refreshing option is incremental rather than total.

Force – In this case, the first attempt to refresh a materialized view is made through a fast refresh. However, if this refresh option fails, then a complete refresh is performed on the materialized view.

Never – In this case, the specified materialized view is never refreshed by Oracle.

There are three components of the frequency to refresh the materialized views, which are as follows:

1. Build type (immediate/deferred)
2. Refresh options (fast/force)
3. Frequency (manual/on commit)

The three types of materialized views as follows:

Read only

• It cannot be updated.
• Complex materialized views support the read only component of the frequency.

Updateable

• It can be updated even when disconnected from the master site.
• It is refreshed on demand.
• It consumes fewer resources.
• It requires Advanced Replication option to be installed.

Writeable

• It is created with the for update clause.
• All the changes are lost when the view is refreshed.
• It requires Advanced Replication option to be installed.

The Database Resource Manager (DRM) is a tool, which handles the resource allocation issues in a more efficient way than can probably be done by the operating system itself. Such issues include equal distribution of resources by the operating system to every active process, inability of the operating system to prioritize the tasks, and inability of the operating system to manage database-specific resources. This tool has been provided with all versions after Oracle7i. Before the introduction of this feature, resource management was only possible through the use of profiles.

Some of the tasks that can be performed by the DRM are as follows:

• Creating resource consumer groups and limiting the number of resources on each such group (Every user application is attached with a resource consumer group, hence each application has an upper limit on the number of resources that can be allocated to it).
• Distributing the processing time by allocating percentage of CPU time to each user application (The DRM does the processing distribution in a more effective way than the operating system by allocating the CPU time on a priority basis).
• Placing an upper limit on the number of user sessions that can be concurrently executed within a resource group.
• Controlling the degree of parallelism of every transaction that are carried out by users of a resource consumer group.
• Creating an active session pool that contains the maximum number of active sessions that are specified to be concurrently active within a group of users.
• Creating an undo pool that contains undo space for consumption by a group of users.

The DRM defines the following elements for database resource management:

• Resource consumer group – A resource consumer group is a logical grouping of user sessions on the basis of the resource requirements of each user session. Hence, there can be more than one resource consumer group with each having different resource requirements. Every user session can only belong to a single resource consumer group at an instance. At times, the resource requirement of a session is not met by the resource consumer group to which it belongs. In such cases, the session can automatically switch to a different resource consumer group depending on administrator settings.
• Resource plan – A resource plan directs the distribution of resources to the resource consumer groups. There can be more than one resource plan in a database. A plan within a plan is called a subplan. Subplans can also be created through the Database Resource Manager (DRM). Subplans increase the granularity of resource distribution by directing the number of resources that can be allocated to different users of an application within a resource consumer group.
• Resource allocation method – it is a policy used by the DRM for allocating a resource to a resource consumer group or resource plan. Although several resource allocation methods are available, a user can choose a specific method that best suites his requirements.
• Resource plan directive – A resource plan directive associates each resource consumer group to a specific resource plan, and directs the number of resources that can be allocated to each resource plan. It can be created using the CREATE_PLAN_DIRECTIVE procedure of the DBMS_RESOURCE_MANAGER package.

The DRM controls the distribution of resources among the various sessions by managing the execution schedule within the database. The DRM decides which session should be allowed to run next and for how long, in accordance with the plan directive.

The use of DRM reduces the performance overhead by not switching the processes as frequently as an operating system scheduler does. The DRM also executes fewer processes concurrently and never context switches a process that is holding a latch.

The DRM controls distribution of resources among consumer groups using plan-level resource allocation methods and directives. It handles the distribution of resources among sessions belonging to consumer groups through the consumer-group methods and directives.

The log writer (LGWR) is an Oracle background process. It is responsible for writing all the new entries that have been copied in the redo log buffer since the LGWR last wrote the entries to a redo log file. The log writer should write the entries of the redo log buffer fast enough, so that buffers are immediately available for new entries.

• Pass OCA DBA 9i in first attampt.
• Download free practice test for ocp-dba9i OCP DBA 9i exam.
• Download practice question and study guide for 1Z0-031 for exam.
• Download practice question and study guide for 1Z0-032 for exam.
• Download practice question and study guide for 1Z0-033 for exam.
• Download free practice test for 1Z0-040 OCA, 10g New Feature for Administrator exam.
• Download free practice test for 1Z0-042 Oracle Database 10g: Admin - I exam.
• Click here to get free 1Z0-043 Oracle Database 10g: Admin - II exam practice questions.
• Download free practice test for 1Z0-045 OCA, 10g New Feature for Oracle 8i Ocp exam.
• Click here to download 1Z0-047 test study guide and practice question.
• Click here to download 1Z0-052 test study guide and practice question.