重组UDB [英] Reorg on UDB
问题描述
这个问题是否适用于LUW上的UDB。假设我采用常规数据库
备份我的数据库
星期一：数据库备份< ts1>
星期二：表空间重新排列imagecopied< ts2>
星期五：数据库恢复并滚动转发到时间戳< ts3> on
星期三。
现在我的问题是：因为整个数据库是
滚转转发，我想数据库前滚操作将需要向前滚动*通过*日志中的数据重组（表空间
，周二重新排列）。表格空间
在
之后进行了图像复制的事实，重组在这种情况下不会增加任何值。这是正确的吗？
另外，我没有找到任何相当于LOG NO选项的选项
是
有效DB2 for OS / 390。似乎总是记录UDB上的Reorg。
对于具有数百万美元行的表来说，必须非常消耗日志和耗时。
TIA
Raquel。
This question if for UDB on LUW. Suppose I take regular database
backups of my database
Monday: database backup <ts1>
Tuesday: Tablespace reorged and imagecopied <ts2>
Friday: database restored and roll-forwarded to a timestamp <ts3> on
Wednesday.
Now my question is: because the entire database is being
roll-forwarded, I suppose the database roll forward operation will
have to roll forward *through* the data reorganization (of tablespace
that was reorged on Tuesday) in the log. The fact that the tablespace
was imagecopied after
the reorganization doesn''t add any value in this case. Is it correct?
Also, I did not find any option equivalent to the LOG NO option that
is
valid on DB2 for OS/390. Seems like the Reorg on UDB is always logged.
Must be pretty ''log consuming'' and ''time consuming'' for a table with
millions of rows.
TIA
Raquel.
推荐答案
你说得对，但有这种情况的变化可能会给b $ b帮助。我会假设你在V8上运行。
1）你将在你的场景中通过前滚重组。但是，当你说图像复制时，如果我理解备份了持有
reorg表的tblspc，那么：你可以恢复整个数据库，然后恢复
tblspc。 Tues的备份，然后前进，你不会支付重组
成本通过前滚，我相信这是一个更快的整体过程。
2）据我所知，在命令发布时，V8的经典重组命令是
记录以及表格的元数据和
它。因此记录不应成为问题。
3）记录将涉及，在V8及之后，如果，而不是经典的
reorg（无法访问）到表）你用ALOOW WRITE进行INPLACE重组。在
这种情况下，因为每个范围都被重组，所以会发生日志记录，因为这个
选项让你A）停止/开始B）暂停/恢复C）完全失败
恢复可用。
HTH，皮埃尔。
Raquel写道：
You are right but there are variations to this situation that might
help. I will presume you are running at V8.
1) You will reorg thru the roll forward in your scenario. However, when
you say image copy, if I understand backup the tblspc that held the
reorg table, then: You can restore the whole db, then restore the
tblspc. backup of Tues., then roll forward and you won''t pay the reorg
cost thru roll forward and I believe it is a faster overall process.
2) To my knowledge, up to and including V8 a classic reorg command is
logged as well as metadata for the table at command issue time and
that''s it. So logging should not be an issue.
3) Logging will be involved, in V8 and after, if, instead of a classic
reorg (no access to table) you do an INPLACE reorg with ALOOW WRITE. In
this case, as each extent is reorg''ed there is logging happening as this
option alloows you to A)Stop/Start B)Pause/Resume C) Fail with full
recovery available.
HTH, Pierre.
Raquel wrote:
这个问题是否适用于LUW上的UDB。假设我定期对我的数据库进行数据库备份
星期一：数据库备份< ts1>
星期二：表空间重新排列并且图像复制< ts2>
星期五：数据库恢复并滚动转发到时间戳< ts3>星期三。
现在我的问题是：因为整个数据库正在滚动转发，我想数据库前滚操作将不得不前滚*通过*日志中的数据重组（在星期二重新安排的表空间
）。表格空间
在重组之后进行了图像复制的事实在这种情况下并没有增加任何价值。这是正确的吗？
此外，我没有找到任何相当于在DB2 for OS / 390上有效的LOG NO选项的选项。似乎UDB上的Reorg总是被记录下来。
对于数百万行的表来说，必须非常消耗日志和耗时。
TIA
Raquel。
This question if for UDB on LUW. Suppose I take regular database
backups of my database
Monday: database backup <ts1>
Tuesday: Tablespace reorged and imagecopied <ts2>
Friday: database restored and roll-forwarded to a timestamp <ts3> on
Wednesday.
Now my question is: because the entire database is being
roll-forwarded, I suppose the database roll forward operation will
have to roll forward *through* the data reorganization (of tablespace
that was reorged on Tuesday) in the log. The fact that the tablespace
was imagecopied after
the reorganization doesn''t add any value in this case. Is it correct?
Also, I did not find any option equivalent to the LOG NO option that
is
valid on DB2 for OS/390. Seems like the Reorg on UDB is always logged.
Must be pretty ''log consuming'' and ''time consuming'' for a table with
millions of rows.
TIA
Raquel.
-
Pierre Saint-Jacques - 回复：attslobaljunk dot com的sesconsjunk
重建地址：删除两个垃圾并用
代替它们的符号。
IBM DB2 Cerified Solutions Expert - Administration
SES顾问公司
--
Pierre Saint-Jacques - Reply to: sesconsjunk at attglobaljunk dot com
Reconstruct address: Remove the two junk and replace at and dot by
their symbols.
IBM DB2 Cerified Solutions Expert - Administration
SES Consultants Inc.
您好Raquel，
REORG确实在移动数据时进行记录，并且这是一个
之后总是运行备份的好理由（对于大型机上的B / B $ B $也是如此，不是吗？）。如果日志记录对你来说是一个问题，那么IBM在DB2 V8（例如无限日志记录）中大大增强了它的价值。我知道
你在重组后进行备份。在这种情况下，你不能将
数据库还原到该备份映像吗？
Mauro。
Raquel ; < RA **************** @ yahoo.com>在消息中写道
news：9a ************************** @ posting.google.c om ...
Hi Raquel,
It''s true that REORG does logging when moving data around, and that''s one
good reason to always run a backup afterwards (the same is true for DB2 on
the mainframe, isn''t ?). In case logging is an issue for you, IBM has
greatly enhanced it in DB2 V8 (infinite logging for instance). I understand
that you take a backup after the reorg. In that case, can''t you restore the
database to that backup image ?
Mauro.
"Raquel" <ra****************@yahoo.com> wrote in message
news:9a**************************@posting.google.c om...
这个问题是否适用于LUW上的UDB。假设我定期对我的数据库进行数据库备份
星期一：数据库备份< ts1>
星期二：表空间重新排列并且图像复制< ts2>
星期五：数据库恢复并滚动转发到时间戳< ts3>星期三。
现在我的问题是：因为整个数据库正在滚动转发，我想数据库前滚操作将不得不前滚*通过*日志中的数据重组（在星期二重新安排的表空间
）。表格空间
在重组之后进行了图像复制的事实在这种情况下并没有增加任何价值。这是正确的吗？
此外，我没有找到任何相当于在DB2 for OS / 390上有效的LOG NO选项的选项。似乎UDB上的Reorg总是被记录下来。
对于数百万行的表来说，必须非常消耗日志和耗时。
TIA
Raquel。
This question if for UDB on LUW. Suppose I take regular database
backups of my database
Monday: database backup <ts1>
Tuesday: Tablespace reorged and imagecopied <ts2>
Friday: database restored and roll-forwarded to a timestamp <ts3> on
Wednesday.
Now my question is: because the entire database is being
roll-forwarded, I suppose the database roll forward operation will
have to roll forward *through* the data reorganization (of tablespace
that was reorged on Tuesday) in the log. The fact that the tablespace
was imagecopied after
the reorganization doesn''t add any value in this case. Is it correct?
Also, I did not find any option equivalent to the LOG NO option that
is
valid on DB2 for OS/390. Seems like the Reorg on UDB is always logged.
Must be pretty ''log consuming'' and ''time consuming'' for a table with
millions of rows.
TIA
Raquel.
" Mauro Cazzari" <毫安*********** @ sas.com>在消息中写道
news：bo ********** @ license1.unx.sas.com ...
"Mauro Cazzari" <ma***********@sas.com> wrote in message
news:bo**********@license1.unx.sas.com...
嗨拉奎尔，
REORG在移动数据时确实记录了日志，这是之后总是运行备份的一个好理由（大型机上的DB2也是如此，isn''' t？）。如果日志记录对您来说是个问题，那么IBM在DB2 V8（例如无限日志记录）中大大增强了它。我知道你在重组后进行备份了。在这种情况下，你不能将数据库的
恢复到该备份映像吗？
Mauro。
Hi Raquel,
It''s true that REORG does logging when moving data around, and that''s one
good reason to always run a backup afterwards (the same is true for DB2 on
the mainframe, isn''t ?). In case logging is an issue for you, IBM has
greatly enhanced it in DB2 V8 (infinite logging for instance). I understand that you take a backup after the reorg. In that case, can''t you restore the database to that backup image ?
Mauro.
在DB2 for OS / 390上对表空间进行重组通常可以在没有
日志记录的情况下完成（如果指定的话）。这使得表空间处于副本状态待定
状态，除非指定图像副本（备份）自动完成
作为重组的一部分。可以读取处于复制暂挂状态的表空间，但不会更改
。相反，不记录和执行图像复制的结果与使用日志记录的重组相同，并且具有额外的优势，即用于恢复的最近图像副本目的。如果DB2 LUW
以这种方式工作会很好。
日志记录问题有一些例外，例如DB2中的在线重新排序
for OS / 390，但这是一个稍微不同的主题。
但真正的问题是关于数据库备份和
$ b $之间的重叠b进行前滚恢复时的表空间备份（在不同时间）。
在DB2 OS / 390上，所有备份（映像副本）都在表空间级别，而不是
数据库（或子系统）。
On DB2 for OS/390 a reorg of the tablespace can generally be done without
logging (if specified that way). This puts the tablespace in copy pending
status, unless an image copy (backup) was specified to automatically be done
as part of the reorg. Tablespaces in copy pending status can be read but not
changed. The combination of not logging and doing an image copy instead is
about the same as a reorg with logging, and has the added advantage of a
more recent image copy for recovery purposes. Would be nice if DB2 LUW
worked this way.
There are some exceptions to the logging issue such as on-line reorgs in DB2
for OS/390, but that is a slightly different subject.
But the real question was about the overlap between a database backup and a
tablespace backup (at different times) when doing a roll-forward recovery.
On DB2 OS/390 all backups (image copies) are at the tablespace level, not
database (or sub-system).
这篇关于重组UDB的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
