Upon Oracle’s release of 11g and noticeably with 11g Release 2, Oracle’s functionality is pretty rock solid. What I considered the most obvious weaknesses of the Oracle database engine are now resolved. Namely, bind peaking is resolved with Adaptive Cursor Sharing, and plan stability issues are resolved with SQL Plan Management.

One weakness still remaining with 11g Release 2(11.2.0.1.0) is the 32 character limit in generating histograms for wide character columns. In a nutshell, if you have a column that is wider than 32 characters AND its values are longer than 32 characters, Oracle will only consider the first 32 characters in the column in generating histograms. In other words, if the first 32 characters don’t vary much in all the rows or it’s identical in all rows, then the histograms generated or the absence of them can be way off. As a consequence, the optimizer will make wrong decisions, doing range scans when it shouldn’t, thinking that more rows will match the criteria than there should be.

But this really should be considered a limitation, not a bug. It is a limitation purposely put in place even at 11g Release 2. And it is a reasonable limitation because it is virtually impossible for Oracle to maintain histograms for columns that can be infinitely wide(up to 4000 characters for varchar2 columns). It’ll have to know how many distinct values there are and how many rows there are for each distinct value. So inevitably, Oracle has to draw a line somewhere.

Here’s a more detailed post from Hemant:
http://hemantoracledba.blogspot.com/2009/08/histograms-on-larger-columns.html
It’s a great read. At the time of this writing, the blog tested the limitation as of 11g Release 1. But I’ve tested the limitation with 11g Release 2, and it’s still present.

One workaround that worked for me is to set the column statistics of such a column manually, so that the number of distinct values and density based on the total number of rows in the table. So:

num_distinct = number of rows
density = 1 / number of rows

The following can be run manually if you wanna do it just once.
dbms_stats.set_column_stats(
    ownname=>’{schema}’,
    tabname=>’{table}’,
    colname=>’{column}’,
    distcnt=>’{count}’,
    density=>’{1/count}’
);

The automatic statistic collection may overwrite these columns stats. So to protect against that, on 10g’s Enterprise Manager, a “chain” can be created to contain the statistics collection procedure and the following procedure call immediately following. This will ensure that every time statistics is collected, the columns stats are set. On 11g, however, the automatic statistics collection is more integrated and hidden from us, so I would created so it’s better to schedule a repeating job to set them every n minutes. The following procedure can be reused for other tables when you supply different values for the parameters.

create or replace procedure set_column_stats_for_wide_cols (piOwner in varchar2, piTableName in varchar2, piColumnName in varchar2) as
    vNumDistinct number := 0;
    vDensity number := 0;
    vNumRows number := 0;
begin

    select num_distinct, density
    into vNumDistinct, vDensity
    from dba_tab_col_statistics
    where owner = piOwner
    and table_name = piTableName
    and column_name = piColumnName;

    select num_rows
    into vNumRows
    from dba_tables
    where owner = piOwner
    and table_name = piTableName;

    if vNumDistinct != vNumRows OR vDensity != 1/vNumRows then
        dbms_stats.set_column_stats(
        ownname=>piOwner,
        tabname=>piTableName,
        colname=>picolumnName,
        distcnt=>vNumRows,
        density=>1/vNumRows
    );

    end if;

end;
/

That’ll indicate to Oracle that each value in the column is unique. And it’ll know not to range scan the column.

Don’t expect this limitation to go away for future versions of Oracle. This is particularly true if the histograms are generated after the data is populated. And even if Oracle tries to maintain such stats instantly as data comes in, this will dramatically upset concurrency and scalability. One wilder idea may be to export the column out to an open source relational database or noSQL database, and use methods such as Map/Reduce to determine the number of distinct values. And then set the column stats in Oracle based on it. Not that Oracle cannot do Map/Reduce, doing it in Oracle may compromise other mission critical operations.

dbms_stats.gather_fixed_objects_stats() fails on 11g Release 2(11.2.0.1.0). The bug is witnessed on Standard Edition databases, but should also apply to Enterprise Edition software, per my speculation.

Upon issuing the command, an error is returned:

SQL*Plus: Release 11.2.0.1.0 Production on Wed May 12 16:49:23 2010

Copyright (c) 1982, 2009, Oracle. All rights reserved.

Connected to:
Oracle Database 11g Release 11.2.0.1.0 – 64bit Production

SQL> exec dbms_stats.gather_fixed_objects_stats;
BEGIN dbms_stats.gather_fixed_objects_stats; END;

*
ERROR at line 1:
ORA-20011: Approximate NDV failed: ORA-00439: feature not enabled: Data Guard
Broker
ORA-06512: at “SYS.DBMS_STATS”, line 20508
ORA-06512: at “SYS.DBMS_STATS”, line 20951
ORA-06512: at “SYS.DBMS_STATS”, line 21498
ORA-06512: at line 1

These bugs are involved:
Bug 9180311: GETTING ORA-20011 AND ORA-439 EXECUTING GATHER_FIXED_OBJECTS_STATS
Bug 9056912: GATHERING STATISTICS ON EXTERNAL TABLES REQUIRES NULL FOR ESTIMATE_PERCENT

Patch 9056912 is available for our platform(x86-64). And once applied, the problem is fixed. Note that there are post installation tasks to be carried out.

With the advent of open source relational database platforms, many organizations must be looking at Oracle Enterprise Edition(EE) pricing as outrageous. Not to mention the drying up of budgets in this economy. You can’t do anything for the sunk cost of the existing EE licenses. However, even for new purchases, switching to an entirely different database platform can be impractical. Some companies make compromises and go with Standard Edition, or for single-node installations, Standard Edition ONE.

Here are a few considerations to be taken when choosing to use Standard Edition:

1. Release Management. Strict release procedures should be in place. Database changes should not be released to a production environment running Standard Edition without shutting down the application first. This is particularly true for applications that have a lot of data. The limitations of Standard Edition such as the inability to build index online makes releasing schema changes on-the-fly very difficult.
2. Application Testing. The database should best be running only a few key, well-tested applications, rather than a big assortment of different applications. The lack of Database Resource Manager in SE means that applications are left to consume resources(cpu cycles, etc) freely. A big assortment of different applications particularly those firing ad-hoc or dynamically composed SQL statements is prone to give you grief.
3. Datawarehouses most likely shouldn’t be hosted on an SE database due to the lack of bitmap indexes on SE.
4. Applications that have a lot of data also are not good candidates to run on SE. SE’s lack of multi-channel RMAN backup makes RMAN backups very time consuming for big databases. You can consider other ways of backing up big databases, such as using SAN snapshots. However, RMAN is an essential part of the Oracle backup strategy. So this comes down to hosting only small datasets on SE. How small should it be? Roughly the databases would best be less 300GB. Otherwise, RMAN full backups will take a long long time.
5. Transportable Tablespaces is not available with SE. So as you sync production data to a development database, you’ll have to rely on other utilities such as data pump export/import or the legacy export/import. Those utilities take a long time to dump out and import data.
6. Parallel Operations. All parallel operations are disabled on SE. This applies to parallel query, parallel index creation, parallel data pump export/import, etc, etc.
7. Virtual Private Database(VPD) / Fine Grained Security are not available for SE. This means it’s harder to allow a broader user base and use that feature to automatically make only a subset of data visible based on the users’ credentials/profile.
8. All Options are not available. Options are only available for EE only. So no partitioning, active data guard, advanced compression, etc, etc.

In essence, anything that allows the database to scale is taken off on SE. To be able to live with SE, you have to practice discipline, testing your applications thoroughly and making sure that SQL statements fired at the SE database are not resource-hogging surprises(this one may be tough to do). Manage the release management procedures, shutdown the applications first, then apply database schema changes and build indexes. Keep things simple and small. Huge tables or indexes will definitely give you a lot of problems down the road for SE.

If you go with open source relational database platforms, those certainly have their own limitations. Their pros and cons vary. Some of their features are comparable to Oracle EE. For example, Postgresql can do online index creation whereas Oracle SE cannot. Some are even weaker than Oracle SE. For example, MySQL cannot do a true hotbackup w/o blocking ongoing DMLs.

When a company can afford to purchase Enterprise Edition licenses, functionally it is really the best you can get. But if it’s not feasible and you choose to stick with Oracle by using SE, then you’ll need to prepare to be strict on your procedures and don’t expect you’d have easy solutions when problems happen. Tuning into that mindset would make using SE a lot easier. You really get ONLY what you paid for.

With a Java module that uses the thick client(OCI) to connect through JDBC and initializes a C3P0 connection pool, the module would intermittently crash. Here’s an example of how to reproduce the problem. Of course, you would need C3P0 libraries in your environment.

import java.sql.*;
import com.mchange.v2.c3p0.*;

public class Reproduce {
    public static void main(String[] s)throws Exception {
        Class.forName(“oracle.jdbc.OracleDriver”);
        String url =”jdbc:oracle:oci:@shotspi”;
        try {

            ComboPooledDataSource source = new ComboPooledDataSource();

            java.util.Properties props = new java.util.Properties();
            props.setProperty(“oracle.jdbc.defaultNChar”, “true”);
            source.setProperties(props);

            source.setDriverClass(“oracle.jdbc.OracleDriver”);
            source.setJdbcUrl(url);
            source.setUser(“username”);
            source.setPassword(“password”);
            source.setAutoCommitOnClose(false);
            source.setMaxConnectionAge(100);
            source.setMaxIdleTimeExcessConnections(10);
            source.setMaxPoolSize(10);

            Connection conn = source.getConnection();

            Statement stmt = conn.createStatement();
            ResultSet res= stmt.executeQuery(“select 1 from dual”);
            while(res.next()) {
                System.out.println(res.getString(1));
            }
            conn.close();
        }
        catch(Exception e) {
            e.printStackTrace();
        }
    }
}

#
# A fatal error has been detected by the Java Runtime Environment:
#
# SIGSEGV (0xb) at pc=0x0000002b20ad9399, pid=30445, tid=1088649568
#
# JRE version: 6.0_18-b07
# Java VM: Java HotSpot(TM) 64-Bit Server VM (16.0-b13 mixed mode linux-amd64 )
# Problematic frame:
# C [libclntsh.so.11.1+0x765399] sltskjadd+0xa1
#
# An error report file with more information is saved as:
# ……….hs_err_pid30445.log
#
# If you would like to submit a bug report, please visit:
# http://java.sun.com/webapps/bugreport/crash.jsp
# The crash happened outside the Java Virtual Machine in native code.
# See problematic frame for where to report the bug.
#
ORA-24550: signal received: [si_signo=6] [si_errno=0] [si_code=-6] [si_int=-838819818] [si_ptr=0x101ce00a016] [si_addr=0x22e8000076ed]
kpedbg_dmp_stack()+314<-kpeDbgCrash()+166<-kpeDbgSignalHandler()+158<-skgesig_sigactionHandler()+217<-0000002A95678430<-gsignal()+61<-0000002B1FA7F250<-0000002B1FA7F250<-0000002B1FA7F250<-0000002B1FA7F250<-0000002B1FA7F250<-0000002B1FA7F250<-0000002B1FA7F250<-0000002B1FA7F250<-0000002B1FA7F250<-0000002B1FA7F250<-0000002B1FA7F250<-0000002B1FA7F250<-0000002B1FA7F250<-0000002B1FA7F250<-0000002B1FA7F250<-0000002B1FA7F250<-0000002B1FA7F250<-0000002B1FA7F250<-0000002B1FA7F250
./wrapper.sh: line 12: 30445 Killed /usr/java/jdk1.6-m64/bin/java -classpath ……../ojdbc6.jar:……..c3p0-0.9.1.2.jar Reproduce

Bug 9496209 has been filed for this. At the time of this writing, the bug is still progressing in the hands of Oracle’s Development.

In a nutshell, Hugepages is a way to allow the operating system to reduce the amount of overhead operations needed to map between virtual memory addresses and physical memory addresses. With the default page size of 4KB for the x86 architecture, the amount of mapping operations can be overwhelming when there is a large amount of physical memory in use. With hugepages set, the amount of pages is dramatically reduced and hence the amount of mapping operations also reduced.

AMM was introduced in 11g Release 1 as a capability to shuffle memory between SGA and PGA. When either memory pool is not fully utilized, its spare memory can be used by the other. And this is managed by Oracle automatically.

It is well-known since 11g Release 1 that AMM is not compatible with Hugepages. The effect is that for systems that have a lot of physical memory, you will need to choose between the following 2 options:

1. Use Hugepages and give up using AMM. This forces you to specify a setting for sga_target and pga_aggregate_target. If the database needs more memory in either pools and there is free memory from the other pool, there’ll be no way for Oracle to automatically shuffle memory between the two.
2. Use AMM and give up using Hugepages.

According to a Oracle Support Representative, due to the fact that Hugepages and AMM are so architecturally different, they will most likely not become compatible in the future releases of Oracle.

Seraph Consulting helped China Unicom Americas’ revamp their website. The new website completely reshaped China Unicom Americas’ publicity and received tremendous acceptance from the Headquarters in Beijing.

Before	After

The design of the website allows China Unicom Americas’ staff to maintain their contents easily, including news, events, and career opportunities. The website also serves as an excellent platform to present their products and services offerings.

Visit the new site now

SC