有人在Linux x86上使用DB2 9，请检查...... [英] Anybody using DB2 9 on Linux x86, please, examine...
问题描述
我几乎可以肯定我找到了坏虫，但有一段时间我不能确认也不能拒绝这个。
如果有人可以独立测试它自己的系统，我会非常感激。
可能的错误是：
*** *************
*** DB2拒绝大于4Gb的DEVICE容器。 ***
****************
DB2版本受影响（至少）：
| ＃db2level
| DB21085I实例dbi使用32表示32。位和DB2代码版本SQL09012级别标识符01030107。
|信息令牌是DB2 v9.1.0.2，s070210，MI00183和Fix Pack2。
测试相当简单：只是尝试在任何数据库中
| ＃db2 create tablespace X pagesize 4096由数据库管理（device''/ some / device''1048576）
设备必须大于4G，并且向DB2指示的页面数量：任何数字> = 1048576和< =（设备大小）。 1048576因为1048576 * 4096 = 0x100000000，即4G。
如果你得到回复：
| SQL1422N容器的大小无效。 SQLSTATE = 54039
-
康斯坦丁安德列夫。
I''m almost sure I''ve found bad bug, but for a while I can''t neither confirm nor reject this.
If anybody could make an independent test on it''s own system, I''d appreciate it very much.
The possible bug is:
****************
*** DB2 refuses DEVICE containers bigger than 4Gb. ***
****************
DB2 version affected ( at least ):
| # db2level
| DB21085I Instance "dbi" uses "32" bits and DB2 code release "SQL09012" with level identifier "01030107".
| Informational tokens are "DB2 v9.1.0.2", "s070210", "MI00183", and Fix Pack "2".
The test is rather simple: just try in any database
| # db2 create tablespace X pagesize 4096 managed by database using ( device ''/some/device'' 1048576 )
The device must be bigger than 4G, and amount of pages indicated to DB2: any number >= 1048576 and <= (device size). The 1048576 because 1048576 * 4096 = 0x100000000, that is 4G.
If you get in response:
| SQL1422N The size of the container is invalid. SQLSTATE=54039
then you are affected too.
--
Konstantin Andreev.
推荐答案
以下哪一部分：
" ...它将在DB2 9的下一个修订包中修复。
$ b来自Haider的帖子$ b不满意？
DB2开发不习惯通过指责操作系统来拒绝修复。
会有修复（期间） 。
干杯
Serge
-
Serge Rielau
DB2解决方案开发
IBM多伦多实验室
Which part of:
"...it will be fixed in the next fixpack of DB2 9."
from Haider''s post was unsatisfying?
DB2 Development is not in the habit of refusing fixes by blaming the OS.
There will be a fix (period).
Cheers
Serge
--
Serge Rielau
DB2 Solutions Development
IBM Toronto Lab
Serge Rielau写道：
Serge Rielau wrote:
以下哪一部分：...它将在DB2 9的下一个修订包中修复。来自海德尔的帖子不满意？
Which part of: "...it will be fixed in the next fixpack of DB2 9." from Haider''s post was unsatisfying?
目前还不清楚Haider和我讨论了同样的错误：......发现了类似的问题......。 Haider指责破坏的BLKGETSIZE64 ioctl（）调用，而对我而言，ioctl是正确的。 *没有人确认我在该主题中引入的问题，所以我决定提出更广泛的测试。
确认后，此测试变得过多。
谢谢你好。
-
康斯坦丁安德列夫。
It was not clear that Haider and I discussed the same bug: "...a similar problem was found ...". Haider blamed the broken BLKGETSIZE64 ioctl() call, whereas it''s obvious for me, that ioctl is correct. *Nobody* had confirmed the issue I introduced in that thread, so I decided to raise wider testing.
After your confirmation this testing becomes excessive.
Thank you.
--
Konstantin Andreev.
Konstantin Andreev写道：
Konstantin Andreev wrote:
我几乎可以肯定我发现了一些坏虫，但有一段时间我不能这样做，不能确认也不会拒绝这个。
如果有人可以对它自己的系统进行独立测试，我会非常感激b $ b。
I''m almost sure I''ve found bad bug, but for a while I can''t neither
confirm nor reject this.
If anybody could make an independent test on it''s own system, I''d
appreciate it very much.
我已经确认了这一点并在你的上一个帖子中发布了回复18:32
- 一个*小时*在你发布这个延续之前你的传奇。
你还想要什么？
APAR？打开的Apar是LI71236。
行代码行号改变了吗？
如果三个人告诉你它将在DB2中修复（不是Linux）
即将推出的Fix Pack 3 - 也许你可以接受这样的事实：它将*固定在FP3中固定
。
任何进一步令人震惊的消息都必须被认为是糟糕的味道。
Jan M. Nelken
I have confirmed this and posted reply in your previous thread at 18:32
- an *one hour* before you posted this continuation of your saga.
What else do you want?
APAR? the open Apar is LI71236.
Line numbers of line code changed?
If three people are telling you that it will be fixed in DB2 (not Linux)
upcoming Fix Pack 3 - may be you can accept fact that it *will be* fixed
in FP3.
Any further alarming news will have to be assumed to be bad taste trolling.
Jan M. Nelken
这篇关于有人在Linux x86上使用DB2 9，请检查......的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
