大分区表问题 [英] Large partitioned table issue
问题描述
嗨......我们是一家大型机V7商店计划即将升级到V8。我的
应用程序团队正在将IMS DB转换为DB / 2表...
大约40GB的未压缩（约20 GB压缩）数据传播到
10个分区。大约35％的数据是不活跃的。 （很容易
可识别）和有限（但有些）使用。我们在数据上需要2个
非分区索引。 DBA小组希望我们将
置于无效状态。数据进入一个单独的表，因为建立NPI的资源要求排序。将数据分成两个
表需要应用程序代码来决定访问哪个表需要
。在同意根据
操作要求进行应用程序更改之前，我想要一些明智的决定
这是否真的是必要的以及它是否会实现
DBA小组会说它会是什么。
任何接受者？
问候，
Steve Keanie
安大略省交通运输部
Hi ... we''re a mainframe V7 shop planning an imminent upgrade to V8. My
application team is converting an IMS DB into a DB/2 table ...
approximately 40GB of uncompressed (~20 GB compressed) data spread over
10 partitions. Approximately 35% of the data is "inactive" (easily
identifiable as such) and of limited (but some) use. We require 2
non-partitioning indexes on the data. The DBA group would like us to
put the "inactive" data into a separate table because of the sort
resource requirements to build the NPIs. Separating the data into two
tables would require application code to decide which table needs to be
accessed. Before agreeing to make application changes based on
operational requirements, I''d like some informed decisions as to
whether this should really be necessary and whether it will achieve
what the DBA group says it will.
Any takers?
Regards,
Steve Keanie
Ministry of Transport, Ontario
推荐答案
< st ****** ****@rogers.com写信息
新闻：11 ********************* @ i42g2000cwa.googlegro ups.com。 ..
<st**********@rogers.comwrote in message
news:11*********************@i42g2000cwa.googlegro ups.com...
嗨...我们是一家大型机V7商店计划即将升级到V8。我的
应用程序团队正在将IMS DB转换为DB / 2表...
大约40GB的未压缩（约20 GB压缩）数据传播到
10个分区。大约35％的数据是不活跃的。 （很容易
可识别）和有限（但有些）使用。我们在数据上需要2个
非分区索引。 DBA小组希望我们将
置于无效状态。数据进入一个单独的表，因为建立NPI的资源要求排序。将数据分成两个
表需要应用程序代码来决定访问哪个表需要
。在同意根据
操作要求进行应用程序更改之前，我想要一些明智的决定
这是否真的是必要的以及它是否会实现
DBA小组会说它会是什么。
任何接受者？
问候，
Steve Keanie
安大略省交通部
Hi ... we''re a mainframe V7 shop planning an imminent upgrade to V8. My
application team is converting an IMS DB into a DB/2 table ...
approximately 40GB of uncompressed (~20 GB compressed) data spread over
10 partitions. Approximately 35% of the data is "inactive" (easily
identifiable as such) and of limited (but some) use. We require 2
non-partitioning indexes on the data. The DBA group would like us to
put the "inactive" data into a separate table because of the sort
resource requirements to build the NPIs. Separating the data into two
tables would require application code to decide which table needs to be
accessed. Before agreeing to make application changes based on
operational requirements, I''d like some informed decisions as to
whether this should really be necessary and whether it will achieve
what the DBA group says it will.
Any takers?
Regards,
Steve Keanie
Ministry of Transport, Ontario
首先，没有名为DB / 2的产品。它是DB2。你必须是一个旧的
屁，他们记得PS / 2和OS / 2，并且认为一切都必须以IBM结束。/ /
。
我会看一下UNION ALL视图，其中定义了哪些
数据进入哪个表。如果DB2可以通过约束来确定数据的位置，那么它只会查看必要的表格并忽略
其他表格。 UNION ALL视图将保护应用程序不知道要访问哪些
表。
First of all, there is no product named DB/2. It is DB2. You must be an old
fart who remembers PS/2 and OS/2 and think that everything must end in /2
from IBM.
I would take a look at UNION ALL views, with constraints defined as to which
data goes into which table. If DB2 can identify where the data is located by
the constraint, it will only look at the table(s) necessary and ignore the
others. The UNION ALL view will shield the application from knowing which
tables to access.
st ********** @ rogers.com 写道：
嗨...我们是一个大型机V7商店，计划即将升级到V8。我的
应用程序团队正在将IMS DB转换为DB / 2表...
大约40GB的未压缩（约20 GB压缩）数据传播到
10个分区。大约35％的数据是不活跃的。 （很容易
可识别）和有限（但有些）使用。我们在数据上需要2个
非分区索引。 DBA小组希望我们将
置于无效状态。数据进入一个单独的表，因为建立NPI的资源要求排序。将数据分成两个
表需要应用程序代码来决定访问哪个表需要
。在同意根据
操作要求进行应用程序更改之前，我想要一些明智的决定
这是否真的是必要的以及它是否会实现
DBA小组说它将会是什么。
Hi ... we''re a mainframe V7 shop planning an imminent upgrade to V8. My
application team is converting an IMS DB into a DB/2 table ...
approximately 40GB of uncompressed (~20 GB compressed) data spread over
10 partitions. Approximately 35% of the data is "inactive" (easily
identifiable as such) and of limited (but some) use. We require 2
non-partitioning indexes on the data. The DBA group would like us to
put the "inactive" data into a separate table because of the sort
resource requirements to build the NPIs. Separating the data into two
tables would require application code to decide which table needs to be
accessed. Before agreeing to make application changes based on
operational requirements, I''d like some informed decisions as to
whether this should really be necessary and whether it will achieve
what the DBA group says it will.
只是为了澄清你在谈论DB2 V8 for zOS，对吧？
-
Serge Rielau
DB2解决方案开发
IBM多伦多实验室
IOD会议
http://www.ibm.com/software/data/ond...ness/conf2006 /
st ***** *****@rogers.com 写道：
嗨...我们是一家大型机V7商店计划即将升级到V8。
Hi ... we''re a mainframe V7 shop planning an imminent upgrade to V8.
您的NPI是否与众不同？如果没有，如果你升级到V8，为什么不用
使用DPSI？这消除了与NPI相关的大多数问题。
P Adhia
Are your NPIs unique? If not and if you are upgrading to V8, why not
use DPSI? That eliminates most of the problmes associated with NPIs.
P Adhia
这篇关于大分区表问题的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
