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 log switch occurs when the log writer (LGWR) finishes writing redo entries to the current online redo log file group and starts writing to the next online redo log file group. By default, a log switch occurs automatically when the current online redo log file group is full. A log switch can also be forced by executing the ALTER SYSTEM SWITCH LOGFILE; statement, regardless of whether or not the current online redo log file group is full.

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.

• Pass OCP DBA 10g in first attampt.
• Pass OCP DBA 9i in first attampt.
• Pass Oracle Certified Master 10g in first attampt.
• Become Oracle RAC Certified Expert 10g certified.
• Pass Oracle9i DB: Performance Tuning in first attampt.
• Pass Oracle Database 10g: Admin - II in first attampt.
• Download free practice test for 1Z0-045 OCA, 10g New Feature for Oracle 8i Ocp exam.
• Download free practice test for Oracle OCP: Oracle Database 11g: Administration II exam.

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.

Retrieving data using the SQL SELECT statement and using single row functions to customize the output

• /*…*/ and — are used to put comments in an Oracle program.
• The CREATE TABLE does not end immediately with a semicolon, and a column name cannot start with a numeric value. However, a numeric value can be used in between a column name.
• Name of a table cannot start with @ special character.
• Knowing about the GROUP BY clause.

Using sub queries and set operators to solve queries, as well as DDL statements to create and manage tables

• + (unary), – (unary), *, /, ||, =, !=, <, >, <=, >=, IS NULL, LIKE, BETWEEN, IN, NOT, AND, OR is the correct order of operators precedence.
• The ROLLBACK command is used to end the current transaction, and discard any changes made since the beginning of the transaction.

Managing objects with data dictionary views, schema objects and data in different time zones

• The length of a column can be increased even if it contains data. However, the data type of the column cannot be modified if it contains any data.
• The parameters used to maximize the space in Flash Recovery Area.
• User error failure refers to a database failure that results due to certain transactions on a database by a user.
• Flashback Query is used to view and repair historical data, and to view the contents of a table at any specific point in time.
• UNDO_RETENTION is a parameter in the init.ora initialization parameters file that specifies the time period in seconds for which a system retains undo data for committed transactions.
• Once the Flashback Versions Query is run to diagnose the erroneous transaction, the Flashback Transaction Query helps in the repair process of the transaction.
• The correct order of steps that will enable the flashback database are as follows:
  1. Put the database in Archive log mode.
  2. Set up a flash recovery area.
  3. Set the period for the flashback retention target.
  4. Shut down and mount the database.
  5. Enable flashback logging.
  6. Open the database.
• The overall utilization of the flash recovery area is displayed in megabytes.
• SQL statement can be used to flashback a database.
• Take the following steps to enable the Flashback Database:
  1. Ensure that the database is in Archive Log mode.
  2. Setup a flash recovery area.
  3. Set the duration for the flashback retention target.
  4. Shutdown the database.
  5. Mount the database.
  6. Enable flashback logging.
  7. Open the database.
• The dropped table can be recovered by using Flashback Drop.
• The flashback database is enabled only in Archive log mode, as it recovers the database to an earlier specific point of time.
• Flashback Database is used to reverse the changes made to a table.
• The Perform Recovery: Review screen is used to display the RMAN script that performs the Flashback Database recovery.
• The portlist.ini file is used to get all the port numbers of the HTTP listeners.
• RVWR is a background process, which is a part of the Flashback Database Architecture.
• LGWR is a background process that is a part of Flashback Database Architecture.
• SELECT oldest_flashback_scn FROM V; is used to retrieve an approximate system change number (SCN) to which a database can be flashed back.

• Become Oracle OCA DBA 10g certified.
• Download free practice test for Oracle OCA DBA 11g exam.
• Click here to get free oca-dba9i OCA DBA 9i exam practice questions.
• Click here to download oca-pl-sql test study guide and practice question.
• Download free practice test for Oracle OCP DBA 10g exam.
• Download free practice test for Oracle OCP DBA 11g exam.
• Pass OCP DBA 9i in first attampt.
• Download practice question and study guide for ocp-pl-sql for exam.
• Pass Oracle Certified Master 10g in first attampt.
• Download free practice test for oracle-pl-sql Oracle PL/SQL Developer exam.
• Best exam simulation Oracle performance-tuning-certified-expert-11g download free trial.
• Download practice question and study guide for rac-administrator-certified-experts-10g for exam.
• Download free practice test for sql-certified-expert-10g SQL Certified Expert 10g exam.
• Pass Oracle sql-certified-expert-11g - SQL Certified Expert 11g
• Download free practice test for 1Z0-047 Oracle Database SQL Expert exam.
• Click here to download 1Z0-051 test study guide and practice question.

The REMOTE_OS_AUTHENT parameter in the parameter file of the database specifies whether remote clients will be authenticated with the value of the OS_AUTHENT_PREFIX parameter or not. The type of the REMOTE_OS_AUTHENT parameter is Boolean, the default value is false, and the parameter class is static. The REMOTE_OS_AUTHENT parameter is case sensitive on some operating systems. The flow diagram below may help a user understand the role of the REMOTE_OS_AUTHENT parameter for a remote database:

• Get certified in first attempt download oca-dba10g - OCA DBA 10g simulation.
• Become Oracle OCA DBA 11g certified.
• Become Oracle OCA DBA 9i certified.
• Click here to download oca-pl-sql test study guide and practice question.
• Pass Oracle ocp-dba10g - OCP DBA 10g
• Pass Oracle ocp-dba-11g - OCP DBA 11g
• Best exam simulation Oracle ocp-dba9i download free trial.
• Pass OCP PL/SQL Developer in first attampt.
• Become Oracle Oracle Certified Master 10g certified.
• Click here to get free oracle-pl-sql Oracle PL/SQL Developer exam practice questions.
• Download free practice test for performance-tuning-certified-expert-11g Performance Tuning Expert 11g exam.
• Become Oracle RAC Certified Expert 10g certified.
• Click here to download sql-certified-expert-10g test study guide and practice question.
• Pass SQL Certified Expert 11g in first attampt.
• Download practice question and study guide for 1Z0-042 for exam.
• Best exam simulation Oracle 1Z0-047 download free trial.

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.