Blog

  • Invisible Columns in Oracle Database 12c

    In May 2014, the following #oratidbit relating to invisible columns were tweeted.

    • In #DB12c, you can make a column in table as INVISIBLE. When you make it invisible, the COL# column in COL$ dictionary is updated to 0, thus is not included in the “SELECT *” or “INSERT INTO VALUES”, unless specifically selected.
    • When you make an INVISIBLE column in Oracle 12c database to VISIBLE, the COL# is assigned the highest available. Thus the column becomes the last column in the table (not storage, only display). So, if you accidentally make a column INVISIBLE and correct it by changing to VISIBLE, the column order changes. So, if the application uses “SELECT *” or “INSERT” without column names, they might break!

    Why would you make a column invisible? There are not many reasons why suddenly you would make a column invisible, one situation comes to mind is you want to test the waters before dropping the column from table – to figure out if something breaks or someone yells. Oracle provides an option to mark a column as UNUSED before you DROP, and do ALTER TABLE … DROP UNUSED COLUMNS at a later time. Once you mark a column as UNUSED, there is no going back to undo the action. So marking it INVISIBLE before drop is a good idea. Another use could be that you have a running application used by many teams – before you collaborate with everyone on a table change, you could test the changes in the table by creating the new column as invisible, do your basic tests, then talk to the other teams and make the column visible to all.

    Let me show you the behavior of INVISIBLE column and UNUSED column in the data dictionary. Create a table with the following characteristics. Columns 1, 4 & 7 are regular columns with no specialty. 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
    

    Notice all columns have USER_GENERATED as YES, 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.
    

    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 visible 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.

    Tip: By default SQL*Plus DESCRIBE will not show the invisible columns in a table. If you want to see the invisible columns in DESCRIBE, use SET COLINVISIBLE ON.

  • Critical Background Processes in Oracle Database 12c

    There are several background processes running when you start Oracle Database 12c instance. Here is an example from one of the 12.1.0.2 instances.

     

     ora_acms_bt9prod1

     ora_lreg_bt9prod1 ora_p00w_bt9prod1
     ora_aqpc_bt9prod1  ora_m000_bt9prod1  ora_p00x_bt9prod1
     ora_asmb_bt9prod1  ora_mark_bt9prod1  ora_p00y_bt9prod1
     ora_cjq0_bt9prod1  ora_mman_bt9prod1  ora_p00z_bt9prod1
     ora_ckpt_bt9prod1  ora_mmnl_bt9prod1  ora_ping_bt9prod1
     ora_dbrm_bt9prod1  ora_mmon_bt9prod1  ora_pmon_bt9prod1
     ora_dbw0_bt9prod1  ora_o000_bt9prod1  ora_ppa6_bt9prod1
     ora_dbw1_bt9prod1  ora_p000_bt9prod1  ora_ppa7_bt9prod1
     ora_dbw2_bt9prod1  ora_p001_bt9prod1  ora_psp0_bt9prod1
     ora_dbw3_bt9prod1  ora_p002_bt9prod1  ora_pxmn_bt9prod1
     ora_dbw4_bt9prod1  ora_p003_bt9prod1  ora_q001_bt9prod1
     ora_dbw5_bt9prod1  ora_p004_bt9prod1  ora_q003_bt9prod1
     ora_dbw6_bt9prod1  ora_p005_bt9prod1  ora_q006_bt9prod1
     ora_dbw7_bt9prod1  ora_p006_bt9prod1  ora_q008_bt9prod1
     ora_dbw8_bt9prod1  ora_p007_bt9prod1  ora_q009_bt9prod1
     ora_dbw9_bt9prod1  ora_p008_bt9prod1  ora_q00a_bt9prod1
     ora_dbwa_bt9prod1  ora_p009_bt9prod1  ora_q00b_bt9prod1
     ora_dbwb_bt9prod1  ora_p00a_bt9prod1  ora_qm00_bt9prod1
     ora_dbwc_bt9prod1  ora_p00b_bt9prod1  ora_qm02_bt9prod1
     ora_dbwd_bt9prod1  ora_p00c_bt9prod1  ora_qm03_bt9prod1
     ora_dbwe_bt9prod1  ora_p00d_bt9prod1  ora_qm05_bt9prod1
     ora_dbwf_bt9prod1  ora_p00e_bt9prod1  ora_rbal_bt9prod1
     ora_dia0_bt9prod1  ora_p00f_bt9prod1  ora_rcbg_bt9prod1
     ora_diag_bt9prod1  ora_p00g_bt9prod1  ora_reco_bt9prod1
     ora_gcr0_bt9prod1  ora_p00h_bt9prod1  ora_rms0_bt9prod1
     ora_gen0_bt9prod1  ora_p00i_bt9prod1  ora_rmv0_bt9prod1
     ora_gtx0_bt9prod1  ora_p00j_bt9prod1  ora_rmv1_bt9prod1
     ora_lck0_bt9prod1  ora_p00k_bt9prod1  ora_rmv2_bt9prod1
     ora_lck1_bt9prod1  ora_p00l_bt9prod1  ora_rsmn_bt9prod1
     ora_lg00_bt9prod1  ora_p00m_bt9prod1  ora_smco_bt9prod1
     ora_lg01_bt9prod1  ora_p00n_bt9prod1  ora_smon_bt9prod1
     ora_lgwr_bt9prod1  ora_p00o_bt9prod1  ora_tmon_bt9prod1
     ora_lmd0_bt9prod1  ora_p00p_bt9prod1  ora_tt00_bt9prod1
     ora_lmd1_bt9prod1  ora_p00q_bt9prod1  ora_vkrm_bt9prod1
     ora_lmhb_bt9prod1  ora_p00r_bt9prod1  ora_vktm_bt9prod1
     ora_lmon_bt9prod1  ora_p00s_bt9prod1  ora_w008_bt9prod1
     ora_lms0_bt9prod1  ora_p00t_bt9prod1  ora_w009_bt9prod1
     ora_lms1_bt9prod1  ora_p00u_bt9prod1  
     ora_lms2_bt9prod1  ora_p00v_bt9prod1  

    Which processes are critical for database operation? In other words, if you terminate one of these processes knowingly or unknowingly, will the instance terminate?

    The critical processes required for basic database operation are:

    Acronym Process Name Description
    CKPT Checkpoint Process Signals DBWn at checkpoints and updates all the data files and control files of the database to indicate the most recent checkpoint
    DBWn Database Writer Process Writes modified blocks from the database buffer cache to the data files. There can be 1 to 100 Database Writer Processes. The names of the first 36 Database Writer Processes are DBW0-DBW9 and DBWa-DBWz. The names of the 37th through 100th Database Writer Processes are BW36-BW99.
    BWnn Database Writer Process The names of the 37th through 100th Database Writer Processes are BW36-BW99.
    DIAG Diagnostic Capture Process Performs diagnostic dumps and executes global oradebug commands.
    DIA0 Diagnostic Process 0 (although 10 possible, only 0 is currently used) Responsible for hang detection and deadlock resolution. Triggers DIAG to perform diagnostic tasks.
    GEN0 General Task Execution Process Performs required tasks including SQL and DML.
    CSnn I/O Calibration Process Issues I/Os to storage as part of storage calibration. There is one slave process per CPU on each node of the database.
    LREG Listener Registration Process LREG notifies the listeners about instances, services, handlers, and endpoint.
    LGWR Log Writer Process Writes the log buffer out to the redo logs.
    OFSD Oracle File Server Background Process This background process listens for new file system requests, both management (like mount, unmount, and export) and I/O requests, and executes them using Oracle threads.
    PMON Process Monitor Recovers failed process resources. If Shared Server architecture is used, PMON monitors and restarts any failed dispatcher or server processes.
    SMON System Monitor Process Performs critical tasks such as instance recovery and dead transaction recovery, and maintenance tasks such as temporary space reclamation, data dictionary cleanup, and undo tablespace management
    VKTM Virtual Keeper of Time Process Responsible for providing a wall-clock time (updated every second) and reference-time counter (updated every 20ms and available only when running at elevated priority).