×
The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.
rob@xxxxxxxxx wrote:
So what you are saying is that it doesn't move the data
right at the time you run CHGPF, nor does it fire off a
background task.
Correct [see Note:], the CHGPF SRCFILE(*NONE) UNIT(*SSD) [where
all defaults are *SAME] would not move any data. That request just
changes the attribute at the *FILE, *MEM, & *QDDS object levels.
New members will have their dataspace created from segments on the
*SSD, and existing members have their dataspaces acquire new
segments on the *SSD.
Instead it waits until certain reorgs or alter tables are
executed against the file.
Not just reorganize or alter, but for whenever "new data
segments" are added since the attribute change; i.e. the specified
UNIT() attribute would then be used to designate from where the
storage should be obtained, for those new data segments. For an
ALTER or a CHGPF SRCFILE(named) UNIT(*SSD), the new\altered file is
created with UNIT(*SSD), its member(s) added with UNIT(*SSD), its
data segments created on\from the *SSD, and the data copied from the
old file.member.dataspace with its data segments on whatever units.
How do you verify that it is REALLY on SSD now?
There is no "map dataspace segments" feature to show which
SegmentIDentifier make up the dataspace, nor a "map SID" feature to
show on which unit\drive it resides. The STRSST D/A/D using a
[formatted] dump of the *QDDS object would show the segment table,
and the segment header of each segment [somehow] identifies its
location.
I'm wondering how to do this. I'd hate to have the first month
end or something come to a creeping crawl as the files are
reorged because the data is then being moved at the same time
(but again, maybe I need to get into a SSD frame of mind?).
Not sure what "to do this" would be. To move the existing data
onto SSD? That would be the ALTER, RGZPFM ALWCANCEL(*NO), or
restore of the changed file.
What about month end would move the data causing some implicit
reorganize to move the data that any other I/O activity would not?
Unless the dataspace is adding new segments from the designated
unit, the UNIT() specification is not even in play; i.e. nothing is
going to cause the existing data to move except something like an
ALTER which creates a new file.member and thus its all-new dataspace
segments from the specified UNIT, or a dedicated reorganize which
copies the active row data from the existing dataspace into a new
dataspace with the specified order.
Note: See Sue Baker's post and "DB2 and SSD integration" section
of the following documents:
http://www-03.ibm.com/systems/resources/ssd_ibmi.pdf
http://www-03.ibm.com/support/techdocs/atsmastr.nsf/5cb5ed706d254a8186256c71006d2e0a/0c819f965197f53c8625765f0004b3e5/$FILE/SSD4i.pdf
reference to TD105280 noted in above document can be searched at:
http://www.ibm.com/support/techdocs/atsmastr.nsf
Hmmm.... OK, so now that I see what Sue wrote and having found
some references to PTF changes to the behavior, maybe your questions
and what seems alluded by "reorged" is in regard to new functions of
both synchronous and asynchronous movement of the existing data by
the CHGPF. Sorry, I was not aware of those changes. Seems like
without some specific control feature, there will be no ability to
predict when or by when any asynchronous movement will be able to
complete; I know nothing of its implementation. The synchronous
data movement apparently is already available by PTF and will be
performed while the CHGPF is active. However there is also note of
asynchronous data movement to *SSD, done in some background
[presumably LIC DB] tasks which I expect would not be predictable
for its impact, for lack of any comment on any available control
that can be applied to the background processing; i.e. any such
background data movement could indeed impact some later activity
[e.g. month-end processing] when that later processing is started
before the background data movement completes. The impact would
presumably be much like what would be for ASP balancing when the
data segments of a database file are being moved.
Regards, Chuck
As an Amazon Associate we earn from qualifying purchases.