支持超过4000字节的varchar2类型
Oracle中最常用的字符串类型可能就是varchar2了，但是一直以来，让人吐槽最多的，可能就是他的存储容量，12c之前，允许存储4000字节，请注意这的单位是字节，如果你按照非常规的字符定义字段，就得结合字符集，确定他能存储的容量。如果要存储超过这个限制的字符，就得改为CLOB类型了，他的容量是4G，另外一种变通的形式，不想使用大字段，就将要存储的字符拆成多个varchar2类型的字段，读的时候拼接这些字段，起到一样的效果。
从12c开始，varchar2(实际包括nvarchar2和raw)开始支持32767个字节，即32K的容量。他是由max_string_size这个参数控制的，默认值是STANDARD，为了支持32K，需要将其改为EXTENDED，
SQL> show parameter max_string_size
NAME TYPE VALUE
---------------- ------ ----------
max_string_size string STANDARD
从官方文档，我们知道，non-CDB、CDB、PDB都支持这个参数，
(1) 如果是non-CDB，步骤较为简单，
1. 关闭数据库，shutdown immediate。
2. 启动数据库到升级模式，startup upgrade。
3. 修改max_string_size=’EXTENDED’，scope=both。
4. 执行@?/rdbms/admin/utl32k.sql
5 .重启数据库至正常open状态，shutdown immdeiate -> startup。
(2) 如果是PDB，步骤和上述相同，只是必须在PDB执行以下操作，
SQL> alter pluggable database bisalpdb2 close;
Pluggable database altered.
SQL> alter pluggable database bisalpdb2 open upgrade;
Pluggable database altered.
SQL> alter system set max_string_size=extended scope=both;
System altered.
SQL> @?/rdbms/admin/utl32k.sql
Session altered.
//脚本执行速度，应该和当前数据库中的对象数量有关。
SQL> alter pluggable database bisalpdb2 close;
Pluggable database altered.
SQL> alter pluggable database bisalpdb2 open;
Pluggable database altered.
此时的参数值，已经改为EXTENDED，
SQL> show parameter max_string_size
NAME TYPE VALUE
---------------- ------ --------
max_string_size string EXTENDED
我们就可以创建一个32767字节的varchar2类型字段，
SQL> create table test(c varchar2(32767));
Table created.
(3) 如果是CDB，执行以上操作，还需要单独设置pdb$seed以及其他pdb的max_string_size，操作过程：
close->open upgrade->max_string_size->close->open
这就不操作了。
虽然能支持32K的字符串了，但是还存在一些风险和限制，例如，
(1) EXTENDED只支持heap table，不支持cluster table簇表和index-organized tables索引组织表。
(2) max_string_size如果改为EXTENDED，不能再改为STANDARD，这是单向操作，因此要提前设计，
SQL> alter pluggable database bisalpdb2 close;
Pluggable database altered.
SQL> alter pluggable database bisalpdb2 open upgrade;
Pluggable database altered.
SQL> alter system set max_string_size=standard scope=both;
alter system set max_string_size=standard scope=both
*
ERROR at line 1:
ORA-02097: parameter cannot be modified because specified value is invalid
ORA-14693: The MAX_STRING_SIZE parameter must be EXTENDED.
(3) 32K的字符串在Oracle内部还是以LOB的方式存储的，容易造成行链接，对数据读取的性能产生一定的影响。
(4) 索引中的字段，不能直接支持EXTENDED，需要删除索引，更改字段，再重建索引。
(5) 官方文档上提到了如下这些场景，第一个场景，应该和索引长度限制相关，如果按照标准8k的数据块，一个B树索引块所支持的索引长度可能就6千多字节，这就和在MySQL中索引键值长度的问题很像了(《小白学习MySQL - 索引键长度限制的问题》)，或者通过substr截取创建索引，或者通过substr创建虚拟列，再创建索引，
Altering MAX_STRING_SIZE will update database objects and possibly invalidate them, as follows:
Tables with virtual columns will be updated with new data type metadata for virtual columns of VARCHAR2(4000), 4000-byte NVARCHAR2, or RAW(2000) type.
Functional indexes will become unusable if a change to their associated virtual columns causes the index key to exceed index key length limits. Attempts to rebuild such indexes will fail with ORA-01450: maximum key length exceeded.
Views will be invalidated if they contain VARCHAR2(4000), 4000-byte NVARCHAR2, or RAW(2000) typed expression columns.
Materialized views will be updated with new metadata VARCHAR2(4000), 4000-byte NVARCHAR2, and RAW(2000) typed expression columns
因此，为了能从语法上支持32K的varchar2，还是需要一些代价的，究竟是设置max_string_size，还是选择CLOB，或者是拆分字段，可能就得结合实际的场景，综合考量。
近期更新的文章：
《“自以为对的”MyBatis空闲连接探测的机制》
《积累一些SQL》
《创建主键的三种方式对指定索引表空间操作的纠正》
《Oracle优化器的“短路”》
《MySQL行转列的小需求》
《Oracle的greatest和least函数》
《我的股市生涯》
《Oracle创建主键的三种方式》
《非Oracle Linux下Oracle 19c CDB数据库安装》
《案例纠正一则》
《Redis和Sentinel的安装部署和配置》
《“火线”和“零线”》
《通过索引提升SQL性能案例一则》
《如何手动添加jar包到maven本地库？》
《1元股权转让的一点思考》
《如何打造一个经常宕机的业务系统？》
《Linux恢复误删文件的操作》
《Linux的scp指令使用场景》
《Oracle处理IN的几种方式》
《如何搭建一支拖垮公司的技术团队？》
《IP地址解析的规则》
《MySQL的skip-grant-tables》
《国产数据库不平凡的一年》
《Oracle要求顺序的top数据检索问题》
《日常工作中碰到的几个技术问题》
《了解一下sqlhc》
《Oracle的MD5函数介绍》
《Oracle 19c的examples静默安装》
《sqlplus登录缓慢的解决》
《VMWare 11安装RedHat Linux 7过程中碰到的坑》
《COST值相同？是真是假？》
《Oracle 11g的examples静默安装》
文章分类和索引：
《公众号700篇文章分类和索引》