Now imagine that you area inserting data using two instances, what actually happen is that the block must “travel” from one instances to another, consuming time and resource as you may notice below:

INSTANCE1> insert into l3ajuste values (10);

1 row created.

INSTANCE2> insert into l3ajuste values (10);

1 row created.

INSTANCE2> commit;

Commit complete.

INSTANCE1> commit;

Commit complete.

SQL> select n,rowid from l3ajuste;

         N ROWID
———- ——————
        10 AA8H+3AAKAAAAE7AAA
        10 AA8H+3AAKAAAAE7AAB

 As you notice we were using the same block, on of course different rows.

And this is the root of a interconnect traffic when you are using SEGMENT_SPACE_MANAGEMENT=’MANUAL’;

When you instead create the table at a TABLESPACE with the SEGMENT_SPACE_MANAGEMENT=’AUTO’

Oracle is clever enough to make each instance use a different block, allowing us to have more performance since we don´t have the interconnect traffic, as you can see bellow:

SQL> create table l3ajusteB  (n number) TABLESPACE TBS_SEG_SPACE_AUTO;

INSTANCE1> insert into l3ajusteb values (10);

1 row created.

INSTANCE2> insert into l3ajusteb values (10);

1 row created.

INSTANCE2> commit;

Commit complete.

INSTANCE1> commit;

Commit complete.

SQL> select n,rowid from l3ajusteb;

            N ROWID
———- ——————
        10 AA8IAGABXAAB3CsAAA
        10 AA8IAGABXAAB3CzAAA

As you notice , we are not sharing the same block, thus the interconnect traffic , simple doesn´t happen.

The botton line is, if you want to decrease the interconnect traffic among RAC instances, the first step is move your data to automatic space management tablespaces.

Since the data are stored together according to the PK, as a bonus you decrease the amount of buffer cache usage.

Martin Widlake wrote a wonderful article about it:

http://mwidlake.wordpress.com/2011/08/08/iot-part-4-greatly-boosting-buffer-cache-efficiency/

SQL_ID        MAX_MEM_USED
————- ————
3mfa13g41v37x            0
59x35kd3vbd8f        71680
3z294wg0udavm        71680
9m2ctqgmdmw5w        88064
1rwxnm0m9vmc3       306176
9t202yjs4usz2       337920

You may also check the  _shared_pool_reserved_min_alloc

You must connect as sysdba

SET SERVEROUT ON;
CREATE OR REPLACE PROCEDURE ESPACO(VOWNER IN VARCHAR2,VTABELA IN VARCHAR2,VPROJETADO IN NUMBER)
IS
SAIDA NUMBER;
BEGIN
EXECUTE IMMEDIATE ‘SELECT BYTES/(SELECT COUNT(*) FROM ‘||VOWNER||’.'||VTABELA||’)*’||VPROJETADO||’ FROM DBA_SEGMENTS WHERE SEGMENT_NAME=:1 and owner=:2′ into saida using vtabela,vowner;
dbms_output.put_line(TRUNC(saida));
END;
/

Thu Jan 20 13:35:52 2011
Errors in file /DATA/oracle/admin/
prod/udump/prod_ora_2131.trc:
ORA-00600: internal error code,
arguments: [ktfbtgex-7], [1015817],
[1024], [1015816], [], [], [], []

ORA-600 or ORA-7445: What Is the Difference?

ORA-600 is a catchall message that indicates an error internal to the database code. The key point to note  is that it is signaled when a code check fails within the database. At points throughout the code, Oracle Database performs checks to confirm that the information being used in internal processing is healthy, that the variables being used are within a valid range, that changes are being made to a consistent structure, and that a change won’t put a structure into an unstable state. If a check fails, Oracle Database signals an ORA-600 error and, if necessary, terminates the operation to protect the health of the database.

The first argument error message indicates the location in the code where the check is performed; in the example above, that is ktfbtgex-7 (which indicates that the error occurred at a particular point during tablespace handling).

An ORA-7445 error, on the other hand, traps a notification the operating system has sent to a process and returns that notification to the user. Unlike the ORA-600 error, the ORA-7445 error is an unexpected failure rather than a handled failure.

ORA-07445: exception encountered:
core dump [kocgor()+96] [SIGSEGV]
[ADDR:0xF000000104] [PC:0x861B7EC]
[Address not mapped to object] []

 
the failing function is kocgor, which is associated with the handling of user-defined objects. The trapped signal is SIGSEGV (signal 11, segmentation violation), which is an attempt to write to an illegal area of memory. Another common signal is SIGBUS (signal 10, bus error), and there are other signals that occur less frequently, with causes that range from invalid pointers to insufficient OS resources.

Both ORA-600 and ORA-7445 errors will 

• Write the error message to the alert.log, along with details about the location of a trace containing further information
• Write detailed information to a trace file in the location indicated in the alert.log
• In Oracle Database 11g Release 1 onward, create an incident and place the relevant files in the incident directory in the location defined by the diagnostic_dest initialization file parameter
• Write the error message to the user interface if the server process is not terminated or signal ORA-3113 if it is

Often you will see multiple errors reported within the space of a few minutes, typically starting with an ORA-600. It is usually, but not always, the case that the first is the significant error and the others are side effects.

Can I Resolve These Errors Myself?

Check the whole Oracle Magazine article

Would you like to help define the depth and scope of future Oracle Database training and certification?

Oracle is conducting this online Job Task survey prior to the next major Oracle Database product release to ensure that the tasks Oracle Database Administrators consider important are prominent in the design of future Database Administrator curriculum and certification offerings.

Join with other Oracle experts to take this online survey and tell us what tasks are important to you.

Please click on the link below to get started:
Oracle DBA Job-Task Analysis Survey

After completing the survey, get your FREE Oracle Database 11g Interactive Reference Guide. This free interactive reference guide can help you write custom data dictionary scripts, locate views pertinent to a specific database component, and more.

If you have problems accessing the survey, please contact Oracle at DBA-Survey-help

As Tom Kyte published in setember Oracle Magazine:

“

SQL> begin
   2   :cpu := dbms_utility.get_cpu_time;
   3   dbms_application_info.set_client_info(0);
   4 end;
   5 /
PL/SQL procedure successfully completed.

SQL> select owner, f(owner) from stage;
…
72841 rows selected.

SQL> select
  2  dbms_utility.get_cpu_time-:cpu cpu_hsecs,
  3  userenv(‘client_info’)
  4  from dual;

CPU_HSECS   USERENV(‘CLIENT_INFO’)
———   ———————–
       118                     72841
“

To read the whole article:

http://www.oracle.com/technetwork/issue-archive/2011/11-sep/o51asktom-453438.html

This time the product was PMI RMP - PMI Risk Management Professional Prepkit.

The overall feeling is that Ucertify have a very good solid product.

The specific area evaluated areas were:

Download , Installation and registration: Perfect.

Usability: Excellent.

Methodology: Very good.

Quality of questions: Very good.

Answer explanations: Good.

How  balanced are the usage among my RAC instances?

What is the database with higher resource demand? (not just redo writting).

Well the query below intend to answer those questions. It shows how much is the usage of database per second since the database started.

select
t1.inst_id,t1.STARTUP_TIME,trunc(value/((sysdate-STARTUP_TIME)*24*60*60)/1000000,2)
from
gv$instance t1,gv$sys_time_model t2 where
t1.INST_ID=t2.INST_ID and t2.stat_name=’DB time’
order by 2;

Futher improvements:

One may create a table , to record snapshots (AWR already do it, but you need the license), then you can check the delta between couple of minutes or hours.