APACHE

Q2. How do you delete the Apache Jserv (Java Server) cache?
A2. The Apache Jserv cache is stored in the directory '$OA_HTML/_pages'. For troubleshooting purposes it can be useful to delete the
Apache Jserv cache. To remove the $OA_HTML/_pages directory you could type rm -rf _pages. This should
remove '_pages' and all its subdirectories. Restart Apache and test.

Q3. How do you bounce the Apache Server?

A3. The Apache server can be shutdown with the seeded Oracle script 'adapcctl. sh'. This script normally resides in
$COMMON_TOP/admin/scripts. When you are in $COMMON_TOP/admin/scripts, to stop Apache enter the command 'adapcctl.sh
stop'. To start Apache enter 'adapcctl.sh start'. For further information, review the
section titled 'Server Process Control Scripts' in 'Installing Oracle Applications, Release 11i (11.5.x)'.

Q4. When are you required to bounce the apache server?

A4. Please bounce the Apache Server when the following changes are made:
i. Create new template
ii. Define new expense type for existing template
iii. Update end date from expense type (Change immediate for disconnected )
iv. End date currency in Currencies window
v. Change prompt value for expense type (Change immediate for details)
vi. Change profile option
vii. Change fnd messages
viii. Recompile plsql packages
ix. Enable tax codes for OIE (Change immediate for details page)
x. Update inactive on date for template
xi. Define Itemization setup (Itemization required does not require bounce,
Specify initial set of expense types does not
require bounce. Subsequent changes to set requires bounce)

Q5. How do you bounce the Jserv (Java Server) ?

A5. With the default setup the JServ (Java Server) is automatically bounced whenever Apache is bounced. So, bouncing Apache will
also bounce the Jserv.

Q6. Why are there two Classpaths for OIE Second Generation?
A6. On a Unix system there is the Environment Variable Classpath. For example, when you open a shell you will normally have
defined an Environment Variable called Classpath. This variable will be used for your shell session. There is
also the Classpath for the Jserv that is set in jserv.properties. These Classpaths are not the same.

Q7. Are there any Examples of Classpaths for OIE Second Generation?
A7. Please review What Are Examples of Classpaths for OIE Second Generation.
Please note these are examples only and are specific to the instances for which they were used. For additional information on the
setup of the Web Server Classpath review the "8. Update the web server java classpath" in Note 139863.1 'Configuring and
Troubleshooting the Self Service Framework with Oracle Applications'.

Q8. How can you setup Apache Web Server session timeouts in OIE Second
Generation?
A8. Please review How to.
Set the Session Timeout Limit in OIE Second Generation

Q9. What are the Apache/Jserv Logs files and where are these log files located
on the file system?
A9. error_log $APACHE_TOP/Apache/logs/
access_log $APACHE_TOP/Apache/logs/
mod_jserv_log $APACHE_TOP/Jserv/logs/
jserv_log $APACHE_TOP/Jserv/logs/

Q10. What type of information is written to the Apache/JServ Log files?

A10. error_log: Contains a record of errors encountered by the Apache Server.
access_log: Contains a record of the URLs requested from the Apache server.
mod_jserv_log: Contains a record of messages and errors encountered by JServ (c-
side).
jserv_log: Contains a record of messages and errors encountered by Java (Java-
side)..

How do you restart (bounce) the Apache server?

Oracle Applications come with a default script to restart (e.g., bounce) the Apache Server. This script can be modified by the
Administrators on site.

Typically, this is done using the following command:

<ORAHTTP_TOP>/Apache/bin/apachectl restart

Note: Please verify with your Administrators before attempting this command.
ORA-01555: "Snapshot too old" – Overview
There are various reasons why customers can get the error ORA-01555. Sometimes
it is due to rollback segments being too small in size, but there are other reasons. This bulletin is an attempt to give a complete
summary of all the situations which would cause an ORA-01555 error and how to resolve them. In order to understand the bulletin, one
needs to understand some of the internal mechanisms of Oracle, so we start by explaining briefly about
read consistency and block cleanouts.

Oracle always enforces statement-level read consistency. This guarantees that the data returned by a single query is consistent with
respect to time when the query began. Therefore, a query never sees the data-changes made by transactions that commit during the
course of execution of the query.

Oracle uniquely identifies any given point in time by a set of numbers called the System Change Numbers (SCN). So SCN can be
defined as the state of the database at any one given point in time. To produce read-consistency, Oracle
marks the current SCN as the query enters the execution phase. The query can only see the snapshot of the records as they were at
the time of marked SCN.

Oracle uses rollback segments to reconstruct the read-consistent snapshot of the data. Whenever a transaction makes any changes,
a snapshot of the record before the changes were made is copied to a rollback segment and the data block header is marked
appropriately with the address of the rollback segment block where the changes are recorded. The data block also maintains
the SCN of the last committed change to the block.

As the data blocks are read on behalf of the query, only blocks with lower SCN than the query SCN will be read. If a block has
uncommitted changes of other transactions or changed data with more recent SCN, then the data is reconstructed using the saved
snapshot from the rollback segments. In some rare situations, if RDBMS is not able to reconstruct the snapshot for a long
running query, the query results in an ORA-01555 error.

A rollback segment maintains the snapshot of the changed data as long as the transaction is still active (commit or rollback has not
been issued). Once a transaction is committed, RDBMS marks it with current SCN and the space used by the snapshot becomes
available for reuse.

Therefore, ORA-01555 will result if the query is looking for the snapshot which is so old that rollback segment information could not be
found because of wrap around or overwrite.

SITUATIONS WHERE ORA-01555 ERRORS COMMONLY OCCUR:

=================================================

1. Fewer and smaller rollback segments for a very actively changing database

If the database has many transactions changing data and commiting very often, then the chance of reusing the space used by a
committed transaction is higher. A long running query then may not be able to reconstruct the snapshot due to wrap around and
overwrite in rollback segments. Larger rollback segments in this case will reduce the chance
of reusing the committed transaction slots.

2. Corrupted rollback segment

If the rollback segment is corrupted and could not be read, then a statement needing to reconstruct a before image snapshot will result
in the error.

3. Fetch across commit

This is the situation when a query opens a cursor, then loops through fetching, changing, and committing the records on the same
table. In this scenerio, very often an ORA-01555 can result. Let's take the following example to explain this:

A cursor was opened at SCN=10. The execution SCN of the query is then marked as SCN=10. Every fetch by that cursor now needs
to get the read-consistent data from SCN=10. The user program is now fetching x numbers of records, changing them, and committing
them.
Let's say they were committed with SCN=20. If a later fetch happens to retrieve a record which is in one of the previously committed
blocks, then the fetch will see that the SCN there as 20. Since the fetch has to get the snapshot from SCN=10 it will try to find it in
the rollback segments. If it could rollback sufficiently backwards as previously explained, then it could reconstruct the snapshot
from SCN=10. If not, then it will result in an ORA-01555 error.

Committing less often which will result in larger rollback segments will REDUCE the probability of getting 'snapshot too old' error.

4. Fetch across commits with delayed block clean out

To complicate things, now we see how delayed block clean outs play an important role in getting this error.

When a data or index block is modified in the database and the transaction committed, Oracle does a fast commit by marking the
transaction as committed in the rollback segment header but does not clean the datablocks that were modified. The next transaction
which does a select on the modified blocks will do the actual cleanout of the block. This is known
as a delayed block cleanout.
Now, take the same scenario as described in previous section. But instead of assuming one table, let us assume that there are two
tables in question. i.e: the cursor is opened and then in a loop, it fetches from one table and changes records in another, and commits.
Even though the records are getting committed in another table it could still cause ORA-01555 because cleanout has not been done
on the table from which the records are being fetched.

For this case, a full table scan before opening and fetching through the cursor will help.

Summary: Fetches across commits as explained in last two cases are not supported by ANSI standard. According to ANSI standard
a cursor is invalidated when a commit is performed and should be closed and reopened. Oracle allows users to do fetch across
commits but users should be aware that it might result in ORA-01555