|
IDS Forum
Re: Help Please: delete rows in a table and co....
Posted By: Kern Doe Date: Sunday, 15 June 2008, at 5:37 p.m.
In Response To: Re: Help Please: delete rows in a table and co.... (Art Kagel)
Thanks Art.
No, the data is just standard, just character field columns; I'm talking about those joining fields.
In addition, I need to mention that the table to purge is fragmented; therefore, there will be no rowid, is it a problem to your dbdelete?
Yesterday, I randomly selected out about 10 rows from tableB (look up table) and hardcoded in a simple query via dbaccess to test the delete. Only half of these were matching in tableA and it took about 3 seconds to finish. Through my SP with similar structure to Dharmendra's suggestion, it averages out 5,6 rows/sec. So, I'm confused, perhaps no matter how we try, 20 or more rows deleted per second may not be achievable for this table?
Regards
----- Original Message ----
From: Art Kagel <art.kagel@gmail.com>
To: ids@iiug.org
Sent: Saturday, June 14, 2008 9:54:29 PM
Subject: Re: Help Please: delete rows in a table and co.... [12431]
Oh, forgot, I uploaded an updated edition of the utils2_ak package on
Friday. Though it only has updates to dostats and myschema, the dbdelete
you already have is up-to-date.
Art
On Sat, Jun 14, 2008 at 9:53 PM, Art Kagel <art.kagel@gmail.com> wrote:
> Kern,
>
> Unless you are using non-standard datatypes that dbdelete might not
> recognize (and that would only matter if those types were used in the filter
> to select rows), dbdelete will work out of the box. Just compiling
> dbdelete.ec is trivial: esql -o dbdelete dbdelete.ec, but on Solaris the
> package 'make's out of the box as long as you have GNU Make (you have to
> make a minor change to the main make file (Makefile) and the makefile for
> myschema in the myschema.d subdirectory - myschema.mk.norcs - (changes
> documented in the BUILD file). To build the entire package if you have GNU
> make just unpack the shell archive by executing it and type 'make'.
>
> Art
>
>
> On Fri, Jun 13, 2008 at 1:39 PM, Kern Doe <kern_doe@yahoo.com> wrote:
>
>> Hi Art,
>> The problem is not about $$$ -- it is a change to the system that I don't
>> want
>> to do yet (even it is a dev box) unless I exhaust all my options then I
>> will
>> push for it convincing that the dbdelete is the way to go no need to
>> reinvent
>> the wheel. Upon getting the suggestion from Obnoxio a couple of days ago,
>> I
>> actually down loaded both: your utilities and the free SDK (for Solaris 7)
>> but
>> have not done anything yet
>> Perhaps you are the creator then may I ask you directly, how difficult is
>> it
>> to compile the dbdelete? (I don't need other stuff)
>> ok, first I need to install ESQL (root id must involve)
>> 2nd, I need to compile the dbdelete.ec I guess?
>> seems like some modifications will be neede to the dbdelete before
>> compiling?
>> Thanks.
>> kern --
>>
>> ----- Original Message ----
>> From: Art Kagel <art.kagel@gmail.com>
>> To: ids@iiug.org
>> Sent: Friday, June 13, 2008 1:27:32 PM
>> Subject: Re: Help Please: delete rows in a table and co.... [12423]
>>
>> Then you will have to code it in a host language where you can limit the
>> number of rows you process at a time by managing the cursor. That means
>> ESQL/C, 4GL, or Perl IB. Dbdelete uses the ESQL/C Fetch Array feature to
>> fetch the entire 8192 maximum number of rowids that it can in a single
>> FETCH. One big reason that it is as fast as it is.
>>
>> I take it you are having trouble getting utils2_ak approved for production
>> use. Let me know if I can help that. Perhaps they would prefer a formal
>> commercial license with warantees and -limited- liability? Don't know why
>> anyone would want to pay for something they can get for free, but if
>> that's
>> what they want, let me know. I've done it before.
>>
>> Art
>>
>> On Fri, Jun 13, 2008 at 1:19 PM, Kern Doe <kern_doe@yahoo.com> wrote:
>>
>> > Art,
>> > I can't do "select first" because this is version 7.31 -- that's the
>> > problem.
>> > Kern --
>> >
>> > ----- Original Message ----
>> > From: Art Kagel <art.kagel@gmail.com>
>> > To: ids@iiug.org
>> > Sent: Friday, June 13, 2008 1:02:17 PM
>> > Subject: Re: Help Please: delete rows in a table and co.... [12421]
>> >
>> > What my dbdelete utility does is the equivalent of:
>> >
>> > LOOP:
>> >
>> > BEGIN WORK;
>> > SELECT FIRST 8192 ROWID as id
>> > FROM target_table
>> > WHERE id_col IN (SELECT id FROM lookup_table)
>> > INTO TEMP fred;
>> >
>> > DELETE FROM target_table
>> > WHERE ROWID IN (SELECT id FROM fred);
>> >
>> > COMMIT WORK;
>> >
>> > GOTO LOOP;
>> > .......
>> >
>> > Except that it doesn't use a temp table, it builds the IN clause on the
>> fly
>> > using the selected ROWIDs.
>> >
>> > Art
>> >
>> > On Fri, Jun 13, 2008 at 12:55 PM, Art Kagel <art.kagel@gmail.com>
>> wrote:
>> >
>> > > ROWIDs are NOT sequential integers starting from 1! They are normally
>> the
>> > > relative page number on which the row resides shifted left 8 bits plus
>> > the
>> > > slot number on the page containing the pointer to the row's data.
>> > >
>> > > So the first row on the first page of a table is ROWID 0x00000101 or
>> 257
>> > > and the first row on the second page of the table is ROWID 0x00000201
>> or
>> > > 513.
>> > >
>> > > You cannot use ROWID like your have consistently, and certainly it
>> will
>> > not
>> > > delete 1000 rows at a time since only 1-255 rows can fit on a page. If
>> > only
>> > > two rows fit on a page, your example would delete only six rows at a
>> > time.
>> > >
>> > > Art
>> > >
>> > >
>> > > On Fri, Jun 13, 2008 at 12:47 PM, Sudhir G Katke <sgkatke@us.ibm.com>
>> > > wrote:
>> > >
>> > >> Hello Kern,
>> > >> You can use the following SQL:
>> > >>
>> > >> delete from tab1
>> > >> where col_in_tab1 in (select col_in_tab2 from tab2 where tab2.rowid
>> bet=
>> > >> ween
>> > >> 1 and 1000);
>> > >>
>> > >> Increment the values in between clause by 1000.
>> > >>
>> > >> =
>> > >>
>> > >> Sudhir G Katke =
>> > >>
>> > >> SWG Client Support - Information Management =
>> > >>
>> > >> Software =
>> > >>
>> > >> Premium Support Analyst =
>> > >>
>> > >> Phone: 479 426 4308 Internal: 624 7341 =
>> > >>
>> > >> sgkatke@us.ibm.com =
>> > >>
>> > >> =
>> > >>
>> > >> |------------>
>> > >> | From: |
>> > >> |------------>
>> > >>
>> >--------------------------------------------------------------------=
>> > >>
>> -----------------------------------------------------------------------=
>> > >> -------|
>> > >> |"Kern Doe" <kern_doe@yahoo.com> =
>> > >>
>> > >> =
>> > >>
>> > >> |
>> > >>
>> >--------------------------------------------------------------------=
>> > >>
>> -----------------------------------------------------------------------=
>> > >> -------|
>> > >> |------------>
>> > >> | To: |
>> > >> |------------>
>> > >>
>> >--------------------------------------------------------------------=
>> > >>
>> -----------------------------------------------------------------------=
>> > >> -------|
>> > >> |ids@iiug.org =
>> > >>
>> > >> =
>> > >>
>> > >> |
>> > >>
>> >--------------------------------------------------------------------=
>> > >>
>> -----------------------------------------------------------------------=
>> > >> -------|
>> > >> |------------>
>> > >> | Date: |
>> > >> |------------>
>> > >>
>> >--------------------------------------------------------------------=
>> > >>
>> -----------------------------------------------------------------------=
>> > >> -------|
>> > >> |06/13/2008 10:55 AM =
>> > >>
>> > >> =
>> > >>
>> > >> |
>> > >>
>> >--------------------------------------------------------------------=
>> > >>
>> -----------------------------------------------------------------------=
>> > >> -------|
>> > >> |------------>
>> > >> | Subject: |
>> > >> |------------>
>> > >>
>> >--------------------------------------------------------------------=
>> > >>
>> -----------------------------------------------------------------------=
>> > >> -------|
>> > >> |Help Please: delete rows in a table and commit.... [12416] =
>> > >>
>> > >> =
>> > >>
>> > >> |
>> > >>
>> >--------------------------------------------------------------------=
>> > >>
>> -----------------------------------------------------------------------=
>> > >> -------|
>> > >>
>> > >> Hi gurus,
>> > >> How hard is it to turn this simple delete query into something where
>> it=
>> > >>
>> > >> will
>> > >> commit the deletion every 1000 rows or so? I've tried with a stored
>> > >> procedure
>> > >> but it's slow -- I'm not all a hardcore coder, perhaps, I don't have
>> th=
>> > >> e
>> > >> right
>> > >> codes.
>> > >> delete from tab1
>> > >>
>> > >> where col_in_tab1 in (select col_in_tab2 from from tab2);
>> > >> Thanks
>> > >> (no, Art's utility is not an option for me at this time)
>> > >>
>> > >>
>> ***********************************************************************=
>> > >> ********
>> > >>
>> > >> Forum Note: Use "Reply" to post a response in the discussion forum.
>> > >>
>> > >> =
>> > >>
>> > >>
>> > >>
>> > >>
>> >
>> >
>> >
>>
>>
>>
*******************************************************************************
>> > >> Forum Note: Use "Reply" to post a response in the discussion forum.
>> > >>
>> > >>
>> > >
>> > >
>> > > --
>> > > Art S. Kagel
>> > > Oninit (www.oninit.com)
>> > > IIUG Board of Directors (art@iiug.org)
>> > >
>> > > Disclaimer: Please keep in mind that my own opinions are my own
>> opinions
>> > > and do not reflect on my employer, Oninit, the IIUG, nor any other
>> > > organization with which I am associated either explicitly or
>> implicitly.
>> > > Neither do those opinions reflect those of other individuals
>> affiliated
>> > with
>> > > any entity with which I am affiliated nor those of the entities
>> > themselves.
>> > >
>> >
>> > --
>> > Art S. Kagel
>> > Oninit (www.oninit.com)
>> > IIUG Board of Directors (art@iiug.org)
>> >
>> > Disclaimer: Please keep in mind that my own opinions are my own opinions
>> > and
>> > do not reflect on my employer, Oninit, the IIUG, nor any other
>> organization
>> > with which I am associated either explicitly or implicitly. Neither do
>> > those
>> > opinions reflect those of other individuals affiliated with any entity
>> with
>> > which I am affiliated nor those of the entities themselves.
>> >
>> >
>> >
>> >
>>
>>
>>
*******************************************************************************
>> > Forum Note: Use "Reply" to post a response in the discussion forum.
>> >
>> >
>> >
>> >
>>
>>
>>
*******************************************************************************
>> > Forum Note: Use "Reply" to post a response in the discussion forum.
>> >
>> >
>>
>> --
>> Art S. Kagel
>> Oninit (www.oninit.com)
>> IIUG Board of Directors (art@iiug.org)
>>
>> Disclaimer: Please keep in mind that my own opinions are my own opinions
>> and
>> do not reflect on my employer, Oninit, the IIUG, nor any other
>> organization
>> with which I am associated either explicitly or implicitly. Neither do
>> those
>> opinions reflect those of other individuals affiliated with any entity
>> with
>> which I am affiliated nor those of the entities themselves.
>>
>>
>>
>>
*******************************************************************************
>> Forum Note: Use "Reply" to post a response in the discussion forum.
>>
>>
>>
>>
*******************************************************************************
>> Forum Note: Use "Reply" to post a response in the discussion forum.
>>
>>
>
>
> --
> Art S. Kagel
> Oninit (www.oninit.com)
> IIUG Board of Directors (art@iiug.org)
>
> Disclaimer: Please keep in mind that my own opinions are my own opinions
> and do not reflect on my employer, Oninit, the IIUG, nor any other
> organization with which I am associated either explicitly or implicitly.
> Neither do those opinions reflect those of other individuals affiliated with
> any entity with which I am affiliated nor those of the entities themselves.
>
--
Art S. Kagel
Oninit (www.oninit.com)
IIUG Board of Directors (art@iiug.org)
Disclaimer: Please keep in mind that my own opinions are my own opinions and
do not reflect on my employer, Oninit, the IIUG, nor any other organization
with which I am associated either explicitly or implicitly. Neither do those
opinions reflect those of other individuals affiliated with any entity with
which I am affiliated nor those of the entities themselves.
*******************************************************************************
Forum Note: Use "Reply" to post a response in the discussion forum.
Messages In This Thread
IDS Forum is maintained by Administrator with WebBBS 5.12.
|
|