Solaris: How to nfs mount a directory

Follow these steps

On box where you want to share or the source box

0. Login as root

1. Edit dfstab
vi /etc/dfs/dfstab
insert
share -F nfs /opt/logs

2. Start the NFS Server
/etc/init.d/nfs.server start

3. Check is exported
exportfs

On box where you want to mount it or the target box
0. Login as root
1. Create a mount point
mkdir a;chmod 777 a

2. start NFS client
/etc/init.d/nfs.client start

3. mount the nfs
mount -F nfs hostname:/opt/logs /a

to unmount
umount /a

Sometimes you get error messages like this one:

nfs mount: mount: variable: Device busy

Cause This message appears when the superuser attempts to NFS mount on top of an active directory. The busy device is actually the working directory of a process.

Action Determine which shell on the workstation is currently located below the mount point, and change out of that directory. Be wary of subshells (such as su shells) that could be in different working directories while the parents remain below the mount point.

Execute this command to check

fuser directory on client where you are trying to mount nfs or

Do an lsof |grep directory on client where you are trying to mount nfs

This will give you the process which is accessing the directory. You can kill that process.

If you yourself are in that directory while trying to umount, cd out of it.

Here's the best nfs document for Solaris, for people who want to go into more details.

Invalid OLAPSYS and SYS objects after installing OLAP and Data Mining

We installed OLAP and Data Mining after upgrading the Apps Instance from to 11.5.9/9.2.0.8 to 11.5.10.2/10.2.0.3 by following point 19 in interop metalink note:362203.1 point 19:

To install Data Mining, use SQL*Plus to connect to the database as SYSDBA and run the following command:

SQL> @$ORACLE_HOME/rdbms/admin/dminst.sql SYSAUX TEMP

If the query does not return AMD, then you do not have OLAP installed. To install OLAP, use SQL*Plus to connect to the database as SYSDBA and run the following command:

SQL> @$ORACLE_HOME/olap/admin/olap.sql SYSAUX TEMP

We got the following invalids after running the above sqls:

SQL> /

OWNER OBJECT_TYPE OBJECT_NAME
---------- ------------------- ---------------------------
OLAPSYS PACKAGE BODY CWM2_OLAP_METADATA_REFRESH
OLAPSYS PACKAGE BODY CWM2_OLAP_OLAPAPI_ENABLE
OLAPSYS PACKAGE BODY DBMS_AWM
SYS PACKAGE DBMS_XSOQ_ODBO
SYS PACKAGE BODY DBMS_XSOQ_ODBO
PUBLIC SYNONYM DBMS_XSOQ_ODBO
SYS TYPE OLAPI_MDX_ROWSET_IMPL_T
SYS FUNCTION OLAPI_MDX_ROWSET_TABLE
PUBLIC SYNONYM OLAPI_MDX_ROWSET_IMPL_T
PUBLIC SYNONYM OLAPI_MDX_ROWSET_TABLE

10 rows selected.

I have logged an SR with Oracle for this. I'll update this post with the solution given by them.

Before Oracle could provide an answer, I reran this command:

SQL> @$ORACLE_HOME/olap/admin/olap.sql SYSAUX TEMP

All the invalids are gone after re-running the command. It is possible that the DBA who ran the command originally, may have got some errors, but carelessly he did not spool the run.

Interesting article about Oracle product versions

I came across an article in searchoracle.com titled Understand Oracle versioning: 8i through 11i.10 by Carol Francum, CIO for Ashford Systems Group. Here's an excerpt:

--------------------------------------------------------------

Listening in to a conversation between Oracle users can be very confusing:

Imagine stepping into the break room and you hear Phil and Bill say, "We're looking at migrating to 11i, we're on 10.7 using 8.1.4."

On the way to your office, you hear Sarah tell HR, "Well, we need someone who's experienced in 11.5.9."

You heard the IT department is developing a Portal. When you ask your pal for more information he says: "Well, we want to compare Websphere to Oracle Application Server."

And, in a meeting with the sales and marketing staff: "Agreed. We need to implement CRM. Bill, will you look into how that works with the Financials?"

"Huh?"

They're all talking about Oracle, but they're referring to different aspects of Oracle products. Let's see if we can clear it up, at least a little.

--------------------------------------------------------------

You can read the full article on the original link by registering with searchoracle.com. Registration is free.

iStore: Mystery of the missing items

Today, I was told about a problem which seemed so basic that I thought it must be a known bug already. In iStore module, items newly added are not visible in price list until we bounce Apache. Strangely this happens only in extranet nodes, intranet nodes show the newly added items. As per point 1 given below, it is expected behavior. But if it is expected behavior, then the behavior of iStore should be same in both extranet and intranet nodes.

Metalink Note 397816.1 describes list Of iStore Operations That Require/Does Not Require Bouncing of Apache:

1. Adding new items to the Price list and onto store and get them reflected in store.
Bouncing Required : Yes ( In Some Exception case, does not require bounce )

2. Existing item in Price list and store, but effective date in price list changed. I.e. end date changed etc.
Bouncing Required : Yes ( In Some Exception case, does not require bounce )

3. Adding available items to the Section/Store.
Bouncing Required : No

4. Ensuring items to be available to Admin UI so that they can be assigned to a store.
Bouncing Required : Yes

5. New section is added to a store.
Bouncing Required : No

6. Payment method in store is updated. For instance invoice is not checked and later checked.
Bouncing Required : No

7. Store Exclusion/Inclusion is updated. I.e. A section being included in the Store scenario,
the already selected store is excluded/ any addition store is assigned.
Bouncing Required : No

8. Display template is updated. For instance Product multi select is changed with any other templates.
Bouncing Required : No

9. Item changes in Published or Orderable on Web flags.
Bouncing Required : YES

Still exploring this one. Will update as I learn more.

How to find out which patch caused issue whie applying a merged patch

To minimize downtime, Apps patches are usually merged and applied. Sometimes, a worker may fail while applying the merged patch. Oracle will usually ask you which patch failed, if you log an SR with them for the issue. Here's how I singled out the patches in a merged patch containing 224 patches:

Worker failed with this error:

sqlplus -s APPS/*****
@$PON_TOP/patch/115/sql/ponTemplateUpg.sql
declare
*
ERROR at line 1:
ORA-01001: invalid cursor
ORA-06512: at "APPS.FND_ATTACHED_DOCUMENTS2_PKG", line 899
ORA-01400: cannot insert NULL into ("APPLSYS"."FND_LOBS"."FILE_CONTENT_TYPE")
ORA-06512: at line 284

cd to directory which has the unzipped source patches

$ find . -name u*.drv -print -exec egrep ponTemplateUpg.sql {} \;

./4028294/u4028294.drv
copy pon patch/115/sql ponTemplateUpg.sql 115.3.11510.4
# file-version-parsed pon patch/115/sql ponTemplateUpg.sql 115.3.11510.4
sql pon patch/115/sql ponTemplateUpg.sql none none none sqlplus &phase=upg

./5150810/u5150810.drv
copy pon patch/115/sql ponTemplateUpg.sql 115.3.11510.4
# file-version-parsed pon patch/115/sql ponTemplateUpg.sql 115.3.11510.4
sql pon patch/115/sql ponTemplateUpg.sql none none none sqlplus &phase=upg checkfile:pon:patch/115/sql:ponTemplateUpg.sql

$ adident Header $PON_TOP/patch/115/sql/ponTemplateUpg.sql
$PON_TOP/patch/115/sql/ponTemplateUpg.sql:
$Header ponTemplateUpg.sql 115.3.11510.4 2004/11/02 09:18:50 ssthakur ship $

$ adident Header ./4028294/pon/patch/115/sql/ponTemplateUpg.sql
./4028294/pon/patch/115/sql/ponTemplateUpg.sql:
$Header ponTemplateUpg.sql 115.3.11510.4 2004/11/02 09:18:50 ssthakur ship $

$ adident Header ./5150810/pon/patch/115/sql/ponTemplateUpg.sql
./5150810/pon/patch/115/sql/ponTemplateUpg.sql:
$Header ponTemplateUpg.sql 115.3.11510.4 2004/11/02 09:18:50 ssthakur ship $

Both the patches 4028294 and 5150810 contain the same version of ponTemplateUpg.sql. So this error can occur due to any of these two patches.

adpatch options

I have noticed that most of the people are not aware of all the options available with adpatch. It is very simple, just type :

adpatch help=y

on unix prompt to display all the options.

Here's the output on an 11.5.10.2 instance patched with AD.I.5 and ATG RUP5:

adpatch help=y

usage: adpatch [help=y]

adpatch Pre-Install Mode
[preinstall=y|n]

adpatch Test Mode
[apply=y|n]

adpatch Non-Interactive mode
[defaultsfile=<$APPL_TOP/admin/SID/defaultsfile>]
[logfile=][interactive=y|n][workers=]
[patchtop=][driver=][restart=y|n]
[abandon=y|n][wait_on_failed_job=y|n]

adpatch
[localworkers=][workers=]
[printdebug=y|n][parallel_index_threshold=]
[order=] [flags=][options=]

adpatch Upload Patch History From Filesystem
[uploadph=y|n]
where

* help=y - Prints help information about adpatch options.

* preinstall - To run adpatch in Pre-Install Mode.
Default - No.

* apply - To run adpatch in Test Mode.
Default - Yes.

* uploadph - To upload the patch history from the filesystem to the
database and exit. This feature can be used when the system
is not in maintenance mode.
Default - No.

* interactive - Invokes adpatch in Non-Interactive mode when
"interactive=no" is specified.
Default - Yes.

Following are usually specified in Non-Interactive Mode, however not all
are compulsory. Some are also valid for interactive mode.

* defaultsfile - Defaults file name.
Default - none. No default file read or written.
* logfile - Adpatch log file name.
Default - none. Adpatch prompts for this value.
* workers - Specifies the number of workers to run.
Default - none. Adpatch prompts for this value.
* patchtop - Top-level directory for the current patch.
Default - none. Adpatch prompts for this value.
* driver - Name of the patch driver file.
Default - none. Adpatch prompts for this value.
* restart - To restart an existing session.
Default - none. Adpatch prompts for this value.
* abandon - To abandon the previous failed session.
Default - No.
* wait_on_failed_job - To prevent adpatch from exiting, when all
workers have failed in Non-Interactive Mode.
Default - No.

* localworkers - Used in Distributed AD to specify the number of
workers to be run on the current machine.
Default - Value specified for workers.
* printdebug - To display extra debugging information.
Default - No.
* parallel_index_threshold - Threshold block count in each table, which when
exceeded for a table causes its indexes to be
created using parallel slaves.
Default - none. Adpatch does not create indexes
in parallel.

* order = To organize list of jobs to run in a phase. Default - forward.
* forward - The order in which jobs are listed in the
patch driver file.
* backward - Opposite to how the jobs are listed in the
patch driver file.

* flags = Generic flags passed to adpatch
* hidepw - To omit the "HIDEPW:" comments in the log file.
Default - hidepw.
* trace - To log all database operations to a trace file.
Default - notrace.
* logging - To create indexes in LOGGING or NOLOGGING mode.
Default - nologging.

* options = Generic options passed to adpatch.
* checkfile - To skip running exec, SQL, and exectier
commands if they are recorded as already run.
Default - checkfile.
* compiledb - To compile invalid objects in the database
after running actions in the database driver.
Default - compiledb.
* compilejsp - To compile out-of-date JSP files, if the patch
has copy actions for at least one JSP file.
Default - compilejsp.
* copyportion - To run commands found in a copy driver.
Default - copyportion.
* databaseportion - To run commands found in a database driver.
Default - databaseportion.
* generateportion - To run commands found in a generate driver.
Default - generateportion.
* integrity - To perform patch integrity checking.
Default - nointegrity.
* maintainmrc - To maintain the MRC schema after running
actions found in the database driver.
Default - maintainmrc.
* autoconfig - To run AutoConfig.
Default - autoconfig.
* actiondetails - To get the details of actions turned off.
Default - actiondetails.
* parallel - To run actions that update the database or
actions that generate files in parallel.
Default - parallel.
* prereq - To perform prerequisite patch checking prior
to running patch driver files.
Default - prereq.
* revcache - To load the package revision cache (if adpatch
determines it is needed).
Default - revcache.
* validate - To connect to all registered Oracle
Applications schemas at the start of the patch.
Default - novalidate.
* hotpatch - A patch which can be applied in Normal mode.
Default - hotpatch.
* phtofile - The patch history will be saved to files.
Default - nophtofile.