ITPub博客

首页 > 数据库 > 数据库开发技术 > 小案例:使用To_char的时候,某些SQL语句在SQLPLUS的表示格式发生变化

小案例:使用To_char的时候,某些SQL语句在SQLPLUS的表示格式发生变化

原创 数据库开发技术 作者:lukeunique 时间:2021-06-09 08:08:00 0 删除 编辑

编者按:

本文作者系流浪的金鱼(花名),甲骨文数据库工程师。个人主页:https://blog.csdn.net/rishairu1,经其本人授权发布。


【免责声明】本公众号文章仅代表个人观点,与任何公司无关。

有的时候,我们可能突然遇到在sqlplus上,以前执行很正常的sql语句,突然表示的格式发生了变化。并且发现这个sql语句中使用了To_char函数。


例如如下的这个表空间使用率的sql。


SQL> set lines 120set pages 100set term offtti offclear colcol TABLESPACE_NAME     format a15col "SIZE(MB)"          format a20col "USED(MB)"          format a20col "FREE(MB)"          format a20col "USED(%)"           format 990.99select  tablespace_name,  to_char(nvl(total_bytes / 1024,0),'999,999,999') as "size(MB)",  to_char(nvl((total_bytes - free_total_bytes) / 1024 / 1024,0),'999,999,999') as "used(MB)",  to_char(nvl(free_total_bytes / 1024 / 1024,0),'999,999,999') as "free(MB)",  round(nvl((total_bytes - free_total_bytes) / total_bytes * 100,100),2) as "rate(%)"from  ( select      tablespace_name,      sum(bytes) total_bytes    from      dba_data_files    group by      tablespace_name  ),  ( select      tablespace_name free_tablespace_name,      sum(bytes) free_total_bytes    from      dba_free_space    group by tablespace_name  )where  tablespace_name = free_tablespace_name(+)/


正常的时候是如下格式表示。


TABLESPACE_NAME size(MB)             used(MB)             free(MB)                rate(%)--------------- -------------------- -------------------- -------------------- ----------SYSAUX             7,809,024                7,084                  543              92.89UNDOTBS1           1,536,000                   44                1,456               2.96USERS              3,000,320                   11                2,919                .39SYSTEM             1,034,240                1,008                    2              99.76SCOTT_TBS             44,928                   32                   12              72.22

但是某一天突然变成了如下串行的格式。并且sql语句没有变过。也没有打什么补丁。


TABLESPACE_NAME ---------------------------------------------------------------size(MB)         -----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------used(MB)          -----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------free(MB)  -----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------rate(%)---------------------------------------------------------------SYSAUX             7,809,024                7,084                  543              92.89

UNDOTBS1 1,536,000 44 1,456 2.96 USERS 3,000,320 11 2,919 .39

SYSTEM 1,034,240 1,008 2 99.76

SCOTT_TBS 44,928 32 12 72.22


如果遇到这种情况,你需要看一下Cursor_sharing 的参数是否发生了改变。


这个参数会影响共享cursor的方式。默认值是EXACT。如果改成了SIMILAR或者FORCE就可能发生这个现象。


按照oracle的文档313135.1说明,Cursor_sharing参数的值会影响to_char处理对象列的表示格式。但是由于会影响共享cursor的动作,所有最终没有被修正。


将Cursor_sharing改回默认值。或者将to_char(nvl(total_bytes / 1024,0),'999,999,999') 中的 999,999,999去掉会解决该问题。


后续文章更加精彩,欢迎关注本公众号或访问【阅读原文】。

——End——


欢迎加入SQL和数据库技术交流群和其他小伙伴一起讨论。

进群方式:加小编微信(微信号:TeacherWhat 或 扫描下方二维码)


回复:加群。
(为方便交流,建议备注:行业-职位-城市)

专注于技术不限于技术!

用碎片化的时间,一点一滴地提高数据库技术和个人能力。

欢迎关注!


案例系列:(从实际问题出发)

案例:如何从SYSTEMSTATE DUMP查看Mutex的持有者和请求者

知识&案例:并行和并发统计信息收集

案例:12.2环境用户登录错误ORA-01017

案例:数据库无法登录发生ORA-12560/ORA-12557错误

案例:DRIVING_SITE 提示(HINT)设定无效的调查

案例:  log file sync等待引起的RAC 挂起(HANG)

案例:”WAITED TOO LONG FOR A ROW CACHE ENQUEUE LOCK! “等待的诊断

小案例:结果缓存无法使用,RESULT_CACHE_MAX_SIZE值无法更改的问题

原文作者:SQL和数据库技术;如有侵权,请联系管理员删除。

请登录后发表评论 登录
全部评论

注册时间:2017-07-21

  • 博文量
    107
  • 访问量
    63567