10.2.0.5 will be released in Q2 2010

Din nota :742060.1

Platform		10.2.0.4	10.2.0.5	11.1.0.7	11.2.0.1
Linux x86		22-FEB-2008	Q2CY2010	18-SEP-2008	1-SEP-2009
Linux x86-64		17-MAR-2008	Q2CY2010	18-SEP-2008	1-SEP-2009
Linux Itanium		24-SEP-2008	Q1CY2011	Not planned	Sched TBA
IBM Linux on POWER		9-JAN-2009 Patching for previous release ended 9-Apr-09	Q1CY2011	Not planned	Sched TBA
IBM Linux on System z		16-DEC-2008 Patching for previous release ended 16-Mar-09	Q4CY2010	Not planned	Q1CY2011
HP-UX PA-RISC (64-bit)		02-JUN-2008	Q4CY2010	11-Nov-2008	Q2CY2010
HP-UX Itanium		30-APR-2008	Q2CY2010	06-OCT-2008	22-DEC-2009
Sun Solaris SPARC (64-bit)		30-APR-2008	Q2CY2010	06-OCT-2008	6-Nov-2009
Sun Solaris x86-64 (64-bit)		13-NOV-2008	Q2CY2010	Not planned	25-Nov-2009
IBM AIX on POWER Systems		15-MAY-2008	Q2CY2010	06-OCT-2008	22-DEC-2009
Microsoft Windows (32-bit)		17-MAR-2008	Q3CY2010	10-OCT-2008	Q1CY2010
Microsoft Windows x64 (64-bit)		16-MAY-2008	Q3CY2010	13-NOV-2008	Q1CY2010
Microsoft Windows Itanium (64-bit)		2-FEB-2009 Patching for previous release ended 2-May-09	Q4CY2010	Not planned	Sched TBA
Apple Mac OS X (PowerPC)		Platform Obsolete	Platform Obsolete	Platform Obsolete	Platform Obsolete
Apple Mac OS X (Intel)		10-April-2009 Single Instance only	Sched TBA	Not planned	Sched TBA
HP Tru64 UNIX		20-FEB-2009 Patching for previous release ended 20-May-09	Q1CY2011	Platform Obsolete	Platform Obsolete
Sun Solaris x86 (32-bit)		14-Nov-2008 Last patch set for this platform	Platform Obsolete	Platform Obsolete	Platform Obsolete
HP OpenVMS Alpha		15-Dec-2008	Q3CY2011	Platform Obsolete	Platform Obsolete
HP OpenVMS Itanium		15-Dec-2008	Q3CY2011	Not planned	Q4CY2010
IBM z/OS on System z		Sched TBA	Sched TBA	Unsupported Platform (see Note:461234.1)	Unsupported Platform (see Note:461234.1)

ORA-600 [kkxprpic8]

Versiune DB : 9.2.0.8

Symptoms: ORA-600 [kkxprpic8] when executing a query referencing PL/SQL objects. 

This is due to an invalid object being encountered.  Check the underlying trace file generated for any invalid objects and recompile them, e.g. search for "status=INVL", then look above for the object name:

SQLPLUS hangs in linux

Sfat : upgrade la 10.2.0.4

Metalink note id : 361680.1

Cause
Bug.4930777/4612267 SQLPLUS HANGS ON MACHINES WITH LARGE UPTIME -- EVEN SQLPLUS HANGS

which says it happens when machine is up for more than 248 days.

Checked in truss output and uptime output exactly maching these symtoms...


Solution
To implement the solution, please execute the following steps:

1.Download one off patch from metalink for bug 4612267 ( 10.2.0.1 )
2. apply patch and rerun sqlplus.

OR
Reboot Server

Patch Set Update January 2010

Noi release-uri, incepand cu 12 IAN 2010:

• Database 11.1.0.7.2
• Database 10.2.0.4.3  Patch:9119284
• CRS 11.1.0.7.2 Patch:8705958
  
• CRS 10.2.0.4.3 not yet released
  
• Enterprise Manager Grid Control - OMS 10.2.0.5.2
• Enterprise Manager Grid Control - Agent 10.2.0.5.2

Bug 8943287 : ORA-1578 corrupt block with SQL*Net AUTH strings

English translate 

Din nota 976852.1:


Versiuni afectate : Release: 9.2 to 11.2

This has affected different tablespaces but the most common corruption has been in table TRIGGER$ in the SYSTEM tablespace.

DBVerify output / ORA-1578 occurrences or RMAN backups may report the corruption (but not limited to) with description "Bad header found".

Workaround:

To prevent it, set sqlnet.inbound_connect_timeout=0 in the sqlnet.ora for the Oracle Sever where the SQL*Net listener resides.

To repair the block use RMAN Blockrecover or Datafile media recovery.

 In nota  345197.1 se specifica ca incepand cu versiunea 10.2.0.1 , inbound_connect_timeout are valoarea default de 60 (  posibil motiv pentru mesajele din alert log : WARNING: inbound connection timed out (ORA-3136) )

ORA-07445 [kcbs_dump_adv_state+0378] si ORA-00600: [KGHLKREM1]

English translate

Nota de pe metalink.oracle.com care descrie cel mai bine erorile de mai sus : 468456.1.

The bug involves abnormal termination of queries involving bloom filters.
This manifests itself as memory corruptions. The memory was freed, reallocated to some other client, and corrupted but slaves were still writing into it.

Desi apare ca fiind fixata in 10.2.0.4 , eroare se manifesta si in 10.2.0.4.2

Possible Workaround :   alter system set "_bloom_filter_enabled"=false scope=both;

Nasty Bug 7662491 , rezolvat in 10.2.0.4.2

English translate 

Bug-ul de mai jos apare ca rezolvat in versiunea 10.2.0.4.2 de Oracle RDBMS ( database - Patch 8833280 ) . Versiuni afectate pana acum : 10.2.0.3 si 10.2.0.4 .

Pentru windows, bug-ul pare a fi fixat in 10.2.0.4 Patch bundle 25 .

Poate introduce corupere la nivel de redo log, facand astfel imposibil recover-ul folosindu-se rman-ul. Mai mult decat atat, in nota de pe metalink, se specifica clar ca respectivul patch nu rezolva eventualele coruperi deja existente.

De pe metalink.oracle.com (nota 861965.1) :

Bug 7662491 - Array Update can corrupt a row. Errors OERI[kghstack_free1] or OERI[kddummy_blkchk][6110] [Note ID 7662491.8] .

Description : With compatibilty set to 10.2 or higher, a row can be corrupted if it is updated with an Array Update (eg: with plsql FORALL ... UPDATE or an UPDATE of several rows) .

If db_block_checking is set to MEDIUM or FULL we can prevent the corruption going to disk.

Media Recovery like RMAN Blockrecover or "RECOVER DATAFILE" don't fix the corruption as it is already introduced in the Redo/Archived Logs.

Workaround-uri: restore pana in momentul aparitiei coruperii  sau incercarea de recuperare a datelor din tabela afectata, prin dbms_repair .