Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

TRUNCATE TABLE really exists, or?

117 views
Skip to first unread message

Troels Arvin

unread,
Jan 31, 2007, 6:13:13 PM1/31/07
to
Hello,

Until this date, I believed that DB2 has no TRUNCATE TABLE command. But
then I came across
http://publib.boulder.ibm.com/infocenter/db2luw/v9/topic/com.ibm.db2.udb.admin.doc/doc/c0023297.htm
where it says:

After an ALTER TABLE statement containing
REORG-recommended operations, you can execute
only the following statements on a table:
REORG TABLE
DROP TABLE
ALTER TABLE
RENAME TABLE
TRUNCATE TABLE

So there _is_ a TRUNCATE TABLE command, or?
My DB2 Express-C v. 9.1 will NOT accept a "TRUNCATE TABLE foo" command.

--
Regards,
Troels Arvin <tro...@arvin.dk>
http://troels.arvin.dk/

Serge Rielau

unread,
Feb 1, 2007, 9:46:18 AM2/1/07
to
Troels Arvin wrote:
> Until this date, I believed that DB2 has no TRUNCATE TABLE command. But
> then I came across
> http://publib.boulder.ibm.com/infocenter/db2luw/v9/topic/com.ibm.db2.udb.admin.doc/doc/c0023297.htm
> where it says:
>
> After an ALTER TABLE statement containing
> REORG-recommended operations, you can execute
> only the following statements on a table:
> REORG TABLE
> DROP TABLE
> ALTER TABLE
> RENAME TABLE
> TRUNCATE TABLE
Doc defect... don't loose your faith just yet.
--
Serge Rielau
DB2 Solutions Development
IBM Toronto Lab

jefftyzzer

unread,
Feb 1, 2007, 1:12:59 PM2/1/07
to
On Jan 31, 3:13 pm, Troels Arvin <tro...@arvin.dk> wrote:
> Hello,
>
> Until this date, I believed that DB2 has no TRUNCATE TABLE command. But
> then I came acrosshttp://publib.boulder.ibm.com/infocenter/db2luw/v9/topic/com.ibm.db2....

> where it says:
>
> After an ALTER TABLE statement containing
> REORG-recommended operations, you can execute
> only the following statements on a table:
> REORG TABLE
> DROP TABLE
> ALTER TABLE
> RENAME TABLE
> TRUNCATE TABLE
>
> So there _is_ a TRUNCATE TABLE command, or?
> My DB2 Express-C v. 9.1 will NOT accept a "TRUNCATE TABLE foo" command.
>
> --
> Regards,
> Troels Arvin <tro...@arvin.dk>http://troels.arvin.dk/

Hi, Troels:

This is somewhat well-known, so forgive me if you already know it, but
if it happens that you're looking not for the TRUNCATE command per se
but rather in the meantime a way to accomplish the same thing in the
absence of an explicit TRUNCATE command, in DB2 there are two ways to
get the same result of fast cleanout of all rows in a table:

1. ALTER TABLE <> NOT LOGGED INITIALLY WITH EMPTY TABLE;
2. IMPORT from /dev/null

Regards,

--Jeff

Troels Arvin

unread,
Feb 1, 2007, 2:42:03 PM2/1/07
to
Hello,

On Thu, 01 Feb 2007 10:12:59 -0800, jefftyzzer wrote:
> a way to accomplish the same thing in the
> absence of an explicit TRUNCATE command, in DB2 there are two ways to
> get the same result of fast cleanout of all rows in a table:
>
> 1. ALTER TABLE <> NOT LOGGED INITIALLY WITH EMPTY TABLE;
> 2. IMPORT from /dev/null

Which one requires the least privileges?

jefftyzzer

unread,
Feb 1, 2007, 3:19:09 PM2/1/07
to

According to the SQL Reference Volume 2 and the Command Reference,
respectively:

ALTER needs at least one of the following:

ALTER on the table to be altered
CONTROL on the table to be altered
ALTERIN on the schema of the table
SYSADM
DBADM

IMPORT (to an existing table using the REPLACE or REPLACE_CREATE
option) requires one of the following:

SYSADM
DBADM
CONTROL on the table or view
INSERT, SELECT, and DELETE on the table or view

So I suppose IMPORT requires the least privileges, if you are generous
in giving INSERT, SELECT, and DELETE.

--Jeff

Troels Arvin

unread,
Feb 1, 2007, 5:51:57 PM2/1/07
to
Hello,

On Thu, 01 Feb 2007 12:19:09 -0800, jefftyzzer wrote:
> According to the SQL Reference Volume 2 and the Command Reference,
> respectively:

[...]

Thanks. My summary:
http://troels.arvin.dk/db/rdbms/#bulk-truncate_table-db2

jefftyzzer

unread,
Feb 1, 2007, 7:49:20 PM2/1/07
to

Nice work--very useful!

--Jeff

Troels Arvin

unread,
Feb 2, 2007, 4:08:18 AM2/2/07
to
Hello,

On Thu, 01 Feb 2007 10:12:59 -0800, jefftyzzer wrote:
> in DB2 there are two ways to
> get the same result of fast cleanout of all rows in a table:
>
> 1. ALTER TABLE <> NOT LOGGED INITIALLY WITH EMPTY TABLE;
> 2. IMPORT from /dev/null

Is there a performance difference between these two approaches?

Serge Rielau

unread,
Feb 2, 2007, 8:43:35 AM2/2/07
to
Troels Arvin wrote:
> Hello,
>
> On Thu, 01 Feb 2007 10:12:59 -0800, jefftyzzer wrote:
>> in DB2 there are two ways to
>> get the same result of fast cleanout of all rows in a table:
>>
>> 1. ALTER TABLE <> NOT LOGGED INITIALLY WITH EMPTY TABLE;
>> 2. IMPORT from /dev/null
>
> Is there a performance difference between these two approaches?
Not that I'm aware of, but option 2 is fully recoverable.
If you truncate an important table using ALTER TABLE you should follow
it up with a backup, otherwise roll forward recovery will hiccup.

Cheers
Serge

Troels Arvin

unread,
Feb 2, 2007, 3:36:15 PM2/2/07
to
On Fri, 02 Feb 2007 08:43:35 -0500, Serge Rielau wrote:
>>> 1. ALTER TABLE <> NOT LOGGED INITIALLY WITH EMPTY TABLE;
>>> 2. IMPORT from /dev/null
>>
>> Is there a performance difference between these two approaches?
> Not that I'm aware of, but option 2 is fully recoverable.
> If you truncate an important table using ALTER TABLE you should follow
> it up with a backup, otherwise roll forward recovery will hiccup.

Ouch. I'll stay away from ALTER TABLE ... NOT LOGGED INITIALLY. (I've
recently been bit by a rather time consuming situation because we tried to
cut some corners using NOT LOGGED INITIALLY.)

Ian

unread,
Feb 2, 2007, 7:03:19 PM2/2/07
to
Serge Rielau wrote:

> Doc defect... don't loose your faith just yet.

Dang! Is it a defect in that the doc was updated too soon? ;-)

0 new messages