This ALTER causes all transaction on the table happening between the ALTER
and the next COMMIT to NOT be logged.
If you have a roolback or an abnormal end of DB2, the table will not be able
to be used again. It becomes inaccessible.
When you have to perform a roll forward through that event, the roll forward
meets the ALTER command and puts the table in "inaccessible" mode, ignores
all transactions concerning that table and finishes to the end of the roll
forward. After which, your db will confirm with a message that all is cool
but that table is inaccessible. The only thing you can do to the table is
drop and recreate if needed.
It's highly recommended that if the table is to be used and/or kept after
the ALTER, when you finish the job you should take a backup of the tblspce
that holds that table. This is way your docs. Recommend putting that table
in its own tablespace, alone.
Whether you use WITH EMPTY TABLE or not is irrelevant the results are the
same. No data, no table available after the roll forward if no tablespace
backup was taken after the ALTER/COMMIT.

Hope this helps, Pierre.

-----Message d'origine-----
De : Michael Bell
[mailto:db2udbdba-ezmlmshield-x4625798.[Email address protected]
Envoyé : 23 février, 2007 12:47
À : LazyDBA Discussion
Objet : Alter Table Not Logged - Rollforward

I've seen issues online regarding the use of ALTER TABLE NOT LOGGED
INITIALLY WITH EMPY TABLE and rollforward recovery. Does anyone know
specifically what problem this causes? I don't care about dropping and
recreating the table if needed, but I don't want to prevent the rest of
the database from coming back up.



Thank you,

Michael Bell





---------------------------------------------------------------------
TO REPLY TO EVERBODY , PLEASE CLICK REPLY-ALL, NOT JUST REPLY
To post a dba job: http://jobs.lazydba.com
To Subscribe : http://www.LazyDBA.com
To unsubscribe: http://www.lazydba.com/unsubscribe.html




DB2 & UDB email list listserv db2-l LazyDBA home page