Re: Design for backup in mind Was: Backup strategy

[CRPence <crp@xxxxxxxxxxxxxxxxxxxx>]

  The identity value was however, saved and restored in the given 
scenario.  If the SAVOBJ is moved after the first two inserts, review 
the change to verify that.  The applied changes made an effective INSERT 
OVERRIDING request, thus ignoring what the identity value would be 
because the data changes being applied must not generate a new value.
  FWiW: The journaled changes are the data.  The attribute of identity 
value at each insert is not row data, and the value is not separately 
recorded/tracked neither in its own entry nor as part of the row entry. 
 The identity value is not part of the ESD [data only], nor is it in 
the /Entry Details/ as presented in DSPJRN.  The identity value must be 
reset in the event of DR by ALTER TABLE RESTART WITH.  AFaIK the HA 
providers incorporate that action in a switch over.  It is of course 
significantly faster to determine a new starting point in the rare 
occasion of a true DR, than to constantly track/store the value; not to 
dismiss a valid point that it would be nice if it could be applied, but 
the cost is an issue that must be considered.  Note that an identity 
should be created with a PRIMARY KEY to prevent duplicates; and a 
duplicate exception _could_ signal an attempt to investigate/reset the 
restart value.  A stored procedure could be created for each file that 
establishes its RESTART value; to be run as part [end] of DR.

Regards, Chuck
-- All comments provided "as is" with no warranties of any kind 
whatsoever and may not represent positions, strategies, nor views of my 
employer

rob@xxxxxxxxx wrote:
> Ok let's say you're current with hardware and software.  Let's also say 
> you have the capability to learn and adapt.  So you've read about such 
> things as "Identity columns"  "sequences", etc.  Your have the freedom to 
> design from scratch.  Now, you want to write your application with some 
> stability in mind.  You just read some emails between Rob and Jeff and say 
> this saving of journal receivers on a periodic basis bears some merit. 
> Now, let's say your concern is, I have a new order number.  I could use an 
> identity column.  However how would this receiver strategy handle that? 
> So, I run a test.
>
> CREATE TABLE ROB/DESIGN 
>   (ORDERNBR INT NOT NULL AS IDENTITY,
>    CUSTNBR INT NOT NULL) 
> SAVOBJ OBJ(DESIGN) LIB(ROB) DEV(*SAVF) SAVF(ROB/ROB)
> INSERT INTO ROB/DESIGN (CUSTNBR) VALUES(1)
> INSERT INTO ROB/DESIGN (CUSTNBR) VALUES(1)
> INSERT INTO ROB/DESIGN (CUSTNBR) VALUES(2)
> INSERT INTO ROB/DESIGN (CUSTNBR) VALUES(3)
> select * from rob/design
> +....1....+....2....+....
>  ORDERNBR         CUSTNBR
>         1               1
>         2               1
>         3               2
>         4               3
> ****  End of data  ******
> RSTOBJ OBJ(DESIGN) SAVLIB(ROB) DEV(*SAVF) OBJTYPE(*FILE) SAVF(ROB/ROB)
> APYJRNCHG JRN(ROB/QSQJRN) FILE((ROB/DESIGN)) RCVRNG(*CURRENT)
> 4 entries applied to 1 objects.
> INSERT INTO ROB/DESIGN (CUSTNBR) VALUES(27)
> select * from rob/design
> +....1....+....2....+....
>  ORDERNBR         CUSTNBR
>         1               1
>         2               1
>         3               2
>         4               3
>         1              27
> ****  End of data  ******
>
> Dang nab it!!!!  Just what I was concerned about!!!  The current value for 
> the identity column is not journaled!
> Time for another DCR.
>
> I suppose you could use a "sequence" and journal the data area.
>
> Rob Berendt