问题描述
我们有几个表,每个表都有这样的结构:
“FIELD2_XML” 包含XML数据-表中的主要数据-当然长度不同。
每个表上有基于函数的复合索引,如下所示:
创建hash_varchar2 (文本) 实际上意味着
函数,而Createhash_Xmltype() 实际上意味着
功能。
索引用于加速哈希计算算法,其中必须考虑整个表 (其中的每一行)。
问题是: 如果我们知道,在TEST环境,我们如何估计创建时间PRODUCTION环境?(我们可以假设测试和生产系统的硬件/软件组件,配置设置等相同)。当然,表中的行数和段的大小存在显着差异。
我已经尝试过什么?
Try1:
不幸的是,它的结果和测试系统上测量的实际结果相差很远☹…。因此,我对我们对PROD系统的估计持怀疑态度。
Try2:
我确定了要为索引计算读取的源数据的总大小
对于XMLTYPE列
并且索引的大小也是在创建之后知道的
经过的时间可以视为读取和写入部分的总和。嗯,我知道,也有一个计算时间,但我想保持模型简单。
我在许多表上多次执行create index命令,并测量了经过的时间。知道要读取和写入的数据,我试图计算一种 “读取速度” 和 “写入速度” 值。
之后,我用它们来估计使用生产系统的数据/段大小的执行时间… .. 但是我得到的时间是不现实的长…… -> 我认为,这个模型不能使用… ..
我能做什么?如何才能得到一个现实的执行时间估计?
提前谢谢,
L.卡罗利
CREATE TABLE "myTABLE" ( "FIELD1" CHAR(36 BYTE) NOT NULL ENABLE, "FIELD2_XML" "SYS"."XMLTYPE" , "FIELD3" NUMBER DEFAULT 0 NOT NULL ENABLE, "FIELD4" NUMBER(*,0) );复制
“FIELD2_XML” 包含XML数据-表中的主要数据-当然长度不同。
每个表上有基于函数的复合索引,如下所示:
CREATE INDEX "myHASH_INDEX" ON "myTABLE " ( RAWTOHEX("CREATEHASH_VARCHAR2"("FIELD1"))|| RAWTOHEX("CREATEHASH_XMLTYPE"("FIELD2_XML"))|| RAWTOHEX("CREATEHASH_VARCHAR2"("FIELD3"))|| RAWTOHEX("CREATEHASH_VARCHAR2"("FIELD4")), "FIELD1", "FIELD3", "FIELD4");复制
创建hash_varchar2 (文本) 实际上意味着
DBMS_CRYPTO.HASH(Utl_Raw.Cast_To_raw(text),3);复制
函数,而Createhash_Xmltype() 实际上意味着
Dbms_Crypto.Hash(Text.getBlobVal(NLS_CHARSET_ID ('UTF8')) ,3);复制
功能。
索引用于加速哈希计算算法,其中必须考虑整个表 (其中的每一行)。
问题是: 如果我们知道,在TEST环境,我们如何估计创建时间PRODUCTION环境?(我们可以假设测试和生产系统的硬件/软件组件,配置设置等相同)。当然,表中的行数和段的大小存在显着差异。
我已经尝试过什么?
Try1:
EXPLAIN PLAN FOR CREATE INDEX ….. SELECT * FROM TABLE(dbms_xplan.display);复制
不幸的是,它的结果和测试系统上测量的实际结果相差很远☹…。因此,我对我们对PROD系统的估计持怀疑态度。
Try2:
我确定了要为索引计算读取的源数据的总大小
select bytes from user_segments where segment_name='myTABLE';复制
对于XMLTYPE列
select bytes from user_lobs, user_segments joined by table_name filtered by table_name;复制
并且索引的大小也是在创建之后知道的
select bytes from user_segments where segment_name='myHASH_INDEX';复制
经过的时间可以视为读取和写入部分的总和。嗯,我知道,也有一个计算时间,但我想保持模型简单。
我在许多表上多次执行create index命令,并测量了经过的时间。知道要读取和写入的数据,我试图计算一种 “读取速度” 和 “写入速度” 值。
之后,我用它们来估计使用生产系统的数据/段大小的执行时间… .. 但是我得到的时间是不现实的长…… -> 我认为,这个模型不能使用… ..
我能做什么?如何才能得到一个现实的执行时间估计?
提前谢谢,
L.卡罗利
专家解答
索引创建几乎是:
A-扫描数据
B-对数据进行排序
C-写新段
在您的情况下,“扫描数据” 将包括每个功能的执行。
所以就估计而言,你可以这样做:
对于 (A) 和 (B) 运行一系列:
给这些时间和推断出来。扫描时间将几乎线性地缩放,但请注意,排序时间可能不太可预测,因为它将取决于临时段性能等。
对于 (C),您知道索引大小将大约为 (keysize + rowid) * 行。通过说20% 来填充它,看看您可以将这么多数据写入表空间的速度有多快。
但是用在线条款创建索引有什么障碍吗?构建时间的持续时间不是一个问题吗?
A-扫描数据
B-对数据进行排序
C-写新段
在您的情况下,“扫描数据” 将包括每个功能的执行。
所以就估计而言,你可以这样做:
对于 (A) 和 (B) 运行一系列:
select RAWTOHEX("CREATEHASH_VARCHAR2"("FIELD1"))|| RAWTOHEX("CREATEHASH_XMLTYPE"("FIELD2_XML"))|| RAWTOHEX("CREATEHASH_VARCHAR2"("FIELD3"))|| RAWTOHEX("CREATEHASH_VARCHAR2"("FIELD4"),"FIELD1", "FIELD3", "FIELD4" from mytable order by 1,2,3,4复制
给这些时间和推断出来。扫描时间将几乎线性地缩放,但请注意,排序时间可能不太可预测,因为它将取决于临时段性能等。
对于 (C),您知道索引大小将大约为 (keysize + rowid) * 行。通过说20% 来填充它,看看您可以将这么多数据写入表空间的速度有多快。
但是用在线条款创建索引有什么障碍吗?构建时间的持续时间不是一个问题吗?
文章转载自ASKTOM,如果涉嫌侵权,请发送邮件至:contact@modb.pro进行举报,并提供相关证据,一经查实,墨天轮将立刻删除相关内容。
评论
相关阅读
Oracle DataGuard高可用性解决方案详解
孙莹
586次阅读
2025-03-26 23:27:33
Oracle RAC 一键安装翻车?手把手教你如何排错!
Lucifer三思而后行
541次阅读
2025-04-15 17:24:06
【纯干货】Oracle 19C RU 19.27 发布,如何快速升级和安装?
Lucifer三思而后行
449次阅读
2025-04-18 14:18:38
XTTS跨版本迁移升级方案(11g to 19c RAC for Linux)
zwtian
436次阅读
2025-04-08 09:12:48
墨天轮个人数说知识点合集
JiekeXu
436次阅读
2025-04-01 15:56:03
Oracle SQL 执行计划分析与优化指南
Digital Observer
436次阅读
2025-04-01 11:08:44
【ORACLE】记录一些ORACLE的merge into语句的BUG
DarkAthena
433次阅读
2025-04-22 00:20:37
【ORACLE】你以为的真的是你以为的么?--ORA-38104: Columns referenced in the ON Clause cannot be updated
DarkAthena
411次阅读
2025-04-22 00:13:51
Oracle数据库一键巡检并生成HTML结果,免费脚本速来下载!
陈举超
401次阅读
2025-04-20 10:07:02
Oracle 19c RAC更换IP实战,运维必看!
szrsu
382次阅读
2025-04-08 23:57:08