Conference orarep::nomahs::rdb_60

doesn't seem like it'd be too hard to try out barry.

Did some further checking.  The "store randomly" requires at least 2
storage areas, so that's not applicable.  As Norm kindly suggested,
I'll give it a test.

~  I saw note 212.0 and Ian's reply 212.1 (NOMAHS::RDB_41) which indicates
~that it couldn't be done (at that point in time).  Couldn't locate any
~further verbage on the subject.

This note and its replies is discussing storage area failover.  This is not
supported for table rows (just segmented strings).

~  I have a customer that has a storage area that is getting full and
~would like to create a second storage area and have new rows only added
~to the new area.  He does not want to REORGANIZE, no indexes.

If they start with this:

	create storage map M for T
	    store in AREA_A;

They can perform this:

	alter storage map M
	    store using (C)
		in AREA_B with limit of (??)
		otherwise AREA_A;

Here C and ?? is a column and partitioning key they can supply.  Or they could
easily add a dummy column. e.g.

	alter table T
	    add column C integer default 1;

Then the storage map could be:

	alter storage map M
	    store using (C)
		in AREA_B with limit of (1)
		otherwise AREA_A;

As time goes on the column C could be changed to have a DEFAULT of 2 and so
start using a new area...

[aside: this will also work by making C a COMPUTED BY column.  However, this
will only work once because you can't ALTER a computed by column - maybe in
the next release]

~  Can he use the "alter storage map" command specifying only the new area
~in the "STORE IN area-name" clause.

Yes - see the example above.

~Will he be able to fetch data from the old area??

Yes - see the example above.

~Will the "RANDOMLY ACROSS" clause buy him anything??

No - see the first part of this reply.

enjoy,

Ian

re .3

  Ian, thanks for the response.  I'll make sure that I understand it
before I pass the information along to my customer.

  BTW, if anyone is following the note, I ran a test.

     I used the "departments" info in the mf_personnel test db.

     I created a new storage area.

     I used the alter storage map command and specified the new storage
     area in the "store" option:

          alter storage map departments_map store in new_area_name.

     I was able to access the "old" data. Wonderfulness.

     I then inserted a new row, returning the dbkey, which went into
     the new area.  Wonderfulness.

     I then updated an existing row, returning the dbkey, which also
     pointed to the new area.  Hmmmmmmm.

     I then got curious and "dumped" the "old" storage area (departments)
     and then the new area.  Turns out that the "alter storage map" appears
     to have moved *all* the rows from the old area to the new.

     My customer's storage area is 7.5 million blocks.  Good grief, I'm
     glad that I didn't suggest he do the same thing!!!!

>          alter storage map departments_map store in new_area_name.

you got what you asked for barry.  your alter is using only one storage
area, so all the data was moved to the new one.  re-read .3

~          alter storage map departments_map store in new_area_name.
~
~     I was able to access the "old" data. Wonderfulness.
~
~     I then inserted a new row, returning the dbkey, which went into
~     the new area.  Wonderfulness.
~
~     I then updated an existing row, returning the dbkey, which also
~     pointed to the new area.  Hmmmmmmm.
~
~     I then got curious and "dumped" the "old" storage area (departments)
~     and then the new area.  Turns out that the "alter storage map" appears
~     to have moved *all* the rows from the old area to the new.

If the old area does not appear in the new storage map we automatically
reorganize the data.  If you followed by directions you see that the data
doesn't move (or at least I hope so :-)

Ian