tnsping direct

the sytax

tnsping '(ADDRESS=(PROTOCOL=tcp)(HOST=10.24.0.11)(PORT=1521))'

authid current_user

http://download.oracle.com/docs/cd/B19306_01/appdev.102/b14261/subprograms.htm#i18574

To give the package the same rights as the caller of the package.

result cache

The two methods in 11g are

1) using a hint /*+ result_cache */
2) using the key words
result_cache
relies_on(table_name)

http://www.oracle.com/technology/oramag/oracle/07-sep/o57asktom.html

INSERT /*+ APPEND */ a good idea ?

Sometimes , sometimes not
1) not good for many small inserts as it appends each insert above the high water mark, leaving lots of unused space
2) only one session at a time can do it at a time

see
http://asktom.oracle.com/pls/asktom/f?p=100:11:0::::P11_QUESTION_ID:1211797200346279484

Oracle install on non Redhat Linux platform

./runInstaller -ignoreSysPrereqs


Specifically ODI

./runInstaller -ignoreSysPrereqs

Installs without a problem
except I had to chmod +x unzip

Post-install
JAVA_HOME=~/OraHome_1/jre/1.4.2
export JAVA_HOME

Then run
./operator.sh

bitmap indexesneed frequent rebuilds

Do they or do they not deteriorate over time (i.e. after lots of inserts/updates) and need rebuilding?

Does this answer the question?
http://technology.amis.nl/blog/1420/myths-on-bitmap-indexes

The Jonathon Lewis' response #18 seems to suggest that it is only true after many 'updates' but not many inserts

Another reason not to use PCT and Materializied views

PCT relies on being able to identify which partition a piece of data came from in the source table. Hence in any aggregates you have to 'group by ' the dbms__mview.marker(rowid). A side affect of this is that aggregates have to have the same paritioning regime as the data from which it is derived.

e.g.
if a daily aggregates table is partitioned weekly and you wish to roll it up into a yearly aggregates using materializied views and PCT then you will get 52 rows in the yearly aggregate, one for each weekly partition.
i.e. it is not a yearly aggregate