Helen Johnson writes:
> I have run into a 2 gig file size limit on the AIX box. Does anyone have
any suggestions around this or do I need to put these tables in DMS space?
DMS is really not that big a deal, so this specific issue (table size
limits) might be the way to convince the customer to embrace DMS. The DMS
containers don't have to be raw; you can mount the containers on existing
file systems.
You mentioned that you were concerned about maximizing storage space, but
there are ways you can minimize the amount of unused space in a DMS
tablespace. Since you already know approximately how big the tables will
be, you should be able to estimate how much DMS storage you'll need. Just
pick a container size (perhaps 1000MB - 1500MB) and start off with just a
couple of containers in the tablespace. As the tablespace fills up, you can
add more containers until all the data fits. If you find that there is too
much unused space when you're finished loading the tables, you can shrink
the size of the containers by backing up the tablespace and doing a
redirected restore to smaller containers.
If, in spite of your persuasive explanation, DMS is still not an option,
then you'll need to implement some kind of partitioning scheme that
involves splitting the data across multiple SMS tables that are each under
the 2GB limit, and then fusing them together with a view that joins them
all via UNION ALL. Since you say that the tables will not be updated once
they are loaded, there shouldn't be any problem with the users' inability
to update or insert into the view that joins the partitioned tables (unless
you're using an INSTEAD OF trigger on DB2 V8.1).
Good Luck,
Fred Sobotka
IBM Certified Database Administrator - DB2 UDB V8.1 for Linux, Unix, and
Windows
CollegeNET, Inc.
-
::: When replying to the list, please use 'Reply-All' and make sure
::: a copy goes to the list ([EMAIL PROTECTED]).
*** To unsubscribe, send 'unsubscribe' to [EMAIL PROTECTED]
*** For more information, check http://www.db2eug.uni.cc
