|
Hi, Karl:This maximum number of records per file is because the record number is stored as a 4-byte (32-bit) unsigned binary number internally. (That number includes "deleted" records, since they still occupy a "slot.") However, this is a "per member" limit. But a physical file can have up to 32,767 members. (See the CHGPF command to change the maximum number of members.)
You might also want to change files with many millions of records (using CHGPF) to specify REUSEDLT(*YES). Otherwise, do you really want to have to do a RGZPFM on a file with that many records? (Even with the "reorganize while active" support in V5R3 and above.)
As of V5R3, i5/OS DB2/UDB supports "partitioned tables" where you can distribute the records among several files (or members), using a "hash" or other algorithm to determine in which "table" (or member) this record "belongs" based on the primary key. So, you can now have DB2 tables with more than 4-billion rows.
You will also need to change your applications to use embedded SQL to work with such partitioned tables.
See http://publib.boulder.ibm.com/infocenter/iseries/v5r3/index.jsp?topic=/dbp/rbafoappmax.htm
And search the V5R3 or V5R4 InfoCenter for "partitioned tables" to learn more.
Does that help? Mark S. Waterbury Karl Lauritzen Jr. wrote:
We have a file that is getting 5 million new records per year (image system), plus some history PF with members that have over 60 million records (10 years company production) and it concerned me as to iseries maximums. I looked up and a PF can have up to 4.2 billion records. So Ihave time.But I am just curious but has anyone ever seen a system or had one where you got close to the limit of records in a PF (4.2 billion) or the size of a LF access path? Why a maximum too made me curious. I would think you would run out of disk before a maximum of records.Oh and from a real business standpoint not a run away application.Karl Lauritzen Jr. National Lloyds Insurance Company American Summit Insurance Company
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.