I'm not sure if they'll be migrated if read. But I don't think they'll be migrated just because you name the UNIT. You'll have to do something overt to make them move.
Look at the ASP balance commands. They'll probably move the sectors to the SSD.
Remember that DB2 doesn't store records on disk. It stores records in virtual memory. Virtual memory pages are swapped to disk sectors. Storage preferences like the UNIT parameter are suggestions to memory management.
-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Robert Rogerson
Sent: Thursday, February 28, 2013 11:14 AM
To: Midrange Systems Technical Discussion
Subject: Re: Migrating a file to SSD...
<snip>
If you only add records and never read them, what good is putting the file
on SSD?
</snip>
Oops, I meant write and never update...wait, are you saying they will get
migrated even if read (not for update)?
On 2013-02-28 11:51 AM, Dan Kimmel wrote:
<snip>
If I wrote a program (I'm not saying I'll do this) to update every record
in the file it would then be 100% on the SSD?
</snip>
Yes, but there are easier ways. Take Sue Baker's suggestion and call support.
If you only add records and never read them, what good is putting the file on SSD?
-----Original Message-----
From: [1]midrange-l-bounces@xxxxxxxxxxxx [[2]mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Robert Rogerson
Sent: Thursday, February 28, 2013 10:31 AM
To: Midrange Systems Technical Discussion
Subject: Re: Migrating a file to SSD...
@Dan,
<snip>
Next time you modify a sector of that file paged in from it's old location, it'll page back out to SSD. In other words, 92% of that file hasn't been used since you changed the UNIT.
</snip>
So if this file is only added to the existing HDD allocation would never
decrease?
And the SSD would be increased only for the newly added records?
If I wrote a program (I'm not saying I'll do this) to update every record
in the file it would then be 100% on the SSD?
Thanks,
Rob
On 2013-02-28 11:08 AM, Dan Kimmel wrote:
Next time you modify a sector of that file paged in from it's old location, it'll page back out to SSD. In other words, 92% of that file hasn't been used since you changed the UNIT.
-----Original Message-----
From: [[3]1]midrange-l-bounces@xxxxxxxxxxxx [[2][4]mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Robert Rogerson
Sent: Thursday, February 28, 2013 9:55 AM
To: [[5]3]midrange-l@xxxxxxxxxxxx
Subject: Migrating a file to SSD...
Hi All,
Yesterday we attempted to migrate a large file (37 Gig) to the SSD using
CHGPF. When I check the file (DSPFD) it confirms that UNIT(*SSD) is now
changed.
This morning when I ran a query on syspartitiondisk it told my that 8% (33
Gig on HDD and 4 Gig on SDD) had been migrated. I was expecting this
percentage to be higher if not at 100%.
Am I misunderstanding? If I specify the UNIT on a file to be SSD does
that not mean that the entire file will be migrated to the SSD?
Thanks,
Rob
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list To post a message email: [[6]4]MIDRANGE-L@xxxxxxxxxxxx To subscribe, unsubscribe, or change list options,
visit: [5][7]
http://lists.midrange.com/mailman/listinfo/midrange-l
or email: [[8]6]MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please take a moment to review the archives at [7][9]
http://archive.midrange.com/midrange-l.
References
Visible links
1. [10]mailto:midrange-l-bounces@xxxxxxxxxxxx
2. [11]mailto:midrange-l-bounces@xxxxxxxxxxxx
3. [12]mailto:midrange-l@xxxxxxxxxxxx
4. [13]mailto:MIDRANGE-L@xxxxxxxxxxxx
5. [14]
http://lists.midrange.com/mailman/listinfo/midrange-l
6. [15]mailto:MIDRANGE-L-request@xxxxxxxxxxxx
7. [16]
http://archive.midrange.com/midrange-l
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list To post a message email: [17]MIDRANGE-L@xxxxxxxxxxxx To subscribe, unsubscribe, or change list options,
visit: [18]
http://lists.midrange.com/mailman/listinfo/midrange-l
or email: [19]MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please take a moment to review the archives at [20]
http://archive.midrange.com/midrange-l.
References
Visible links
1. mailto:midrange-l-bounces@xxxxxxxxxxxx
2. mailto:midrange-l-bounces@xxxxxxxxxxxx
3. mailto:1]midrange-l-bounces@xxxxxxxxxxxx
4. mailto:midrange-l-bounces@xxxxxxxxxxxx
5. mailto:3]midrange-l@xxxxxxxxxxxx
6. mailto:4]MIDRANGE-L@xxxxxxxxxxxx
7.
http://lists.midrange.com/mailman/listinfo/midrange-l
8. mailto:6]MIDRANGE-L-request@xxxxxxxxxxxx
9.
http://archive.midrange.com/midrange-l
10. mailto:midrange-l-bounces@xxxxxxxxxxxx
11. mailto:midrange-l-bounces@xxxxxxxxxxxx
12. mailto:midrange-l@xxxxxxxxxxxx
13. mailto:MIDRANGE-L@xxxxxxxxxxxx
14.
http://lists.midrange.com/mailman/listinfo/midrange-l
15. mailto:MIDRANGE-L-request@xxxxxxxxxxxx
16.
http://archive.midrange.com/midrange-l
17. mailto:MIDRANGE-L@xxxxxxxxxxxx
18.
http://lists.midrange.com/mailman/listinfo/midrange-l
19. mailto:MIDRANGE-L-request@xxxxxxxxxxxx
20.
http://archive.midrange.com/midrange-l
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list To post a message email: MIDRANGE-L@xxxxxxxxxxxx To subscribe, unsubscribe, or change list options,
visit:
http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please take a moment to review the archives at
http://archive.midrange.com/midrange-l.
As an Amazon Associate we earn from qualifying purchases.