Extended Data Types is a feature as of Oracle 12c. It allows to increase the maximum size of VARCHAR2, NVARCHAR2, and RAW columns in a table.

Prerequisites

  • Oracle database version 12c onward

  • Admin privileges to connect as SYSDBA into the database

Introduction

For versions prior to Oracle 12c, the following limits apply for the maximum size of a column:

  • VARCHAR2 : 4000 bytes

  • NVARCHAR2 : 4000 bytes

  • RAW : 2000 bytes

In Oracle 12c (and onward), the maximum limit is set to 32767 bytes for the following data types:

  • VARCHAR2 : 32767 bytes

  • NVARCHAR2 : 32767 bytes

  • RAW : 32767 bytes

Important: If you plan to execute the database update scripts for censhare 2020.1, check for specific indexes under  asset_feature  table. Otherwise, an update error can occur. For detailed instructions, see Before update to 2020.1.

Enable the Extended Data Types

The extended data types feature is controlled by using the MAX_STRING_SIZE initialization parameter. The default value is STANDARD, which restricts the maximum sizes to the traditional lengths. Setting the parameter value to EXTENDED, allows you to use the new maximum lengths.

The process of switching to the extended data types is a one-way operation. Once, you have switched to extended data types you cannot go back without some form of database recovery. In addition to changing the parameter, you must run the utl32k.sql script to invalidate and recompile any object that may be affected by the maximum length changes.

Execute the upgrade

As an admin, execute the following commands:

CONN / AS SYSDBA  -- If you have not connected before, introduce the user and pass of an admin. 
-- Precaution to prevent possible failures. Suggested by Hristiyan. 
PURGE DBA_RECYCLEBIN 
SHUTDOWN IMMEDIATE; 
STARTUP UPGRADE; ALTER SYSTEM SET max_string_size=extended; 
@?/rdbms/admin/utl32k.sql 
SHUTDOWN IMMEDIATE; 
STARTUP;
CODE

Watch the Output

The utl32k.sql script produces output that looks something like this:

Session altered. 
DOC>####################################################################### 
DOC>####################################################################### 
DOC>   The following statement will cause an "ORA-01722: invalid number" 
DOC>   error if the database has not been opened for UPGRADE. 
DOC> 
DOC>   Perform a "SHUTDOWN ABORT"  and 
DOC>   restart using UPGRADE. 
DOC>####################################################################### 
DOC>####################################################################### 
DOC>#

no rows selected  

DOC>####################################################################### 
DOC>####################################################################### 
DOC>   The following statement will cause an "ORA-01722: invalid number" 
DOC>   error if the database does not have compatible >= 12.0.0 
DOC> 
DOC>   Set compatible >= 12.0.0 and retry. 
DOC>####################################################################### 
DOC>####################################################################### 
DOC>#

PL/SQL procedure successfully completed.  

Session altered.  

0 rows updated.  

Commit complete.  

System altered.

PL/SQL procedure successfully completed.  

Commit complete.  

System altered.  

Session altered.

PL/SQL procedure successfully completed.  

No errors.  

Session altered.  

PL/SQL procedure successfully completed.  

Commit complete.  

Package altered.

TIMESTAMP 
-------------------------------------------------------------------------------- 
COMP_TIMESTAMP UTLRP_BGN  2013-07-10 10:11:26  

DOC>   The following PL/SQL block invokes UTL_RECOMP to recompile invalid 
DOC>   objects in the database. Recompilation time is proportional to the 
DOC>   number of invalid objects in the database, so this command may take 
DOC>   a long time to execute on a database with a large number of invalid 
DOC>   objects. 
DOC> 
DOC>   Use the following queries to track recompilation progress: 
DOC> 
DOC>   1. Query returning the number of invalid objects remaining. This 
DOC>      number should decrease with time. 
DOC>         SELECT COUNT(*) FROM obj$ WHERE status IN (4, 5, 6); 
DOC> 
DOC>   2. Query returning the number of objects compiled so far. This number 
DOC>      should increase with time. 
DOC>         SELECT COUNT(*) FROM UTL_RECOMP_COMPILED; 
DOC> 
DOC>   This script automatically chooses serial or parallel recompilation 
DOC>   based on the number of CPUs available (parameter cpu_count) multiplied 
DOC>   by the number of threads per CPU (parameter parallel_threads_per_cpu). 
DOC>   On RAC, this number is added across all RAC nodes. 
DOC> 
DOC>   UTL_RECOMP uses DBMS_SCHEDULER to create jobs for parallel 
DOC>   recompilation. Jobs are created without instance affinity so that they 
DOC>   can migrate across RAC nodes. Use the following queries to verify 
DOC>   whether UTL_RECOMP jobs are being created and run correctly: 
DOC> 
DOC>   1. Query showing jobs created by UTL_RECOMP 
DOC>         SELECT job_name FROM dba_scheduler_jobs 
DOC>            WHERE job_name like 'UTL_RECOMP_SLAVE_%'; 
DOC> 
DOC>   2. Query showing UTL_RECOMP jobs that are running 
DOC>         SELECT job_name FROM dba_scheduler_running_jobs 
DOC>            WHERE job_name like 'UTL_RECOMP_SLAVE_%'; 
DOC>#

PL/SQL procedure successfully completed.  

TIMESTAMP 
-------------------------------------------------------------------------------- 
COMP_TIMESTAMP UTLRP_END  2013-07-10 10:11:33  

DOC> The following query reports the number of objects that have compiled 
DOC> with errors. 
DOC> 
DOC> If the number is higher than expected, please examine the error 
DOC> messages reported with each object (using SHOW ERRORS) to see if they 
DOC> point to system misconfiguration or resource constraints that must be 
DOC> fixed before attempting to recompile these objects. 
DOC>#

OBJECTS WITH ERRORS 
-------------------
                     0  
DOC> The following query reports the number of errors caught during 
DOC> recompilation. If this number is non-zero, please query the error 
DOC> messages in the table UTL_RECOMP_ERRORS to see if any of these errors 
DOC> are due to misconfiguration or resource constraints that must be 
DOC> fixed before objects can compile successfully. 
DOC>#

ERRORS DURING RECOMPILATION 
---------------------------
                             0  

Function created.  

PL/SQL procedure successfully completed.  

Function dropped.

...Database user "SYS", database schema "APEX_040200", user# "98" 11:26:30 
...Compiled 0 out of 2998 objects considered, 0 failed compilation 11:26:31 
...263 packages 
...255 package bodies 
...453 tables 
...11 functions 
...16 procedures 
...3 sequences 
...458 triggers 
...1322 indexes 
...207 views 
...0 libraries 
...6 types 
...0 type bodies 
...0 operators 
...0 index types 
...Begin key object existence check 11:26:31 
...Completed key object existence check 11:26:31 
...Setting DBMS Registry 11:26:31 
...Setting DBMS Registry Complete 11:26:31 
...Exiting validate 11:26:31  

PL/SQL procedure successfully completed.  

SQL>

Extend the size of database columns

After successfully executing the previous commands, you can extend the size of the columns of the mentioned types.

As mentioned above: The type of the database column must be one of these: VARCHAR2, NVARCHAR2, and RAW.

To extend the size, execute the following command:

ALTER TABLE TABLE_NAME MODIFY COLUMN_NAME VARCHAR(32767 CHAR)

For example:

ALTER TABLE ASSET_FEATURE MODIFY VALUE_STRING VARCHAR(32767 CHAR)

Note: Normally, after applying the extended data type to the Oracle database, there is no need to execute any additional commands to increase the size of the desired column. The pre-update sql scripts and the new installations (censhare 2019.3 or higher) take care of that step by introducing the new default sizes.

Before update to censhare 2020.1

The 2019_3_maxversion-t-2020_1_0-01-pre.sql update script extends the size of value_string column of asset_feature table. Using this, the extended data type must have been activated.

For some installations, there can be defined indexes for the asset_feature table that can cause the update script to fail. The following change command in the update script then cannot be executed:

ALTER TABLE ASSET_FEATURE MODIFY VALUE_STRING VARCHAR(32767 CHAR)

The following indexes have been found to block the change command:

  • ASSET_FEATURE_IDX4

  • ASSET_FEATURE_IDX5

  • ASSET_FEATURE_IDX6

  • ASSET_FEATURE_IDX7

  • ASSET_FEATURE_IDX9

Use the following command to check if these indexes exist for the asset_feature table:

select distinct index_name from dba_ind_columns where table_owner=' <USER> ' and table_name='ASSET_FEATURE' order by index_name;
SQL

If so, delete these indexes:

DROP INDEX ASSET_FEATURE_IDX4; DROP INDEX ASSET_FEATURE_IDX5; DROP INDEX ASSET_FEATURE_IDX6; DROP INDEX ASSET_FEATURE_IDX7; DROP INDEX ASSET_FEATURE_IDX9;
SQL

After that, the change command in the update script should not fail.