Blog

  • DBA_TAB_COLUMNS vs DBA_TAB_COLS

    Not sure how many DBAs have noticed the difference between DBA_TAB_COLUMNS view and DBA_TAB_COLS view. Both views look pretty identical, if you are not paying too much attention. According to Oracle documentation, DBA_TAB_COLS describes the columns of all tables, views, and clusters in the database. This view differs from “DBA_TAB_COLUMNS” in that system-generated hidden columns and invisible columns, which are user-generated hidden columns, are not filtered out.

    Let me dig a little deep to understand the differences better. First, how the views are built…

    Until 11gR2, DBA_TAB_COLS view is a complex SQL joining multiple internal dictionary tables. The FROM clause is shown here…

    The FROM clause of DBA_TAB_COLS view in 10gR2 is…

    --10gR2 
    SQL> set long 32000 
    SQL> select text from dba_views 
         where view_name = 'DBA_TAB_COLS'; 
     
         from sys.col$ c, sys.obj$ o, sys.hist_head$ h, sys.user$ u, 
              sys.coltype$ ac, sys.obj$ ot, sys.user$ ut 
    

    The FROM clause of DBA_TAB_COLS view in 11gR2 is…

    --11gR2
    SQL> select text from dba_views 
         where view_name = 'DBA_TAB_COLS';
    
         from sys.col$ c, sys."_CURRENT_EDITION_OBJ" o, sys.hist_head$ h, 
         sys.user$ u, sys.coltype$ ac, sys.obj$ ot, 
         sys."_BASE_USER" ut, sys.tab$ t
    

    Because of the increased complexity by introducing new features like invisible columns, I think Oracle decided to create an intermediate view named DBA_TAB_COLS_V$ to make the SQL for DBA_TAB_COLS simpler in 12c. The view SQL for SYS.DBA_TAB_COLS_V$ is similar to the SQL used in DBA_TAB_COLS in 11gR2, but has more lines.

    So, in 12c, the DBA_TAB_COLS view is a straight SELECT of columns from DBA_TAB_COLS_V$ without any WHERE clause.

    In all versions the DBA_TAB_COLUMNS is a query on selected columns from DBA_TAB_COLS with a WHERE clause to filter the hidden columns. In 10g and 11g, the WHERE clause is where HIDDEN_COLUMN = ‘NO’ and in 12c the WHERE clause changed to where USER_GENERATED = ‘YES’.

    Full SQL used for the DBA_TAB_COLUMNS view in 12c is below.

    --12cR1
    SQL> set long 32000
    SQL> select text from dba_views where view_name = 'DBA_TAB_COLUMNS';
    
    TEXT
    ----------------------------------------------------------------------
    select OWNER, TABLE_NAME,
    COLUMN_NAME, DATA_TYPE, DATA_TYPE_MOD, DATA_TYPE_OWNER,
    DATA_LENGTH, DATA_PRECISION, DATA_SCALE, NULLABLE, COLUMN_ID,
    DEFAULT_LENGTH, DATA_DEFAULT, NUM_DISTINCT, LOW_VALUE, HIGH_VALUE,
    DENSITY, NUM_NULLS, NUM_BUCKETS, LAST_ANALYZED, SAMPLE_SIZE,
    CHARACTER_SET_NAME, CHAR_COL_DECL_LENGTH,
    GLOBAL_STATS, USER_STATS, AVG_COL_LEN, CHAR_LENGTH, CHAR_USED,
    V80_FMT_IMAGE, DATA_UPGRADED, HISTOGRAM, DEFAULT_ON_NULL,
    IDENTITY_COLUMN, SENSITIVE_COLUMN,
    EVALUATION_EDITION, UNUSABLE_BEFORE, UNUSABLE_BEGINNING
    from DBA_TAB_COLS
    where USER_GENERATED = 'YES'

    Which columns are available in DBA_TAB_COLS that are not in DBA_TAB_COLUMNS? Following query shows the columns that are additional in DBA_TAB_COLS in 12cR1.

    SQL> select column_name from dba_tab_cols 
         where table_name = 'DBA_TAB_COLS'
         minus
         select column_name from dba_tab_cols 
         where table_name = 'DBA_TAB_COLUMNS';
    
    COLUMN_NAME
    -----------------------------
    HIDDEN_COLUMN
    INTERNAL_COLUMN_ID
    QUALIFIED_COL_NAME
    SEGMENT_COLUMN_ID
    USER_GENERATED
    VIRTUAL_COLUMN

    USER_GENERATED column is new in 12c, all other columns are same in 11gR2/10gR2 as well.

    When you mark a column in table as UNUSED (that is a candidate for drop), it becomes hidden in 11gR2. Is Hidden Column different from Invisible Column in 12c DBA_TAB_COLS?

    Let me create a table with the following characteristics. Columns 1, 4 & 7 are regular columns with no speciality. x2 is invisible, x3 is virtual, x5 is invisible and virtual, x6 is identity.

    SQL> create table hidden_test (
         x1 number,
         x2 number invisible,
         x3 number generated always as (x1/2) virtual,
         x4 number,
         x5 number invisible generated always as (x1/4) virtual,
         x6 number generated always as identity,
         x7 number );
    
    Table created.

    Query the column properties of the table just created.

    SQL> col column_name format a5
    SQL> select column_name, user_generated, virtual_column, hidden_column, 
                identity_column, column_id, segment_column_id, internal_column_id
         from dba_tab_cols
         where table_name = 'HIDDEN_TEST';
    
    COLUM USE VIR HID IDE  COLUMN_ID SEGMENT_COLUMN_ID INTERNAL_COLUMN_ID
    ----- --- --- --- --- ---------- ----------------- ------------------
    X7    YES NO  NO  NO           5                 5                  7
    X6    YES NO  NO  YES          4                 4                  6
    X5    YES YES YES NO                                                5
    X4    YES NO  NO  NO           3                 3                  4
    X3    YES YES NO  NO           2                                    3
    X2    YES NO  YES NO                             2                  2
    X1    YES NO  NO  NO           1                 1                  1
    
    7 rows selected.

    Notice all columns have USER_GENERATED as YES, which means all of these columns will be visible in DBA_TAB_COLUMNS. Remeber, this is the filter condition for DBA_TAB_COLUMNS, so for all subsequent queries on DBA_TAB_COLS, if USER_GENERATED is NO, those columns will not be visible in DBA_TAB_COLUMNS. [[I would have liked to see VIRTUAL_COLUMN (HIDDEN_COLUMN too) as part of DBA_TAB_COLUMNS, they would have added some useful information to DBA_TAB_COLUMNS.]] Virtual column information is included in DBA_TAB_COLUMNS, but does not identify if the column is VIRTUAL or not. The invisible columns are marked as HIDDEN_COLUMN=YES. Now, mark x4 for drop and x2 visible.

    SQL> alter table hidden_test set unused (x4);
    
    Table altered.
    
    SQL> alter table hidden_test modify x2 visible;
    
    Table altered.
    
    SQL>

    Query the properties again…

    SQL> select column_name, user_generated, virtual_column, hidden_column, 
                identity_column, column_id, segment_column_id, internal_column_id
         from dba_tab_cols
         where table_name = 'HIDDEN_TEST';
    
    COLUMN_NAM USE VIR HID IDE  COLUMN_ID SEGMENT_COLUMN_ID INTERNAL_COLUMN_ID
    ---------- --- --- --- --- ---------- ----------------- ------------------
    X7         YES NO  NO  NO           4                 5                  7
    X6         YES NO  NO  YES          3                 4                  6
    X5         YES YES YES NO                                                5
    SYS_C00004 NO  NO  YES NO                             3                  4
    _14060322:
    52:06$
    
    X3         YES YES NO  NO           2                                    3
    X2         YES NO  NO  NO           5                 2                  2
    X1         YES NO  NO  NO           1                 1                  1
    
    7 rows selected.

    The x4 column name marked for drop got renamed, and got a system generated name. The rename is to facilitate adding a column with same name to the table. The column x4 also got property changes – USER_GENERATED became NO and HIDDEN_COLUMN changed to YES. Also, the COLUMN_ID is released, thus the column will not be visilbe in “SELECT *” and “DESCRIBE”. The UNUSED column still maintains the same INTERNAL_COLUMN_ID.

    When x2 column is made VISIBLE, it got a new COLUMN_ID assigned (the highest available, thus the column becomes the last column in “SELECT *” and “DESCRIBE”). Its hidden status changed to NO.

    What happens to the ID columns, when the UNUSED column is dropped.

    SQL> alter table hidden_test drop unused columns;
    
    Table altered.
    
    SQL> select column_name, user_generated, virtual_column, hidden_column, 
                identity_column, column_id, segment_column_id, internal_column_id
         from dba_tab_cols
         where table_name = 'HIDDEN_TEST';
    
    COLUMN_NAM USE VIR HID IDE  COLUMN_ID SEGMENT_COLUMN_ID INTERNAL_COLUMN_ID
    ---------- --- --- --- --- ---------- ----------------- ------------------
    X7         YES NO  NO  NO           4                 4                  6
    X6         YES NO  NO  YES          3                 3                  5
    X5         YES YES YES NO                                                4
    X3         YES YES NO  NO           2                                    3
    X2         YES NO  NO  NO           5                 2                  2
    X1         YES NO  NO  NO           1                 1                  1
    

    The COLUMN_ID got reordered after the unused column is dropped (X4 was dropped, hence X6 and X7 got new column ids – X5 never had a column id assigned as it is INVISIBLE). The internal column id, which includes id for INVISIBLE columns also got adjusted. After the column is dropped, the INTERNAL_COLUMN_ID also got adjusted.

    Well, I started with just difference between DBA_TAB_COLS and DBA_TAB_COLUMNS, but got into investigating column ids… 🙂

    [amazon text=Amazon&template=carousel&asin=111864395X]

  • Is Oracle Enterprise Manager (OEM) Free?

    I am pretty sure most DBAs and Architects get this question very often. The information is available in the Oracle Enterprise Manager (OEM) documentation, this is a compilation I thought of sharing, might benefit someone out there without spending too much time searching.

    When someone says OEM, it could be OEM that comes with database (called OEM Database Control in 11g and called OEM Database Express in 12c), or it could mean OEM used to manage multiple databases and hosts (in 11g, known as OEM Grid Control and in 12c known as OEM Cloud Control – this OEM 11g/12c versions are totally different from the database versions). So, have I confused you enough already?  Oracle uses “OEM”, “11g”, “12c” for two products. Let me try to clear this up… (hopefully!).

    OEM Database Control 11g

    Let me start with 11g database. To manage a 11g database, you can use “Database Control”. With Database Control, only one database can be managed/monitored. During the database creation or upgrade you can configure “Database Control” using the DBUA or DBCA tools. You may also use EMCA to configure. Details here… Configuring Database Control During and After Installation.

    For you to use Database Control, the dbconsole process must be running on the database host server. You can start and stop the dbconsole process using emctl. Details here… Administering Database Control.

    Access Database Control using your browser – https://hostname:portnumber/em, where hostname is the name of the machine database is running, and port number is 1158 by default. Database users with SELECT_CATALOG_ROLE privilege can access Database Control.

    Database Control can manage a RAC database as well. You can access database control for RAC through any of the available nodes (hosts) of the RAC database. The dbconsole should be running on the node(s).

    Database Control license is included with your Oracle Database license, irrespective of the Edition of the database. So, it is “FREE“! You are allowed to use and manage all the features licensed in the database through OEM. If you are not licensed for Diagnostic and Tuning (to use ASH and AWR, SQL Tuning Advisor, SQL Access Advisor, etc), it is better to set the parameter CONTROL_MANAGEMENT_PACK_ACCESS to NONE in the Oracle database. 

    The version of the Database Control is tied to your database version… 11.1.0.x or 11.2.0.x.

    OEM Database Express (EM Express) 12c

    Similar to Database Control in 11g, the equivalent tool available in Oracle Database 12c is Database Express (also known as EM Express). There are few differences on the capabilities compared to 11g Database Control, but is more aligned to support the features of Oracle Database 12c. The architecture of Database Express is different from Database Control. There is no dbconsole running anymore, Database Express (EM Express) is a web-based database management tool that is built inside the Oracle Database. 

    EM Express is a servlet built on top of Oracle XML DB. DBCA or DBUA automatically configures the port for Database Express access. You can access Database Express using https://hostname:portnumber/em/ (similar to 11g Database Control). The default port is 5500. To configure the port and XMLDB service manually, you may use the steps here… Configuring the HTTPS Port for EM Express. When you invoke the URL, Database Express is started. 

    Database Express supports only One database. It could be a non-container database (traditional pre-12c architecture) or  multitenant database with multiple pluggable databases. It could be a RAC database too.

    Database users having the EM_EXPRESS_BASIC role can connect to EM Express and view the pages in read-only mode. The EM_EXPRESS_ALL role enables users to connect to EM Express and use all the functionality provided by EM Express (read/write access to all EM Express features).

    Database Express license is included with your Oracle Database license, irrespective of the Edition of the database. So, it is “FREE“! You are allowed to use and manage all the features licensed in the database through Database Express. If you are not licensed for Diagnostic and Tuning (to use ASH and AWR, SQL Tuning Advisor, SQL Access Advisor, etc), it is better to set the parameter CONTROL_MANAGEMENT_PACK_ACCESS to NONE in the database, also ENABLE_DDL_LOGGING. 

    The version of the Database Express is tied to your database version… 12.1.0.x.

    Oracle Enterprise Manager 11g Grid Control

    OEM Grid Control is a standalone product, to manage and monitor multiple Oracle targets. You can install and use OEM Grid Control and its repository database, if you purchase any Oracle product (this is the rule for 12c Cloud Control, so I believe it is true for Grid Control as well though not explicitly stated). OEM is not tied directly to Oracle database. That means, the 11g you see with Grid Control is not the same 11g version you associate with the database. Grid control does not have a 11g Release 2. The versions of Grid Control 11g are 11.1.0.x, there is no 11.2.

    Grid Control includes three technical components. Oracle Management Service (OMS) is the brain (the application server), Oracle Management Agent is deployed on each host being monitored by OEM to collect and report target information and Oracle Management Repository database to store the data. A picture and more information on the architecture is here… Enterprise Manager Architecture. So unlike Grid Control and Database Express, you need to procure hardware, install, configure OEM Grid Control.

    You need to buy license to use the “packs” that are installed separately or installed by default when you install OEM Grid Control. To view the packs and individually disable the packs that are not licensed, read here… Enabling and Disabling the Oracle Enterprise Manager Packs.

    Premier Support for OEM Grid Control 11g ends in April 2015.

    Oracle Enterprise Manager Cloud Control 12c

    Finally, this is the super product you need to be on, if you do not have it installed already, please do! The name again is little bit confusing. “12c” does not mean it is associated with Oracle 12c database, the “Cloud” does not mean it can manage only virtual environments and cloud platforms.

    OEM Cloud Control 12c is the latest release of OEM Grid Control. The name change is Oracle strategy to go with the popular technology! Oracle did the same to database names – 8i/9i for internet, 10g/11g for grid, 12c for cloud.

    Are you licensed to use OEM Cloud Control 12c to manage databases and other targets? According to the OEM license document, you are. It says “The base installation of Enterprise Manager Cloud Control 12c includes several features free of charge with the purchase of any Oracle software license or Support contract.” To view the features supported by the “FREE” base installation, read chapter 10 here… Base Enterprise Manager Functionality.

    The real power of OEM Cloud Control comes from the packs. You can enable a pack indicator showing beside the links in OEM Cloud Control to easily identify the packs or required license to use the link. It is always better to disable the packs that you are not licensed to use. The instructions to disable are here… Enabling and Disabling the Oracle Enterprise Manager Packs.

    In addition to the various licensed “cost option” packs from Oracle, there are several OEM extensions available. These are great extensions to use OEM framework to monitor non-Oracle components. Oracle’s Extensibility Exchange is a library of contributions from Oracle, its trusted partners and power users. Kellyn has a great post on the Extensibility Library. The At-a-Glance view gives you opportunity to filter the extensions by vendor, product management area. A check mark in the “Additional Purchase Required” column indicates you need to pay for this extension.

    You should definitely explore the Extensibility Exchange…

    Have a wonderful Cloud Control!

     

    [amazon text=Oracle Enterprise Manager 12c Books &template=carousel&asin=1430249382,0071790578]