针对个性化业务无法使用oracle自带审计，设计了触发器跟踪问题

纪念传统系统下线，记录和总结以oracle为主的sql优化、plsql开发、故障排查。 虽然ORACLE已逐步淡出国内市场，但数据库技术一通则百通，类似的技术经验依然可迁移。欢迎其他同行加入~

分享一个跟踪SQL解析错误的案例。在日常 Oracle 数据库监控过程中，发现 alert 日志中不定时出现大量解析报错的记录，解析报错意味着没有执行计划也没有实际的执行结果，那么该怎么跟踪问题呢？

当前用户没有调试新建存储过程的权限，用高权限用户给该用户赋权，执行以下命令试试GRANT DEBUG CONNECT SESSION TO <user>;GRANT DEBUG ANY PROCEDURE TO <user>;

更新Oracle相关的学习心得，故障解决思路，实验测试等等

之前遇到过这样的报错，数据库进程数超过参数限制。建议确认下所在实例processes这个参数配置的是不是太小了，并且检查下所在数据库实例在报错时是否存在连接数风暴，控制住数量或者把该参数值调高（需要重启实例）应该可以避免这个错误

试试加双引号，比如 order和limit都是关键字，create table "order" (id int, "limit" int);

这个还得看具体SQL和你的查询需求。如果千万级数据量的表访问少量数据，过滤条件尽量按索引。如果需要查询大量数据，可以在资源允许的情况下对大表启用并行。如果查询条件比较规律，查询时效性要求不高，可以考虑建立物化视图，直接访问物化视图中的数据。

虽然SQLID一样，但是各节点执行SQL时刻的负载未必相近，建议抓取频繁出现问题时间段的AWR对比报告进行分析。您有具体的例子吗？

不清楚具体的表结构和数据，横向求和可以考虑下OVER函数， SUM(XXX) OVER()

需要看具体数据量和操作期间的业务压力，直接DROP期间会锁表，风险很大，可能导致长时间中断相关业务。可以考虑先标记UNUSED再进行DROP：ALTER TABLE TABLENAME SET UNUSED (COLUMN_NAME);ALTER TABLE TABLENAME DROP UNUSED COLUMNS CHECKPOINT 500;checkpoint后面的数值（500）是表示每处

调用python程序，报错：scocket.error：【10060】

你好，有试过move坏块所属的表吗？准备一个设置ASSM的表空间比如testalter table SYSMAN.MGMT_METRICS_RAW move tablespace test;alter table SYSMAN.MGMT_METRICS_RAW move tablespace SYSAUX;如果无法move报什么错？还有一种麻烦的办法，就是跳过坏块建一张新表，下面给个帖子，与你的案

ORACLE SQL画福字 白菜版