惯性聚合 高效追踪和阅读你感兴趣的博客、新闻、科技资讯
阅读原文 在惯性聚合中打开

推荐订阅源

H
Help Net Security
博客园 - Franky
GbyAI
GbyAI
Threat Intelligence Blog | Flashpoint
Threat Intelligence Blog | Flashpoint
爱范儿
爱范儿
IT之家
IT之家
酷 壳 – CoolShell
酷 壳 – CoolShell
aimingoo的专栏
aimingoo的专栏
博客园_首页
MongoDB | Blog
MongoDB | Blog
CTFtime.org: upcoming CTF events
CTFtime.org: upcoming CTF events
Recent Announcements
Recent Announcements
Scott Helme
Scott Helme
有赞技术团队
有赞技术团队
M
MIT News - Artificial intelligence
C
CERT Recently Published Vulnerability Notes
K
KPMG report finds enterprise disconnect between AI and its ROI | CIO
Jina AI
Jina AI
F
Fortinet All Blogs
N
Netflix TechBlog - Medium
L
LangChain Blog
L
LINUX DO - 最新话题
OSCHINA 社区最新新闻
OSCHINA 社区最新新闻
cs.AI updates on arXiv.org
cs.AI updates on arXiv.org
H
Hacker News: Front Page
MyScale Blog
MyScale Blog
P
Palo Alto Networks Blog
G
Google Developers Blog
Google DeepMind News
Google DeepMind News
AI
AI
T
Troy Hunt's Blog
Microsoft Azure Blog
Microsoft Azure Blog
阮一峰的网络日志
阮一峰的网络日志
cs.CL updates on arXiv.org
cs.CL updates on arXiv.org
Vercel News
Vercel News
Microsoft Security Blog
Microsoft Security Blog
罗磊的独立博客
S
Secure Thoughts
大猫的无限游戏
大猫的无限游戏
博客园 - 叶小钗
人人都是产品经理
人人都是产品经理
Blog — PlanetScale
Blog — PlanetScale
博客园 - 司徒正美
Apple Machine Learning Research
Apple Machine Learning Research
钛媒体:引领未来商业与生活新知
钛媒体:引领未来商业与生活新知
博客园 - 三生石上(FineUI控件)
S
Security @ Cisco Blogs
Cloudbric
Cloudbric
E
Exploit-DB.com RSS Feed
Attack and Defense Labs
Attack and Defense Labs

博客园 - 阿泰

水晶报表问题交流与答疑帖-2011/07-08-09 Oracle中可选参数的处理 水晶报表问题交流与答疑帖-2011/04-05-06 水晶报表问题交流与答疑帖-2010/07-08-09【关闭】 【公告】如果发现博客中图片或文件丢失,请在本贴中回复中贴上URL [转]2010年Gartner企业绩效管理四分区 重要通知:为了能提升答疑质量,本博客的答疑转移到CSDN论坛 2009年11月答疑贴 VS2010beta2中RDLC与水晶报表之简单评测 【水晶报表内功心法】--信手拈来,掌控对象 之 多值参数传入 - 阿泰 2009年10月份答疑贴 2009年9月份答疑帖 2009年8月份答疑贴 【水晶报表内功心法】--完美Excel(下) 【水晶报表内功心法】--完美Excel(上) 【水晶报表内功心法】--公式、函数与运行时总计 【水晶报表内功心法】--第一阶段小结 【水晶报表内功心法】--数据过滤 【水晶报表内功心法】--信手拈来,掌控对象
Oracle 00600 错误解决方法
阿泰 · 2009-09-05 · via 博客园 - 阿泰

写了个语句,执行过程中报出如下错误:

网上查了下,这篇还比较靠谱:http://www.eygle.com/archives/2009/02/ora_00600_17182.html

但是怎么解决,却没有通用的方法。

怀疑是因为数据量太大导致的,A表6000万条数据,占用物理空间15G。B表1万条数据,因为有物理逻辑,A表上还带了个子查询。
因为这个是偶尔才执行一次,所以就只简单地实现了逻辑。实际分析的时候COST相当厉害。基本上都是Table Access Full。

本来时间长点没什么,因为是空闲时调度起来,但是可能是造成磁盘和资源吃紧。

后来联系了DBA,给了这么个方案。

在后面语句中的Select 后增加这么个语句

Select  /*+ NO_USE_HASH_AGGREGATION*/ ...

还真是不报错了,跑了近50+30分钟(两段insert),返回190万条数据。

想想不甘心,将存储过程拆开来,逐个分公司跑,存储过程执行40次,减小单次执行的资源和磁盘开销。结果跑了19分钟。

这个故事告诉我们,不能偷懒。记录一下,警醒自己。