Oracle 11g benefits

Question

Hello Guys
Oracle 11g new features notes as found on web very generic
if i want to convince my client to switch from oracle 10g to oracle 11g,this information will not be useful
if you had migrated to 11g and worked on it,please reply practical reasons from dba point of view
how customer will be benefited from migrating from oracle 10 g to 11g
like if i mentioned to him ADR feature it doesnt makes sense to him
Active dataguard may be one of feature but will be have any benefit where dataguard is implemented
still to application guys also it will give any advantage
say for example i am discussing this with Application team head ,how will he benefit from migrating to 11g
what feature will be benefitted to him and how
will this feature will be appealing enough to efforts in migration
thanks
cheers

Answer 1

In my opinion, the best way to convince them is to do an assessment for their particular environment, based on the specifics.
For example, I've done such one for a database and here are some of the points:
1. Almost 30%(as reported by Grid Control) of frequently executed queries are on tables like XX.XXXX and YY.YYYYY. These tables are relatively small and statements , and functions on them are good candidates for modification to use :
Query Results Cache and PL/SQL Function Result Cache (Oracle 11G Enterprise Edition option, no extra cost needed).
2. From time to time we experience sudden execution plan changes and get worse plans. This degrades applications' performance orders of magnitude. Oracle 11g has a new built-in feature called "SQL Plan Management". As described in the docs:
"SQL plan management prevents performance regressions resulting from sudden changes to the execution plan of a SQL statement by providing components for capturing, selecting, and evolving SQL plan information. If you are performing a database upgrade that installs a new optimizer version, it can result in plan changes for a small percentage of SQL statements, with most of the plan changes resulting in either no performance change or improvement. However, certain plan changes may cause performance regressions.
With SQL plan management, the optimizer automatically manages execution plans and ensures that only known or verified plans are used. When a new plan is found for a SQL statement, the plan is not used until it has been verified by the database to have comparable or better performance than the current plan. This means if you seed SQL plan management with your current (pre-11g) execution plan, which will become the SQL plan baseline for each statement, the optimizer uses these plans after the upgrade. If the 11g optimizer determines that a different plan should be used, the new plan is queued for verification and will not be used until it has been confirmed to have comparable or better performance than the current plan."
I don't expect this to be perfect but at least it will decrease the number of such problematic periods.
3. 10g Recovery Manager doesn't support parallelism per datafile. In our environment we have several 30+GB datafiles and since our storage system is not very fast for such type of operations, non-parallel restore of a single datafile will take much more time compared to the same activity on 11g. 11g supports RMAN datafile restore in parallel.
4. Several optimizations in optimizer work. One of them is better handling of full scans:
We've done some tests 10g/11g and were surprised because of this direct path read/db file scattered reads thing. Our tests are:
Two databases - one 11g and one 10g with same sga_target,sga_max_size(500MB) and pga_aggregate_target(200MB), everything else is as it is set during install by DBCA. These two databases run on one host.
The storage is a NAS(6 discs) managed by 11g ASM (one normal redundancy diskgroup ) which is used by the databases.
I imported a 3GB table on every database and gathered stats. To not go in detail as of now, the results are:
three consecutive runs on 11g.
average execution time - 50 seconds
three consecutive runs on 10g.
average execution time - 125 seconds
The statement is:
select /*+ full(t) nocache(t) */ count(1) from zz.zzz t;
and there is no other activity on the host and the storage.
Same number of logical and physical reads during 11g and 10g runs.
During the above runs while run on:
11g, iostat reports ~14MB/s per disk
10g, iostat reports ~5MB/s per disk
After tracing these sessions we figured out that on 11g direct path read is used, while 10g uses db file scattered read.
5. We can use AUDIT_SYS_OPERATIONS in conjunction with XML,EXTENDED for auditing purposes. 10.2.0.4 has a bug for this that is fix in 11.1.0.6 onwards.
6. Database Resident Connection Pooling(Concepts guide 11g documentation)
"Database Resident Connection Pooling (DRCP) provides a connection pool in the database server for typical Web application usage scenarios. DRCP pools dedicated servers, which comprise of a server foreground combined with a database session, to create pooled servers.
A Web application typically acquires a database connection, uses the connection for a short period, and then releases the connection. DRCP enables multiple Web application threads and processes to share the pooled servers for their connection needs.
DRCP complements middle-tier connection pools that share connections between threads in a middle-tier process. DRCP also enables you to share database connections across multiple middle-tier processes. These middle-tier processes may belong to the same or different middle-tier host.
DRCP enables a significant reduction in key database resources that are required to support a large number of client connections. DRCP reduces the amount of memory required for the database server and boosts the scalability of both the database server and the middle-tier. The pool of readily available servers also reduces the cost of re-creating client connections.
DRCP is especially useful for architectures with multi-process, single-threaded application servers, such as PHP and Apache servers, that cannot do middle-tier connection pooling. The database can scale to tens of thousands of simultaneous connections with DRCP."
It will help us to improve dedicated server usage(currently we use shared server).
7. A lot of bug fixes for bugs that don't have 10g patches , fixed in 11g only and affect us - examples XML,EXTENDED and AUDIT_SYS_OPERATIONS bug, FGA bugs, job system on logical standby database , "ORA-12569: TNS:packet checksum failure" during sqlplus login and so on.
It's for sure that there are much more such convincing points, but a several days assessment will make it possible to identify the most important ones from performance/availability/security perspective for their environment. As it is often the case - the devil is in the details. It's all about the way they use the database.