Explore topic-wise InterviewSolutions in .

VIEWS do not CONTAIN or STORE DATA.

Views do not contain or store data.

When an instance of an ORACLE DATABASE is started, its control file is used to identify the database and redo log files that MUST be OPENED for database OPERATION to proceed. It is also used in database recovery.

When an instance of an ORACLE database is started, its control file is used to identify the database and redo log files that must be opened for database operation to proceed. It is also used in database recovery.

Yes.

Yes.

Yes.

Yes.

Yes.

Yes.

A full backup is an operating SYSTEM backup of all data files, on-line REDO LOG files and control file that constitute ORACLE DATABASE and the PARAMETER.

A full backup is an operating system backup of all data files, on-line redo log files and control file that constitute ORACLE database and the parameter.

A MIRRORED on-line redo log consists of copies of on-line redo log files physically located on separate disks, changes made to one member of the GROUP are made to all MEMBERS.

A mirrored on-line redo log consists of copies of on-line redo log files physically located on separate disks, changes made to one member of the group are made to all members.

A Partial Backup is any OPERATING system backup SHORT of a FULL backup, TAKEN while the database is OPEN or shut down.

A Partial Backup is any operating system backup short of a full backup, taken while the database is open or shut down.

VIEW is a VIRTUAL table. EVERY view has a query ATTACHED to it. (The query is a SELECT statement that identifies the columns and rows of the table(s) the view USES).

view is a virtual table. Every view has a query attached to it. (The query is a SELECT statement that identifies the columns and rows of the table(s) the view uses).

A table is the BASIC UNIT of data storage in an ORACLE database. The TABLES of a database hold all of the USER accessible data. Table data is stored in rows and columns.

A table is the basic unit of data storage in an Oracle database. The tables of a database hold all of the user accessible data. Table data is stored in rows and columns.

Yes.

Yes.

Schema objects are the LOGICAL structures that directly refer to the DATABASE's data. Schema objects include tables, views, SEQUENCES, synonyms, indexes, clusters, database triggers, procedures, functions PACKAGES and database links.

Schema objects are the logical structures that directly refer to the database's data. Schema objects include tables, views, sequences, synonyms, indexes, clusters, database triggers, procedures, functions packages and database links.

A SCHEMA is COLLECTION of DATABASE OBJECTS of a USER.

A schema is collection of database objects of a user.

EVERY Oracle database contains a TABLESPACE named SYSTEM, which is automatically created when the database is created. The SYSTEM tablespace always contains the data DICTIONARY TABLES for the entire database.

Every Oracle database contains a tablespace named SYSTEM, which is automatically created when the database is created. The SYSTEM tablespace always contains the data dictionary tables for the entire database.

A DATABASE is divided into Logical Storage UNIT called tablespaces. A tablespace is used to GROUPED related logical structures together.

A database is divided into Logical Storage Unit called tablespaces. A tablespace is used to grouped related logical structures together.

There are TABLESPACES and DATABASE's SCHEMA OBJECTS.

There are tablespaces and database's schema objects.

ORACLE DATABASE is comprised of three types of FILES. One or more datafiles, two are more REDO log files, and one or more control files.

Oracle database is comprised of three types of files. One or more datafiles, two are more redo log files, and one or more control files.

There are several METHODS to do this;

1. EXPORT the table, DROP the table, CREATE the table DEFINITION in the new tablespace, and then import the data (imp ignore=y).
2. Create a new table in the new tablespace with the CREATE TABLE statement AS SELECT all from source table command.

CREATE TABLE temp_name TABLESPACE new_tablespace AS SELECT * FROM source_table;

Then drop the original table and rename the temporary table as the original:

There are several methods to do this;

CREATE TABLE temp_name TABLESPACE new_tablespace AS SELECT * FROM source_table;

Then drop the original table and rename the temporary table as the original:

Different versions of the import utility are upwards COMPATIBLE. This means that one can take an export file created from an old export version, and import it using a LATER version of the import utility.

Oracle also ships some previous catexpX.sql SCRIPTS that can be executed as user SYS ENABLING older imp/exp versions to work (for backwards compatibility).

For example, one can RUN $ORACLE_HOME/rdbms/admin/catexp7.sql on an Oracle 8 database to allow the Oracle 7.3 exp/imp utilities to run against an Oracle 8 database.

Different versions of the import utility are upwards compatible. This means that one can take an export file created from an old export version, and import it using a later version of the import utility.

Oracle also ships some previous catexpX.sql scripts that can be executed as user SYS enabling older imp/exp versions to work (for backwards compatibility).

For example, one can run $ORACLE_HOME/rdbms/admin/catexp7.sql on an Oracle 8 database to allow the Oracle 7.3 exp/imp utilities to run against an Oracle 8 database.

Oracle Database CREATES server processes to handle the requests of user processes connected to an instance.

A server process can be either of the following:

• A dedicated server process, which services only one user process.
• A shared server process, which can service multiple user processes.

Your database is always ENABLED to allow dedicated server processes, but you must SPECIFICALLY configure and enable shared server by setting one or more initialization parameters.

Oracle Database creates server processes to handle the requests of user processes connected to an instance.

A server process can be either of the following:

Your database is always enabled to allow dedicated server processes, but you must specifically configure and enable shared server by setting one or more initialization parameters.

Range Partitioning MAPS data to partitions based on a range of column values (e.g. a date column)
Hash Partitioning maps data to partitions based on a HASHING ALGORITHM, EVENLY distributing data between the partitions.

Range Partitioning maps data to partitions based on a range of column values (e.g. a date column)
Hash Partitioning maps data to partitions based on a hashing algorithm, evenly distributing data between the partitions.

Local Index :each partition of a local index is ASSOCIATED with exactly one partition of the table.
Global Index :global index is associated with MULTIPLE partitions of the table.

Oracle offers two TYPES of global partitioned index:

• Global Range Partitioned INDEXES.
• Global Hash Partitioned Indexes.

Local Index :each partition of a local index is associated with exactly one partition of the table.
Global Index :global index is associated with multiple partitions of the table.

Oracle offers two types of global partitioned index:

A conventional path load executes SQL INSERT statements to POPULATE tables in an ORACLE database.
A direct path load eliminates MUCH of the Oracle database overhead by formatting Oracle data blocks and writing the data blocks directly to the database files.

A conventional path load executes SQL INSERT statements to populate tables in an Oracle database.
A direct path load eliminates much of the Oracle database overhead by formatting Oracle data blocks and writing the data blocks directly to the database files.

DELETE: command is used to remove rows from a table. A WHERE clause can be used to only remove some rows.

If no WHERE condition is specified, all rows will be removed. After performing a DELETE OPERATION you need to COMMIT or ROLLBACK the transaction to MAKE the CHANGE permanent or to undo it.
DELETE will cause all DELETE triggers on the table to FIRE.

TRUNCATE: removes all rows from a table. A WHERE clause is not permited. The operation cannot be rolled back and no triggers will be fired.

As such, TRUCATE is faster and doesn't use as much undo space as a DELETE.

DELETE: command is used to remove rows from a table. A WHERE clause can be used to only remove some rows.

If no WHERE condition is specified, all rows will be removed. After performing a DELETE operation you need to COMMIT or ROLLBACK the transaction to make the change permanent or to undo it.
DELETE will cause all DELETE triggers on the table to fire.

TRUNCATE: removes all rows from a table. A WHERE clause is not permited. The operation cannot be rolled back and no triggers will be fired.

As such, TRUCATE is faster and doesn't use as much undo space as a DELETE.

YES. This is achievable with Oracle Resource Manager.
DBMS_RESOURCE_MANAGER is the packcage to administer the DATABASE Resource Manager.
The DBMS_RESOURCE_MANAGER package MAINTAINS plans, consumer groups, and plan directives. It ALSO provides semantics so that you MAY group together changes to the plan SCHEMA.

YES. This is achievable with Oracle Resource Manager.
DBMS_RESOURCE_MANAGER is the packcage to administer the Database Resource Manager.
The DBMS_RESOURCE_MANAGER package maintains plans, consumer groups, and plan directives. It also provides semantics so that you may group together changes to the plan schema.

YES. That's POSSIBLE.
SQL>alter system set shared_pool_size=500M scope=both;
System altered.
It's a LOT QUICKER to bounce the instance when changing this.

YES. That's possible.
SQL>alter system set shared_pool_size=500M scope=both;
System altered.
It's a lot quicker to bounce the instance when changing this.

STATSPACK: is a performance diagnosis TOOL provided by Oracle starting from Oracle 8i and above.STATSPACK is a diagnosis tool for instance-wide performance problems it also supports APPLICATION tuning activities by providing DATA which identifies high-load SQL statements.

Although AWR and ADDM (introduced in Oracle 10g) provide better statistics than STATSPACK,
users that are not licensed to use the Enterprise MANAGER Diagnostic Pack should continue to use statspack.

STATSPACK: is a performance diagnosis tool provided by Oracle starting from Oracle 8i and above.STATSPACK is a diagnosis tool for instance-wide performance problems it also supports application tuning activities by providing data which identifies high-load SQL statements.

Although AWR and ADDM (introduced in Oracle 10g) provide better statistics than STATSPACK,
users that are not licensed to use the Enterprise Manager Diagnostic Pack should continue to use statspack.

The Buffer CACHE Advisor provides advice on how to size the Database Buffer Cache to OBTAIN OPTIMAL cache HIT ratios. Member of PERFORMANCE Advisors --> Memory Advisor pack.

The Buffer Cache Advisor provides advice on how to size the Database Buffer Cache to obtain optimal cache hit ratios. Member of Performance Advisors --> Memory Advisor pack.

YES. In many WAYS, for example from GUI based tools like TOAD, Oracle SQL Developer.

Configuring AUTOTRACE, a SQL*Plus facility

AUTOTRACE is a facility within SQL*Plus to show us the explain plan of the queries we've executed, and the RESOURCES they USED. Once the PLAN_TABLE has been installed in the database, You can control the report by setting the AUTOTRACE system variable.

• SET AUTOTRACE OFF - No AUTOTRACE report is generated. This is the default.
• SET AUTOTRACE ON EXPLAIN - The AUTOTRACE report shows only the optimizer execution path.
• SET AUTOTRACE ON STATISTICS - The AUTOTRACE report shows only the SQL statement execution statistics.
• SET AUTOTRACE ON - The AUTOTRACE report includes both the optimizer execution path and the SQL statement execution statistics.
• SET AUTOTRACE TRACEONLY - Like SET AUTOTRACE ON, but SUPPRESSES the printing of the user's query output, if any.

YES. In many ways, for example from GUI based tools like TOAD, Oracle SQL Developer.

Configuring AUTOTRACE, a SQL*Plus facility

AUTOTRACE is a facility within SQL*Plus to show us the explain plan of the queries we've executed, and the resources they used. Once the PLAN_TABLE has been installed in the database, You can control the report by setting the AUTOTRACE system variable.

YES. You can create and rebuild indexes online.
This enables you to update base tables at the same time you are building or rebuilding indexes on that table.
You can perform DML operations while the index BUILD is taking PLACE, but DDL operations are not allowed.
Parallel EXECUTION is not SUPPORTED when creating or rebuilding an index online.
The following statements illustrate online index build operations:
CREATE INDEX emp_name ON emp (mgr, emp1, emp2, emp3) ONLINE.

YES. You can create and rebuild indexes online.
This enables you to update base tables at the same time you are building or rebuilding indexes on that table.
You can perform DML operations while the index build is taking place, but DDL operations are not allowed.
Parallel execution is not supported when creating or rebuilding an index online.
The following statements illustrate online index build operations:
CREATE INDEX emp_name ON emp (mgr, emp1, emp2, emp3) ONLINE.

In 90% cases - NEVER. When the data in index is sparse (lots of HOLES in index, due to DELETES or UPDATES) and your query is usually range based. Also index blevel is one of the key indicators of performance of sql queries doing Index range scans.

In 90% cases - NEVER. When the data in index is sparse (lots of holes in index, due to deletes or updates) and your query is usually range based. Also index blevel is one of the key indicators of performance of sql queries doing Index range scans.

For example, assume there is a motor vehicle DATABASE with numerous low-cardinality COLUMNS such as car_color, car_make, car_model, and car_year. Each column contains less than 100 distinct values by themselves, and a b-tree INDEX would be fairly useless in a database of 20 MILLION vehicles.

For example, assume there is a motor vehicle database with numerous low-cardinality columns such as car_color, car_make, car_model, and car_year. Each column contains less than 100 distinct values by themselves, and a b-tree index would be fairly useless in a database of 20 million vehicles.

SMALL tables do not require INDEXES; if a query is taking too long, then the table might have grown from small to large. You can create an index on any column; however, if the column is not USED in any of these SITUATIONS, creating an index on the column does not increase performance and the index TAKES up resources unnecessarily.

Small tables do not require indexes; if a query is taking too long, then the table might have grown from small to large. You can create an index on any column; however, if the column is not used in any of these situations, creating an index on the column does not increase performance and the index takes up resources unnecessarily.

A B-Tree INDEX is a DATA structure in the FORM of a tree, but it is a tree of database blocks, not rows.

A B-Tree index is a data structure in the form of a tree, but it is a tree of database blocks, not rows.

There are many index types within Oracle:

B*Tree Indexes - common indexes in Oracle. They are similar construct to a binary tree, they provide fast access by KEY, to an individual row or range of rows, normally requiring very few reads to find the correct row.

The B*Tree index has several subtypes:

• Index Organised Tables - A table stored in a B*Tree structure
• B*Tree Cluster Indexes - They are used to index the cluster keys
• Reverse Key Indexes - The bytes in the key are reversed. This is used to stop sequential keys being on the same block like 999001, 999002, 999003 would be reversed to 100999, 200999, 300999 thus these would be located on different blocks.
• Descending Indexes - They allow data to be sorted from big to SMALL (descending) instead of small to big (ascending).

Bitmap Indexes - With a bitmap index , a single index entry uses a bitmap to point to many rows SIMULTANEOUSLY, they are used with low data that is mostly read-only. Schould be avoided in OLTP systems.

Function Based Indexes - These are B*Tree or bitmap indexes that store the computed result of a function on a row(s) (for example sorted results)- not the column data itself.

Application Domain Indexes - These are indexes you build and store yuorself, either in Oracle or outside of Oracle interMedia Text Indexes - This is a specialised index built into Oracle to allow for keyword searching of large bodies of text.

There are many index types within Oracle:

B*Tree Indexes - common indexes in Oracle. They are similar construct to a binary tree, they provide fast access by key, to an individual row or range of rows, normally requiring very few reads to find the correct row.

The B*Tree index has several subtypes:

Bitmap Indexes - With a bitmap index , a single index entry uses a bitmap to point to many rows simultaneously, they are used with low data that is mostly read-only. Schould be avoided in OLTP systems.

Function Based Indexes - These are B*Tree or bitmap indexes that store the computed result of a function on a row(s) (for example sorted results)- not the column data itself.

Application Domain Indexes - These are indexes you build and store yuorself, either in Oracle or outside of Oracle interMedia Text Indexes - This is a specialised index built into Oracle to allow for keyword searching of large bodies of text.

In general, you should CREATE an index on a column in any of the following SITUATIONS:

• The column is queried frequently.
• A referential integrity constraint exists on the column.
• A UNIQUE KEY integrity constraint exists on the column.

The following list gives guidelines in choosing COLUMNS to index:

• You should create indexes on columns that are USED frequently in WHERE clauses.
• Are used frequently to join tables.
• Are used frequently in ORDER BY clauses.
• On columns that have few of the same values or unique values in the table.

In general, you should create an index on a column in any of the following situations:

The following list gives guidelines in choosing columns to index:

YES. Oracle DATABSE has default, scheduled job "gather_stats_job" that analyses stats on a daily basis during the maintenance window time.

There are two scheduled activities related to the collection of Oracle "statistics":

• AWR statistics: Oracle has an automatic method to collect AWR "snapshots" of DATA that is used to create elapsed-time performance reports.
• Optimizer statistics: Oracle has an automatic job to collect statistics to help the optimizer make intelligent decisions about the best access method to fetch the DESIRED rows.

This job can be disabled with this command: EXEC dbms_scheduler.disable(’SYS.GATHER_STATS_JOB’);
Oracle collects optimizer statistics for SQL VIA the default of autostats_target = auto.

YES. Oracle databse has default, scheduled job "gather_stats_job" that analyses stats on a daily basis during the maintenance window time.

There are two scheduled activities related to the collection of Oracle "statistics":

This job can be disabled with this command: exec dbms_scheduler.disable(’SYS.GATHER_STATS_JOB’);
Oracle collects optimizer statistics for SQL via the default of autostats_target = auto.

Analyse if it's necessary:

• Refresh STALE STATISTICS before the batch processes run but only for tables involved in batch run.
• Don't do it if you don't have to.
• Oracle databse has default, scheduled job "gather_stats_job" that analyses stats on a DAILY basis during the MAINTENANCE WINDOW time.

Analyse if it's necessary:

The ORACLE Cost Based Optimizer (CBO) is a SQL Query optimizer that uses data statistics to identify the query plan with lowest cost before execution. The cost is based on the number of rows in a table, index efficiency, etc. All APPLICATIONS should be converted to use the Cost Based Optimizer as the RULE Based Optimizer is not be supported in Oracle 10G and above releases.

The Oracle Cost Based Optimizer (CBO) is a SQL Query optimizer that uses data statistics to identify the query plan with lowest cost before execution. The cost is based on the number of rows in a table, index efficiency, etc. All applications should be converted to use the Cost Based Optimizer as the Rule Based Optimizer is not be supported in Oracle 10g and above releases.

The DBMS_FGA package provides FINE-grained security functions. DBMS_FGA is a PL/SQL package used to DEFINE Fine Grain AUDITING on objects.
DBMS_FGA Package Subprograms:

• ADD_POLICY Procedure - Creates an AUDIT policy using the supplied predicate as the audit CONDITION.
• DISABLE_POLICY Procedure - Disables an audit policy.
• DROP_POLICY Procedure - Drops an audit policy.
• ENABLE_POLICY Procedure - Enables an audit policy.

The DBMS_FGA package provides fine-grained security functions. DBMS_FGA is a PL/SQL package used to define Fine Grain Auditing on objects.
DBMS_FGA Package Subprograms:

YES. But beware, you will need a storage mechanism to hold your SQL SELECT audits, a high data volume that can exceed the size of your whole database, everyday.
SQL SELECT auditing can be accomplished in several ways:

• Oracle audit table command: audit SELECT table by FRED by access.
• Oracle Fined-grained Auditing.

In a BUSY database, the volume of the SELECT audit trail could easily exceed the size of the database every data. PLUS, all data in the audit trail must also be audited to SEE who has selected data from the audit trail.

YES. But beware, you will need a storage mechanism to hold your SQL SELECT audits, a high data volume that can exceed the size of your whole database, everyday.
SQL SELECT auditing can be accomplished in several ways:

In a busy database, the volume of the SELECT audit trail could easily exceed the size of the database every data. Plus, all data in the audit trail must also be audited to see who has selected data from the audit trail.

Locally Managed Tablespace is a tablespace that record extent allocation in the tablespace header.
Each tablespace manages it's own free and used SPACE within a bitmap structure stored in one of the tablespace's DATA files.

ADVANTAGES of Locally Managed Tablespaces:

• Eliminates the need for recursive SQL OPERATIONS against the data dictionary (UET$ and FET$ tables).
• Reduce contention on data dictionary tables (single ST enqueue).
• Locally managed tablespaces eliminate the need to periodically coalesce free space (automatically tracks ADJACENT free space).
• Changes to the extent bitmaps do not generate rollback information.

Locally Managed Tablespace is a tablespace that record extent allocation in the tablespace header.
Each tablespace manages it's own free and used space within a bitmap structure stored in one of the tablespace's data files.

Advantages of Locally Managed Tablespaces:

Row Migration:
Row Migration refers to rows that were moved to another blocks due to an update making them too large to fit into their original blocks.

Oracle will leave a FORWARDING pointer in the original BLOCK so indexes will still be able to "find" the row. Note that Oracle does not discriminate between CHAINED and migrated rows, even though they have different causes. A chained row is a row that is too large to fit into a single database data block.

For example, if you use a 4KB blocksize for your database, and you need to insert a row of 8KB into it, Oracle will use 3 blocks and store the row in pieces.

Some conditions that will cause row chaining are:

• Tables whose row size exceeds the blocksize.
• Tables with LONG and long raw columns are prone to having chained rows.
• ables with more then 255 columns will have chained rows as Oracle break wide tables up into pieces.

Detecting row chaining:
This query will show how many chained (and migrated) rows each table has:
SQL>SELECT owner, table_name, chain_cnt FROM dba_tables WHERE chain_cnt > 0;

To see which rows are chained:
SQL>ANALYZE TABLE tablename LIST CHAINED ROWS;

This will put the rows into the INVALID_ROWS table which is created by the utlvalid.sql script (located in $ORACLE_HOME/rdbms/admin).

Row Migration:
Row Migration refers to rows that were moved to another blocks due to an update making them too large to fit into their original blocks.

Oracle will leave a forwarding pointer in the original block so indexes will still be able to "find" the row. Note that Oracle does not discriminate between chained and migrated rows, even though they have different causes. A chained row is a row that is too large to fit into a single database data block.

For example, if you use a 4KB blocksize for your database, and you need to insert a row of 8KB into it, Oracle will use 3 blocks and store the row in pieces.

Some conditions that will cause row chaining are:

Detecting row chaining:
This query will show how many chained (and migrated) rows each table has:
SQL>SELECT owner, table_name, chain_cnt FROM dba_tables WHERE chain_cnt > 0;

To see which rows are chained:
SQL>ANALYZE TABLE tablename LIST CHAINED ROWS;

This will put the rows into the INVALID_ROWS table which is created by the utlvalid.sql script (located in $ORACLE_HOME/rdbms/admin).

PCTFREE: is a block storage parameter used to specify how much space should be left in a database block for future updates.

For example, for PCTFREE=10, Oracle will keep on adding new rows to a block until it is 90% full. This leaves 10% for future updates (row expansion). 

When using Oracle Advanced COMPRESSION, Oracle will trigger block compression when the PCTFREE is REACHED. This eliminates holes created by row deletions and maximizes contiguous free space in blocks.

See the PCTFREE setting for a table:

PCTUSED:is a block storage parameter used to specify when Oracle should consider a database block to be empty enough to be added to the freelist. Oracle will only insert new rows in blocks that is enqueued on the freelist.

For example, if PCTUSED=40, Oracle will not ADD new rows to the block unless sufficient rows are DELETED from the block so that it falls below 40% empty.

PCTFREE: is a block storage parameter used to specify how much space should be left in a database block for future updates.

For example, for PCTFREE=10, Oracle will keep on adding new rows to a block until it is 90% full. This leaves 10% for future updates (row expansion). 

When using Oracle Advanced Compression, Oracle will trigger block compression when the PCTFREE is reached. This eliminates holes created by row deletions and maximizes contiguous free space in blocks.

See the PCTFREE setting for a table:

PCTUSED:is a block storage parameter used to specify when Oracle should consider a database block to be empty enough to be added to the freelist. Oracle will only insert new rows in blocks that is enqueued on the freelist.

For example, if PCTUSED=40, Oracle will not add new rows to the block unless sufficient rows are deleted from the block so that it falls below 40% empty.

The large pool is an OPTIONAL memory area and provides large memory allocations for:

• Session memory for the shared server and the Oracle XA interface (used where transactions interact with more than one database).
• I/O server processes, BUFFER area.
• Oracle backup and RESTORE operations (RMAN).
• USER Global Area (UGA) for shared SERVERS.

The large pool is an optional memory area and provides large memory allocations for:

PGA_AGGREGATE_TARGET: SPECIFIES the target aggregate PGA MEMORY AVAILABLE to all server processes attached to the INSTANCE.

PGA_AGGREGATE_TARGET: specifies the target aggregate PGA memory available to all server processes attached to the instance.

A PFILE is a static, text FILE located in $ORACLE_HOME/dbs - UNIX.
An SPFILE (SERVER Parameter File) is a PERSISTENT server-side binary file that can only be MODIFIED with the "ALTER SYSTEM SET" command.

A PFILE is a static, text file located in $ORACLE_HOME/dbs - UNIX.
An SPFILE (Server Parameter File) is a persistent server-side binary file that can only be modified with the "ALTER SYSTEM SET" command.

The DATABASE BUFFER cache is the portion of the SGA that holds copies of DATA blocks read from datafiles.
All user processes CONCURRENTLY connected to the instance SHARE access to the database buffer cache.

The database buffer cache is the portion of the SGA that holds copies of data blocks read from datafiles.
All user processes concurrently connected to the instance share access to the database buffer cache.

YES. A DATAFILE can be auto EXTENDIBLE.
Here's how to enable auto extend on a Datafile:
SQL>alter database datafile '/u01/app/oracle/product/10.2.0/oradata/DBSID/EXAMPLE01.DBF' autoextend on.

YES. A Datafile can be auto extendible.
Here's how to enable auto extend on a Datafile:
SQL>alter database datafile '/u01/app/oracle/product/10.2.0/oradata/DBSID/EXAMPLE01.DBF' autoextend on.

Database Writer BACKGROUND PROCESS DBWn (20 POSSIBLE) writes dirty BUFFERS from the buffer cache to the data files.In other WORDS, this process writes modified blocks permanently to disk.

Database Writer background process DBWn (20 possible) writes dirty buffers from the buffer cache to the data files.In other words, this process writes modified blocks permanently to disk.