10g and 9i difference from DB view and DB Administration View

Hi,
I want to know the basic difference between oracle 10g and 9i ....
Reason, is im new to oracle; now im going to learn oracle DB administration side... but in here they still offer Oracle version 9i... (10g is NOT officially available)
what i want to know is whether there is BIG difference between oracle 9i and 10g from the DB Administration view.
These are the things im going to learn:
Introduction to Oracle 9i
Oracle 9i DB Administration Fundermentals-1
Oracle 9i DB Administration Fundermentals-2
Oracle 9i DB Performance Tuning
All will be in Oracle 9i... pls let me know is there big difference between 9i and 10g for the above subject categories.
!!!!

>> I want to know the basic difference between oracle 10g and 9i
You may need to read "Oracle® Database New Features Guide 10g"
http://download.oracle.com/docs/cd/B19306_01/server.102/b14214/toc.htm
but in here they still offer Oracle version 9i... (10g is NOT officially available)Hope you know that Oracle 9i is now disported by Oracle Support.
>> what i want to know is whether there is BIG difference between oracle 9i and
Obviously in every new Oracle Version there are big differences and many new features. Consider reading Oracle Documentation referred, It's not easy to list or two new features here in the forum, one should read about them from documentations.
Regards,
Sabdar Syed.

Similar Messages

Current_date different in forms 10g (variable:=current_date differente from select current_date into varialble)

If in a form, I assign current_date to a variable like ' wdate:=current_date' the variable get incorrect value than if i assign like 'select current_date into wdate from dual'
Why?, current_date is always from database session isn't it?
Thanks for your help.

Hello tony.g
This is the code:
:b11.femovi is a form field date type;
In this code wdate shows differente value than :b11.femovi.
I think that the value must be the same because "current_date" is a database variable isn't it?
declare
wdate date;
begin
:b11.femovi := current_date;
select current_date into wdate from dual;
rutmensaje('date='||to_Char(wdate,'dd/mm/yyyy hh24:MI')||'-'||to_Char(:b11.femovi,'dd/mm/yyyy hh24:MI'));
end;

Difference between Materialised view in 10g and 11g

Hi,
I am beginner . I want to know the difference between Materialized view between 10g and 11g. Is there any impact if the materialized view used in 10g gets upgraded to 11g ?
awaiting ur response.Please and Thanks

In addition to the documentation, you might want to look at the blog of Alberto Dell'Era:
http://www.adellera.it/blog/
Alberto writes quite a bit about materialized views, including this important change in 11GR2:
http://www.adellera.it/blog/2009/11/03/11gr2-materialized-view-logs-changes/

Is there any difference between 10g and 11g M Views?

Hi,
I need to give a demo on and working examples of materialized views. The requirement is this: Master tables are in a 10g R2 DB, MV is in a 11g.
I just create a DB Link in 11g to point to the 10g DB and then create the MV in 11g.
Will there be any problems creating a 11g MV using 10 Master tables?
My question is are there any significant differences between 10g and 11g MViews??
Thanks & Regards,
Channa.

You have to be careful about your versions. 10g could be 10.1 or 10.2 11g could be 11.1 or 11.2
I wouldn't have an 11.2 database with a database link against a 10.1 database.
In fact, even with 10.2, I would try to ensure that I have a "high patchset" (10.2.0.4 or 10.2.0.5) although, in theory, 10.2.0.1 should also work.
See Oracle Support article
Client / Server / Interoperability Support Between Different Oracle Versions [ID 207303.1]
Hemant K Chitale

Difference Between OBIEE 10g and OBIEE 11g

Hi everyone,
I have a doubt when choosing two versions of OBIEE, 10g and 11g.
Actually, is there any big difference between 10g and 11 version ?
From the point of view of easiness finding tutorial in internet, simplicity of using the tool, and other considerations, which one is better ?
I hope you guys could also explain with your arguments.
Thanks

Hi,
Few differences..
Architectures-
OBIEE 11g architecture...http://www.rittmanmead.com/2010/07/09/obiee-11gr1-architecture-and-use-of-weblogic-server/
OBIEE 10g architecture....http://gerardnico.com/wiki/dat/obiee/obiee_overview
Features-
New features in OBIEE11g...Re: OBIEE 11g
http://blogs.oracle.com/robreynolds/2010/07/new_administration_features_of.html
I have a doubt when choosing two versions of OBIEE, 10g and 11g.If you are new to OBIEE its best to start with 10g,there are lot changes in 11g.It takes time to get used to it and you many not get enough docs or material to read,may face some new issues also.
Actually, is there any big difference between 10g and 11 version ? Yes there are some differences between them...you can see them in above links.(many things like graphs,server)
From the point of view of easiness finding tutorial in internet, simplicity of using the tool, and other considerations, which one is better ?For sure obiee 10g as 11g is new many of them just started using it,so you may get less help on this if you face issues & may not get enough tutorial in internet and OBIEE10g is bit easy to use.
Its best to you go for OBIEE10g,parallely you can try 11g.
Regards,
Srikanth
Edited by: Srikanth Mandadi on Oct 7, 2010 11:08 AM

Whats difference between dba_segments in 10g and 11.2

Hi Everyone,
The Space related Queries on DBA_SEGMENTS on 10g is running for more than 10 minutes and the same queries running within 2 seconds 11.2 for same database..
Please some one can explain the differences between 10g and 11.2 on this and is there any improvements in LMT tablespaces in 11.2 because this is issue related to LMT.
Thanks
Vijay

*10.2.0.4*
SQL> explain plan for
2 select owner owner, segment_name segment, a.tablespace_name name, a.next_extent next_extent, a.next_extent/1024/1024 MB, sum(floor(b.bytes/a.next_extent)) avail_extents from dba_SEGMENTS a, dba_FREE_SPACE b where a.tablespace_name = b.tablespace_name   and a.next_extent>0 group by owner, segment_name,a.tablespace_name, a.next_extent having sum(floor(b.bytes/a.next_extent)) < 8 order by 3,6;
Explained.
Elapsed: 00:00:00.45
SQL> select * from table(dbms_xplan.display());
PLAN_TABLE_OUTPUT
Plan hash value: 3420003334
| Id | Operation                           | Name             | Rows | Bytes | Cost (%CPU)| Time     |
|   0 | SELECT STATEMENT                    |                  |    42 | 4998 | 20360 (91)| 00:03:37 |
|   1 | SORT ORDER BY                      |                  |    42 | 4998 | 20360 (91)| 00:03:37 |
|* 2 |   FILTER                            |                  |       |       |            |          |
|   3 |    HASH GROUP BY                    |                  |    42 | 4998 | 20360 (91)| 00:03:37 |
|* 4 |     HASH JOIN                       |                  |    42 | 4998 | 20358 (91)| 00:03:37 |
|   5 |      VIEW                           | SYS_DBA_SEGS     |     3 |   267 | 1520   (1)| 00:00:17 |
|   6 |       UNION-ALL                     |                  |       |       |            |          |
|   7 |        NESTED LOOPS OUTER           |                  |     1 |   291 | 1322   (1)| 00:00:15 |
|   8 |         NESTED LOOPS                |                  |     1 |   261 | 1321   (1)| 00:00:15 |
|   9 |          NESTED LOOPS               |                  |     1 |   205 | 1320   (1)| 00:00:15 |
|* 10 |           HASH JOIN                 |                  |     4 |   596 | 1319   (1)| 00:00:15 |
| 11 |            NESTED LOOPS             |                  |    19 | 1729 |   156   (0)| 00:00:02 |
| 12 |             TABLE ACCESS FULL       | FILE$            |    77 | 2002 |     2   (0)| 00:00:01 |
| 13 |             TABLE ACCESS CLUSTER    | SEG$             |     1 |    65 |     2   (0)| 00:00:01 |
|* 14 |              INDEX RANGE SCAN       | I_FILE#_BLOCK#   |    15 |       |     1   (0)| 00:00:01 |
| 15 |            VIEW                     | SYS_OBJECTS      | 30274 | 1714K| 1162   (1)| 00:00:13 |
| 16 |             UNION-ALL               |                  |       |       |            |          |
|* 17 |              TABLE ACCESS FULL      | TAB$             | 3109 |   197K|   272   (1)| 00:00:03 |
| 18 |              TABLE ACCESS FULL      | TABPART$         |   354 | 18408 |     3   (0)| 00:00:01 |
| 19 |              TABLE ACCESS FULL      | CLU$             |    65 | 3380 |   272   (1)| 00:00:03 |
|* 20 |              TABLE ACCESS FULL      | IND$             | 7364 |   467K|   272   (1)| 00:00:03 |
| 21 |              TABLE ACCESS FULL      | INDPART$         |   970 | 50440 |     5   (0)| 00:00:01 |
|* 22 |              TABLE ACCESS FULL      | LOB$             | 1997 |   126K|   272   (1)| 00:00:03 |
| 23 |              TABLE ACCESS FULL      | TABSUBPART$      | 1000 | 52000 |     6   (0)| 00:00:01 |
| 24 |              TABLE ACCESS FULL      | INDSUBPART$      | 15382 |   781K|    58   (2)| 00:00:01 |
| 25 |              TABLE ACCESS FULL      | LOBFRAG$         |    33 | 1782 |     2   (0)| 00:00:01 |
|* 26 |           TABLE ACCESS CLUSTER      | TS$              |     1 |    56 |     1   (0)| 00:00:01 |
|* 27 |            INDEX UNIQUE SCAN        | I_TS#            |     1 |       |     0   (0)| 00:00:01 |
|* 28 |          TABLE ACCESS BY INDEX ROWID| OBJ$             |     1 |    56 |     1   (0)| 00:00:01 |
|* 29 |           INDEX UNIQUE SCAN         | I_OBJ1           |     1 |       |     0   (0)| 00:00:01 |
| 30 |         TABLE ACCESS CLUSTER        | USER$            |     1 |    30 |     1   (0)| 00:00:01 |
|* 31 |          INDEX UNIQUE SCAN          | I_USER#          |     1 |       |     0   (0)| 00:00:01 |
| 32 |        NESTED LOOPS                 |                  |     1 |   246 |    75   (0)| 00:00:01 |
| 33 |         NESTED LOOPS OUTER          |                  |     1 |   203 |    74   (0)| 00:00:01 |
| 34 |          NESTED LOOPS               |                  |     1 |   173 |    73   (0)| 00:00:01 |
| 35 |           NESTED LOOPS              |                  |    71 | 6745 |     2   (0)| 00:00:01 |
|* 36 |            TABLE ACCESS FULL        | UNDO$            |    76 | 5244 |     2   (0)| 00:00:01 |
|* 37 |            INDEX UNIQUE SCAN        | I_FILE2          |     1 |    26 |     0   (0)| 00:00:01 |
|* 38 |           TABLE ACCESS CLUSTER      | SEG$             |     1 |    78 |     1   (0)| 00:00:01 |
|* 39 |            INDEX UNIQUE SCAN        | I_FILE#_BLOCK#   |     1 |       |     0   (0)| 00:00:01 |
| 40 |          TABLE ACCESS CLUSTER       | USER$            |     1 |    30 |     1   (0)| 00:00:01 |
|* 41 |           INDEX UNIQUE SCAN         | I_USER#          |     1 |       |     0   (0)| 00:00:01 |
|* 42 |         TABLE ACCESS CLUSTER        | TS$              |     1 |    43 |     1   (0)| 00:00:01 |
|* 43 |          INDEX UNIQUE SCAN          | I_TS#            |     1 |       |     0   (0)| 00:00:01 |
| 44 |        NESTED LOOPS                 |                  |     1 |   203 |   123   (0)| 00:00:02 |
| 45 |         NESTED LOOPS OUTER          |                  |     1 |   147 |   122   (0)| 00:00:02 |
| 46 |          NESTED LOOPS               |                  |     1 |   117 |   121   (0)| 00:00:02 |
| 47 |           TABLE ACCESS FULL         | FILE$            |    77 | 3003 |     2   (0)| 00:00:01 |
|* 48 |           TABLE ACCESS CLUSTER      | SEG$             |     1 |    78 |     2   (0)| 00:00:01 |
|* 49 |            INDEX RANGE SCAN         | I_FILE#_BLOCK#   |    15 |       |     1   (0)| 00:00:01 |
| 50 |          TABLE ACCESS CLUSTER       | USER$            |     1 |    30 |     1   (0)| 00:00:01 |
|* 51 |           INDEX UNIQUE SCAN         | I_USER#          |     1 |       |     0   (0)| 00:00:01 |
|* 52 |         TABLE ACCESS CLUSTER        | TS$              |     1 |    56 |     1   (0)| 00:00:01 |
|* 53 |          INDEX UNIQUE SCAN          | I_TS#            |     1 |       |     0   (0)| 00:00:01 |
| 54 |      VIEW                           | DBA_FREE_SPACE   | 1393 | 41790 | 18837 (99)| 00:03:21 |
| 55 |       UNION-ALL                     |                  |       |       |            |          |
| 56 |        NESTED LOOPS                 |                  |     1 |   121 |    11   (0)| 00:00:01 |
| 57 |         NESTED LOOPS                |                  |     1 |    65 |    10   (0)| 00:00:01 |
| 58 |          TABLE ACCESS FULL          | FET$             |     1 |    39 |    10   (0)| 00:00:01 |
|* 59 |          INDEX UNIQUE SCAN          | I_FILE2          |     1 |    26 |     0   (0)| 00:00:01 |
|* 60 |         TABLE ACCESS CLUSTER        | TS$              |     1 |    56 |     1   (0)| 00:00:01 |
| 61 |        NESTED LOOPS                 |                  | 1377 |   158K|    58 (83)| 00:00:01 |
| 62 |         NESTED LOOPS                |                  | 72400 | 6504K|    41 (76)| 00:00:01 |
|* 63 |          TABLE ACCESS FULL          | TS$              |    54 | 4428 |    10   (0)| 00:00:01 |
|* 64 |          FIXED TABLE FIXED INDEX    | X$KTFBFE (ind:1) | 1342 | 13420 |     1 (100)| 00:00:01 |
|* 65 |         INDEX UNIQUE SCAN           | I_FILE2          |     1 |    26 |     0   (0)| 00:00:01 |
| 66 |        NESTED LOOPS                 |                  |    14 | 2324 | 18498 (100)| 00:03:18 |
| 67 |         NESTED LOOPS                |                  |   640 | 89600 | 18498 (100)| 00:03:18 |
|* 68 |          HASH JOIN                  |                  |   640 | 77440 |    59   (2)| 00:00:01 |
| 69 |           TABLE ACCESS FULL         | RECYCLEBIN$      |   651 | 25389 |    48   (0)| 00:00:01 |
|* 70 |           TABLE ACCESS FULL         | TS$              |    54 | 4428 |    10   (0)| 00:00:01 |
|* 71 |          FIXED TABLE FIXED INDEX    | X$KTFBUE (ind:1) |     1 |    19 |    29 (100)| 00:00:01 |
|* 72 |         INDEX UNIQUE SCAN           | I_FILE2          |     1 |    26 |     0   (0)| 00:00:01 |
|* 73 |        HASH JOIN                    |                  |     1 |   173 |   270   (1)| 00:00:03 |
| 74 |         NESTED LOOPS                |                  |     1 |   134 |   221   (1)| 00:00:03 |
| 75 |          NESTED LOOPS               |                  |     1 |    78 |   220   (1)| 00:00:03 |
| 76 |           TABLE ACCESS FULL         | UET$             |     1 |    52 |   220   (1)| 00:00:03 |
|* 77 |           INDEX UNIQUE SCAN         | I_FILE2          |     1 |    26 |     0   (0)| 00:00:01 |
|* 78 |          TABLE ACCESS CLUSTER       | TS$              |     1 |    56 |     1   (0)| 00:00:01 |
|* 79 |           INDEX UNIQUE SCAN         | I_TS#            |     1 |       |     0   (0)| 00:00:01 |
| 80 |         TABLE ACCESS FULL           | RECYCLEBIN$      |   651 | 25389 |    48   (0)| 00:00:01 |
Predicate Information (identified by operation id):
   2 - filter(SUM(FLOOR("B"."BYTES"/"NEXT_EXTENT"))<8)
   4 - access("TABLESPACE_NAME"="B"."TABLESPACE_NAME")
10 - access("S"."FILE#"="SO"."HEADER_FILE" AND "S"."BLOCK#"="SO"."HEADER_BLOCK" AND
              "S"."TS#"="SO"."TS_NUMBER" AND "S"."TYPE#"="SO"."SEGMENT_TYPE_ID")
14 - access("S"."TS#"="F"."TS#" AND "S"."FILE#"="F"."RELFILE#")
17 - filter(BITAND("T"."PROPERTY",1024)=0)
20 - filter("I"."TYPE#"=1 OR "I"."TYPE#"=2 OR "I"."TYPE#"=3 OR "I"."TYPE#"=4 OR "I"."TYPE#"=6
              OR "I"."TYPE#"=7 OR "I"."TYPE#"=8 OR "I"."TYPE#"=9)
22 - filter(BITAND("L"."PROPERTY",64)=0 OR BITAND("L"."PROPERTY",128)=128)
26 - filter(DECODE(BITAND("TS"."FLAGS",3),1,TO_NUMBER(NULL),"S"."EXTSIZE"*"TS"."BLOCKSIZE")>0)
27 - access("S"."TS#"="TS"."TS#")
28 - filter("O"."TYPE#"="SO"."OBJECT_TYPE_ID")
29 - access("O"."OBJ#"="SO"."OBJECT_ID")
31 - access("O"."OWNER#"="U"."USER#"(+))
36 - filter("UN"."STATUS$"<>1)
37 - access("UN"."TS#"="F"."TS#" AND "UN"."FILE#"="F"."RELFILE#")
38 - filter("S"."TYPE#"=1 OR "S"."TYPE#"=10)
39 - access("S"."TS#"="UN"."TS#" AND "S"."FILE#"="UN"."FILE#" AND "S"."BLOCK#"="UN"."BLOCK#")
41 - access("S"."USER#"="U"."USER#"(+))
42 - filter("S"."EXTSIZE"*"TS"."BLOCKSIZE">0)
43 - access("S"."TS#"="TS"."TS#")
48 - filter("S"."TYPE#"<>1 AND "S"."TYPE#"<>5 AND "S"."TYPE#"<>6 AND "S"."TYPE#"<>8 AND
              "S"."TYPE#"<>10)
49 - access("S"."TS#"="F"."TS#" AND "S"."FILE#"="F"."RELFILE#")
51 - access("S"."USER#"="U"."USER#"(+))
52 - filter(DECODE(BITAND("TS"."FLAGS",3),1,TO_NUMBER(NULL),"S"."EXTSIZE"*"TS"."BLOCKSIZE")>0)
53 - access("S"."TS#"="TS"."TS#")
59 - access("F"."TS#"="FI"."TS#" AND "F"."FILE#"="FI"."RELFILE#")
60 - filter("TS"."BITMAPPED"=0 AND "TS"."TS#"="F"."TS#")
63 - filter(("TS"."ONLINE$"=1 OR "TS"."ONLINE$"=4) AND "TS"."CONTENTS$"=0 AND
              "TS"."BITMAPPED"<>0)
64 - filter("TS"."TS#"="F"."KTFBFETSN")
65 - access("F"."KTFBFETSN"="FI"."TS#" AND "F"."KTFBFEFNO"="FI"."RELFILE#")
68 - access("TS"."TS#"="RB"."TS#")
70 - filter(("TS"."ONLINE$"=1 OR "TS"."ONLINE$"=4) AND "TS"."CONTENTS$"=0 AND
              "TS"."BITMAPPED"<>0)
71 - filter("U"."KTFBUESEGTSN"="RB"."TS#" AND "U"."KTFBUESEGFNO"="RB"."FILE#" AND
              "U"."KTFBUESEGBNO"="RB"."BLOCK#")
72 - access("RB"."TS#"="FI"."TS#" AND "U"."KTFBUEFNO"="FI"."RELFILE#")
73 - access("U"."TS#"="RB"."TS#" AND "U"."SEGFILE#"="RB"."FILE#" AND
              "U"."SEGBLOCK#"="RB"."BLOCK#")
77 - access("U"."TS#"="FI"."TS#" AND "U"."SEGFILE#"="FI"."RELFILE#")
78 - filter("TS"."BITMAPPED"=0)
79 - access("TS"."TS#"="U"."TS#")
11.2
SQL> explain plan for
2   select owner owner, segment_name segment, a.tablespace_name name, a.next_extent next_extent, a.next_extent/1024/1024 MB, sum(floor(b.bytes/a.next_extent)) avail_extents from dba_SEGMENTS a, dba_FREE_SPACE b where a.tablespace_name = b.tablespace_name   and a.next_extent>0 group by owner, segment_name,a.tablespace_name, a.next_extent having sum(floor(b.bytes/a.next_extent)) < 8 order by 3,6;
Explained.
SQL> select * from table(dbms_xplan.display());
PLAN_TABLE_OUTPUT
Plan hash value: 1346760999
| Id | Operation                            | Name             | Rows | Bytes | Cost (%CPU)| Time     |
|   0 | SELECT STATEMENT                     |                  |     3 |   333 | 1481   (1)| 00:00:27 |
|   1 | SORT ORDER BY                       |                  |     3 |   333 | 1481   (1)| 00:00:27 |
|* 2 |   FILTER                             |                  |       |       |            |          |
|   3 |    HASH GROUP BY                     |                  |     3 |   333 | 1481   (1)| 00:00:27 |
|* 4 |     HASH JOIN                        |                  | 8243 |   893K| 1479   (1)| 00:00:27 |
|   5 |      VIEW                            | DBA_FREE_SPACE   |   101 | 2626 |    55 (11)| 00:00:01 |
|   6 |       UNION-ALL                      |                  |       |       |            |          |
|   7 |        NESTED LOOPS                  |                  |     1 |    69 |     7   (0)| 00:00:01 |
|   8 |         NESTED LOOPS                 |                  |     1 |    45 |     6   (0)| 00:00:01 |
|   9 |          TABLE ACCESS FULL           | FET$             |     1 |    39 |     6   (0)| 00:00:01 |
|* 10 |          INDEX UNIQUE SCAN           | I_FILE2          |     1 |     6 |     0   (0)| 00:00:01 |
|* 11 |         TABLE ACCESS CLUSTER         | TS$              |     1 |    24 |     1   (0)| 00:00:01 |
| 12 |        NESTED LOOPS                  |                  |    98 | 7350 |    33   (0)| 00:00:01 |
| 13 |         NESTED LOOPS                 |                  |    98 | 6762 |    33   (0)| 00:00:01 |
|* 14 |          TABLE ACCESS FULL           | TS$              |    59 | 1770 |    33   (0)| 00:00:01 |
|* 15 |          FIXED TABLE FIXED INDEX     | X$KTFBFE (ind:1) |     2 |    78 |     0   (0)| 00:00:01 |
|* 16 |         INDEX UNIQUE SCAN            | I_FILE2          |     1 |     6 |     0   (0)| 00:00:01 |
| 17 |        NESTED LOOPS                  |                  |     1 |   140 |    10 (60)| 00:00:01 |
| 18 |         NESTED LOOPS                 |                  |     1 |   134 |    10 (60)| 00:00:01 |
| 19 |          NESTED LOOPS                |                  |     1 |    69 |     4   (0)| 00:00:01 |
| 20 |           TABLE ACCESS FULL          | RECYCLEBIN$      |     1 |    39 |     3   (0)| 00:00:01 |
|* 21 |           TABLE ACCESS CLUSTER       | TS$              |     1 |    30 |     1   (0)| 00:00:01 |
|* 22 |            INDEX UNIQUE SCAN         | I_TS#            |     1 |       |     0   (0)| 00:00:01 |
|* 23 |          FIXED TABLE FIXED INDEX     | X$KTFBUE (ind:1) |   100K| 6347K|     6 (100)| 00:00:01 |
|* 24 |         INDEX UNIQUE SCAN            | I_FILE2          |     1 |     6 |     0   (0)| 00:00:01 |
| 25 |        NESTED LOOPS                  |                  |     1 |   121 |     5   (0)| 00:00:01 |
| 26 |         NESTED LOOPS                 |                  |     1 |    97 |     4   (0)| 00:00:01 |
| 27 |          MERGE JOIN CARTESIAN        |                  |     1 |    45 |     4   (0)| 00:00:01 |
| 28 |           TABLE ACCESS FULL          | RECYCLEBIN$      |     1 |    39 |     3   (0)| 00:00:01 |
| 29 |           BUFFER SORT                |                  |    78 |   468 |     1   (0)| 00:00:01 |
| 30 |            INDEX FULL SCAN           | I_FILE2          |    78 |   468 |     1   (0)| 00:00:01 |
| 31 |          TABLE ACCESS CLUSTER        | UET$             |     1 |    52 |     0   (0)| 00:00:01 |
|* 32 |           INDEX UNIQUE SCAN          | I_FILE#_BLOCK#   |     1 |       |     0   (0)| 00:00:01 |
|* 33 |         TABLE ACCESS CLUSTER         | TS$              |     1 |    24 |     1   (0)| 00:00:01 |
|* 34 |          INDEX UNIQUE SCAN           | I_TS#            |     1 |       |     0   (0)| 00:00:01 |
| 35 |      VIEW                            | SYS_DBA_SEGS     | 4897 |   406K| 1423   (1)| 00:00:26 |
| 36 |       UNION-ALL                      |                  |       |       |            |          |
| 37 |        NESTED LOOPS OUTER            |                  |     1 |   158 | 1128   (1)| 00:00:21 |
| 38 |         NESTED LOOPS                 |                  |     1 |   141 | 1127   (1)| 00:00:21 |
| 39 |          NESTED LOOPS                |                  |     1 |   120 | 1126   (1)| 00:00:21 |
|* 40 |           HASH JOIN                  |                  |     3 |   246 | 1120   (1)| 00:00:21 |
| 41 |            NESTED LOOPS              |                  | 36056 |   845K|   122   (0)| 00:00:03 |
| 42 |             INDEX FULL SCAN          | I_FILE2          |    78 |   468 |     1   (0)| 00:00:01 |
| 43 |             TABLE ACCESS CLUSTER     | SEG$             |   462 | 8316 |     2   (0)| 00:00:01 |
|* 44 |              INDEX RANGE SCAN        | I_FILE#_BLOCK#   |     1 |       |     1   (0)| 00:00:01 |
| 45 |            VIEW                      | SYS_OBJECTS      | 39147 | 2217K|   997   (1)| 00:00:18 |
| 46 |             UNION-ALL                |                  |       |       |            |          |
|* 47 |              TABLE ACCESS FULL       | TAB$             | 4543 |   102K|   237   (0)| 00:00:05 |
| 48 |              TABLE ACCESS FULL       | TABPART$         |   424 | 6784 |     4   (0)| 00:00:01 |
| 49 |              TABLE ACCESS FULL       | CLU$             |    10 |   140 |   237   (0)| 00:00:05 |
|* 50 |              TABLE ACCESS FULL       | IND$             | 11060 |   205K|   237   (0)| 00:00:05 |
| 51 |              TABLE ACCESS FULL       | INDPART$         |   587 | 9392 |     5   (0)| 00:00:01 |
|* 52 |              TABLE ACCESS FULL       | LOB$             |   938 | 17822 |   234   (0)| 00:00:05 |
| 53 |              TABLE ACCESS FULL       | TABSUBPART$      |   968 | 15488 |     5   (0)| 00:00:01 |
| 54 |              TABLE ACCESS FULL       | INDSUBPART$      | 20616 |   322K|    33   (0)| 00:00:01 |
| 55 |              TABLE ACCESS FULL       | LOBFRAG$         |     1 |    17 |     3   (0)| 00:00:01 |
| 56 |           TABLE ACCESS BY INDEX ROWID| OBJ$             |     1 |    38 |     2   (0)| 00:00:01 |
|* 57 |            INDEX RANGE SCAN          | I_OBJ1           |     1 |       |     1   (0)| 00:00:01 |
|* 58 |          TABLE ACCESS CLUSTER        | TS$              |     1 |    21 |     1   (0)| 00:00:01 |
|* 59 |           INDEX UNIQUE SCAN          | I_TS#            |     1 |       |     0   (0)| 00:00:01 |
| 60 |         TABLE ACCESS CLUSTER         | USER$            |     1 |    17 |     1   (0)| 00:00:01 |
|* 61 |          INDEX UNIQUE SCAN           | I_USER#          |     1 |       |     0   (0)| 00:00:01 |
|* 62 |        HASH JOIN OUTER               |                  |    21 | 2121 |   133   (1)| 00:00:03 |
| 63 |         NESTED LOOPS                 |                  |    21 | 1764 |   128   (0)| 00:00:03 |
| 64 |          NESTED LOOPS                |                  |    21 | 1323 |   107   (0)| 00:00:02 |
| 65 |           NESTED LOOPS               |                  |    21 | 1197 |   107   (0)| 00:00:02 |
|* 66 |            TABLE ACCESS FULL         | UNDO$            |   104 | 3640 |     3   (0)| 00:00:01 |
|* 67 |            TABLE ACCESS CLUSTER      | SEG$             |     1 |    22 |     1   (0)| 00:00:01 |
|* 68 |             INDEX UNIQUE SCAN        | I_FILE#_BLOCK#   |     1 |       |     0   (0)| 00:00:01 |
|* 69 |           INDEX UNIQUE SCAN          | I_FILE2          |     1 |     6 |     0   (0)| 00:00:01 |
|* 70 |          TABLE ACCESS CLUSTER        | TS$              |     1 |    21 |     1   (0)| 00:00:01 |
|* 71 |           INDEX UNIQUE SCAN          | I_TS#            |     1 |       |     0   (0)| 00:00:01 |
| 72 |         TABLE ACCESS FULL            | USER$            |   111 | 1887 |     4   (0)| 00:00:01 |
|* 73 |        HASH JOIN RIGHT OUTER         |                  | 4875 |   328K|   162   (1)| 00:00:03 |
| 74 |         TABLE ACCESS FULL            | USER$            |   111 | 1887 |     4   (0)| 00:00:01 |
|* 75 |         HASH JOIN                    |                  | 4875 |   247K|   158   (1)| 00:00:03 |
| 76 |          TABLE ACCESS FULL           | TS$              |    60 | 1260 |    33   (0)| 00:00:01 |
| 77 |          NESTED LOOPS                |                  | 4875 |   147K|   124   (0)| 00:00:03 |
| 78 |           TABLE ACCESS FULL          | FILE$            |    78 |   702 |     3   (0)| 00:00:01 |
|* 79 |           TABLE ACCESS CLUSTER       | SEG$             |    62 | 1364 |     2   (0)| 00:00:01 |
|* 80 |            INDEX RANGE SCAN          | I_FILE#_BLOCK#   |     1 |       |     1   (0)| 00:00:01 |
Predicate Information (identified by operation id):
   2 - filter(SUM(FLOOR("B"."BYTES"/"NEXT_EXTENT"))<8)
   4 - access("TABLESPACE_NAME"="B"."TABLESPACE_NAME")
10 - access("F"."TS#"="FI"."TS#" AND "F"."FILE#"="FI"."RELFILE#")
11 - filter("TS"."BITMAPPED"=0 AND "TS"."TS#"="F"."TS#")
14 - filter("TS"."CONTENTS$"=0 AND "TS"."BITMAPPED"<>0 AND ("TS"."ONLINE$"=1 OR
              "TS"."ONLINE$"=4))
15 - filter("TS"."TS#"="F"."KTFBFETSN")
16 - access("F"."KTFBFETSN"="FI"."TS#" AND "F"."KTFBFEFNO"="FI"."RELFILE#")
21 - filter("TS"."CONTENTS$"=0 AND "TS"."BITMAPPED"<>0 AND ("TS"."ONLINE$"=1 OR
              "TS"."ONLINE$"=4))
22 - access("TS"."TS#"="RB"."TS#")
23 - filter("U"."KTFBUESEGTSN"="RB"."TS#" AND "U"."KTFBUESEGFNO"="RB"."FILE#" AND
              "U"."KTFBUESEGBNO"="RB"."BLOCK#")
24 - access("RB"."TS#"="FI"."TS#" AND "U"."KTFBUEFNO"="FI"."RELFILE#")
32 - access("U"."TS#"="RB"."TS#" AND "U"."SEGFILE#"="RB"."FILE#" AND
              "U"."SEGBLOCK#"="RB"."BLOCK#")
       filter("U"."TS#"="FI"."TS#" AND "U"."SEGFILE#"="FI"."RELFILE#")
33 - filter("TS"."BITMAPPED"=0)
34 - access("TS"."TS#"="U"."TS#")
40 - access("S"."FILE#"="SO"."HEADER_FILE" AND "S"."BLOCK#"="SO"."HEADER_BLOCK" AND
              "S"."TS#"="SO"."TS_NUMBER" AND "S"."TYPE#"="SO"."SEGMENT_TYPE_ID")
44 - access("S"."TS#"="F"."TS#" AND "S"."FILE#"="F"."RELFILE#")
47 - filter(BITAND("T"."PROPERTY",1024)=0)
50 - filter("I"."TYPE#"=1 OR "I"."TYPE#"=2 OR "I"."TYPE#"=3 OR "I"."TYPE#"=4 OR "I"."TYPE#"=6
              OR "I"."TYPE#"=7 OR "I"."TYPE#"=8 OR "I"."TYPE#"=9)
52 - filter(BITAND("L"."PROPERTY",64)=0 OR BITAND("L"."PROPERTY",128)=128)
57 - access("O"."OBJ#"="SO"."OBJECT_ID" AND "O"."TYPE#"="SO"."OBJECT_TYPE_ID")
       filter("O"."TYPE#"="SO"."OBJECT_TYPE_ID")
58 - filter("S"."EXTSIZE"*"TS"."BLOCKSIZE">0)
59 - access("S"."TS#"="TS"."TS#")
61 - access("O"."OWNER#"="U"."USER#"(+))
62 - access("S"."USER#"="U"."USER#"(+))
66 - filter("UN"."STATUS$"<>1)
67 - filter("S"."TYPE#"=1 OR "S"."TYPE#"=10)
68 - access("S"."TS#"="UN"."TS#" AND "S"."FILE#"="UN"."FILE#" AND "S"."BLOCK#"="UN"."BLOCK#")
69 - access("UN"."TS#"="F"."TS#" AND "UN"."FILE#"="F"."RELFILE#")
70 - filter("S"."EXTSIZE"*"TS"."BLOCKSIZE">0)
71 - access("S"."TS#"="TS"."TS#")
73 - access("S"."USER#"="U"."USER#"(+))
75 - access("S"."TS#"="TS"."TS#")
       filter("S"."EXTSIZE"*"TS"."BLOCKSIZE">0)
79 - filter("S"."TYPE#"<>6 AND "S"."TYPE#"<>5 AND "S"."TYPE#"<>8 AND "S"."TYPE#"<>10 AND
              "S"."TYPE#"<>1)
80 - access("S"."TS#"="F"."TS#" AND "S"."FILE#"="F"."RELFILE#")
135 rows selected.
SQL>

Difference in select for update of - in Oracle Database 10g and 11g

Hi, I found out that Oracle Database 10g and 11g treat the following PL/SQL block differently (I am using scott schema for convenience):
DECLARE
  v_ename bonus.ename%TYPE;
BEGIN
  SELECT b.ename
    INTO v_ename
    FROM bonus b
    JOIN emp e ON b.ename = e.ename
    JOIN dept d ON d.deptno = e.deptno
   WHERE b.ename = 'Scott'
     FOR UPDATE OF b.ename;
END;
/While in 10g (10.2) this code ends successfully (well NO_DATA_FOUND exception is raised but that is expected), in 11g (11.2) it raises exception "column ambiguously defined". And that is definitely not expected. It seems like it does not take into account table alias because I found out that when I change the column in FOR UPDATE OF e.empno (also does not work) to e.mgr (which is unique) it starts working. So is this some error in 11g? Any thoughts?
Edited by: Libor Nenadál on 29.4.2010 21:46
It seems that my question was answered here - http://stackoverflow.com/questions/2736426/difference-in-select-for-update-of-in-oracle-database-10g-and-11g

The behaviour seems like it really is a bug and can be avoided using non-ANSI syntax. (It makes me wonder why Oracle maintains two query languages while dumb me thinks that this is just a preprocessor matter and query engine could be the same).

Differences Between Entry View and GL View - Doc. Splitting

Hello Experts,
I need some help about an issue occuring in our Client right now, differences in Entry view and GL View. Any help will be appreciated.
- Debit or Credit Balance posting of an account does not match with the balance posted in GL View, generally the GL view posts an amount above of the Entry view, and then it cause the Debit/Credit balance does not match with the movement in Entry View. Example Below from Quality System:
Debit Balance in January 2013: 319.794.641,38
Movement from FAGLL03 - OK.
Movement from FBL3N - Entry View Difference: 319.794.619,86 - 319.794,641,38 = 21,52 Debit
Checking NEW-GL Movement, we found the posting difference:
The Document Entry View: 5.465,22 Credit From Bank Account
The GL View - SAP Credited 5.486,74 Bank Account PC 1411 and Cr Bank Account PC 1444.
Total: -5.486,74 + 21,52 = 5.465,22 OK on Balance, but not OK from movement considering the Entry view.
- Questions:
- I understood the calculations, it was calculated as mentioned in note 1072850_Field overflow or very large amounts due to doc splitting
- Is this supposed to happen by SAP Doc.Splitting perspective?
- I am facing this issue because we need to send to the government account balances and their movements, and according to laws we need to pay additional amount for addtional lines generated, so it was better to send the information based in Entry View, not in GL View.
- FS10N Show warning message "New general Ledger Implemented, use FAGLB03", and when i execute the transaction the balance showed was the balance from FAGLB03.
- SAP 605 APPL.
Regards,
Leandro.

Hi ,
Can you Please look at OSS note
1655571 - Multiple values and multiple/additional line items appearing in the NewGL View when compared to Entry View
Many Thanks

Issue with materialized view and fast refresh between Oracle 10g and 11g

Hi all,
I've hit a problem when trying to create a fast-refreshable materialized view.
I've got two databases, one 10.2.0.10, another 11.2.0.1.0, running on 32-bit Windows. Both are enterprise edition, and I'm trying to pull data from the 10g one into the 11g one. I can happily query across the database link from 11g to 10g, and can use complete refresh with no problem except the time it takes.
On the 10g side, I've got tables with primary keys and m.v. logs created, the logs being of this form ...
CREATE MATERIALIZED VIEW LOG ON table WITH PRIMARY KEY INCLUDING NEW VALUES
On the 11g side, when I try to create an m.v. against that ...
CREATE MATERIALIZED VIEW mv_table REFRESH FAST WITH PRIMARY KEY AS SELECT col1, col2 FROM table@dblink;
... I get an ORA-12028 error (materialized view type is not supported by master site).
After running the EXPLAIN_MVIEW procedure it shows this;
REFRESH_FAST_AFTER_INSERT not supported for this type mv by Oracle version at master site
A colleague has managed to build a fast-refresh m.v. from the same source database, but pulling to a different one than I'm using; his target is also 10g, like the (common) source, so I've no idea why I'm getting the 'not supported' message whilst he isn't.
I've been able, on previous projects, to do exactly what I'm trying to achieve but on those someone with more knowledge than me has configured the database!
I'm now stumped. I'm also no DBA but despite that it's been left to me to install the new 11g database on the 32-bit Windows server from scratch, so there are probably a couple of things I'm missing. It's probably something really obvious but I don't really know where to look now.
If anyone can give me any pointers at all, I'd be really grateful. This question is also duplicated in the Replication forum but hasn't had any replies as yet, so I'm reproducing it here in hope!
Thanks in advance,
Steve

Hi Steve,
You should have a look at metalink, Doc ID 1059547.1
If that does not help, there may be something else in Mater note ID 1353040.1
Best regards
Peter

Difference between oracle bpm 10g and 11g

Newbie: I am trying to understand 10g. The basic questions I have is
1)What is the difference between 10g and 11g?
2)What is the infrastructure & skillset needed for me to do implementation in 10g?
3)How is migration from 10g to 11g is accomplished?
Any resource links that would help me to get started with 10g would be appreciated.
Chaitanya

Hi,
Please follow the below mentioned link to find your answer.
Re: Main differences between oracle bpm 10.3 vs 11g
Migration from ALBPM 5.7 to BPM 11g
Bibhu

How to join three tables and practical difference between 10g and 11g

I want to know with example how to outer join three different tables in Oracle.
Also if you have any website or reference for understand syntax or performance difference between 10g and 11g then please paste a link in.thanks!!

Hi,
897293 wrote:
I want to know with example how to outer join three different tables in Oracle.The 3rd table comes into the result set the same way the 2nd one did:
FROM           table_1 t1
LEFT OUTER JOIN      table_2 t2 ON   ...
LEFT OUTER JOIN      table_3 t3 ON   ...The join condition(s) for t3 can reference t1, or t2, or both.
Also if you have any website or reference for understand syntax or performance difference between 10g and 11g then please paste a link in.thanks!!The main manuals all have "What's New" sections near the beginning. For example:
http://download.oracle.com/docs/cd/B28359_01/server.111/b28286/wnsql.htm#sthref5
Hoek,
We've missed you. Welcome back!

NVL in view: discrepancy between 10G and 11G

Hi,
I've discovered some discrepancy between 10G and 11G in a way how view deals with NVL-based column in a where clause.
Here are two examples:
*10G:*
Connected to:
Oracle Database 10g Release 10.2.0.4.0 - Production
SQL> create table test_nvl (null_column number);
Table created.
SQL> insert into test_nvl values (null);
1 row created.
SQL> commit;
Commit complete.
SQL> create view view_nvl as select nvl(null_column,0) null_column from test_nvl;
View created.
SQL> select * from view_nvl where null_column is not null and null_column = 0;
NULL_COLUMN
0
*11G*
Connected to:
Oracle Database 11g Release 11.2.0.1.0 - 64bit Production
SQL> create table test_nvl (null_column number);
Table created.
SQL> insert into test_nvl values (null);
1 row created.
SQL> commit;
Commit complete.
SQL> create view view_nvl as select nvl(null_column,0) null_column from test_nvl;
View created.
SQL> select * from view_nvl where null_column is not null and null_column = 0;
no rows selected
Does anyone know why it behaves differently?
I couldn't find any documentation regarding this.
Or I'm just missing something here.
Thanks

BANNER
Oracle Database 11g Enterprise Edition Release 11.2.0.2.0 - 64bit Production
PL/SQL Release 11.2.0.2.0 - Production
CORE     11.2.0.2.0     Production
TNS for HPUX: Version 11.2.0.2.0 - Production
NLSRTL Version 11.2.0.2.0 - Production
CREATE TABLE test_nvl (null_column NUMBER);
INSERT INTO test_nvl
     VALUES (NULL);
COMMIT;
CREATE VIEW view_nvl
AS
   SELECT NVL (null_column, 0) null_column FROM test_nvl;
SELECT *
FROM view_nvl
WHERE null_column IS NOT NULL AND null_column = 0;
NULL_COLUMN
0

Difference between 10g and 11g OEM

Hi,
I would like to know what is the difference between 10g and 11g Grid control. Unfortunately I have worked only on 11g Grid Control. So do not not what exactly are the differences like from GUI features,installation steps.
Thank you....

Hi,
From 11g grid Weblogic also introduced. You can refer this below note for understanding even architecture.
*Understanding the Enterprise Manager 10g and 11g Grid Control Management Agent, Directory Structure and Key Configuration Files. [ID 234872.1]*

Client-side Memory leak while executing PL/SQL and reading from a view

Iam noticing memory leaks in OCCI while performing the following:
Sample function()
1. Obtain a connection
2. Create a statement to execute a PL/SQL procedure
3 Execute the statement created in step #2
4. Terminate the statement created in step #2
5. Create a statement to read from a view which was populated
by executing stored procedure in step #3
6. Execute the statement created in step #5
7. Terminate the statement created in step #5
8. Release the connection
The PL/SQL populates a view with fixed 65,000 records for every execution. PL/SQL opens a cursor, loads 65000 records and populates the target view and closes the cursor at the end. If i invoke the above function it results in memory leak of 4M for every call. I tried several variants such as:
1. Disabling statement caching
2. Using setSQL instead of newly creating second SQL statement
3. Obtaining two separate connections for these two activities (PL/SQL exec and View read)
4. Breaking the sample function into two, one for each of these activities (PL/SQL exec and View read).
All the combinations results in the same behaviour of 4M memory leak.
Iam using Oracle 10g Client/Server 10.2.0.1.0.
Is there any known limitations in this area?

Yes. Iam closing the result set and terminating the statement.
My program contains layers of inhouse wrapper classes, which will take some time for
me to present it in pure OCCI calls, to be posted here for your understanding.
After some more debugging, i found that if the connection level statement caching is set to
0, the memory leak is much lower than before.
Thanks.
Message was edited by:
user498920

Print report parameter and column headers PDF format from Discoverer Viewer

Hi,
From Discoverer Viewer 4i I'm presently using the printer friendly version to print my workbooks. I would like to know if their is a way to include report parameters and print column headers on every page.
I would appreciate any pointers or workarounds to this issue at the earliest.
Thanks
T

Hi T
I don't think this is possible with 4i.
Have you considered upgrading to 10g R2?
Best wishes
Michael

10g and 9i difference from DB view and DB Administration View

Similar Messages

Maybe you are looking for