Re: Memory leak on AIX 5.3
Look no further than this statement.
First of all, a table with 134 fields??
None of this data could have been normalized ?
Or perhaps group the related data elements into smaller tables ?
That's your problem: a very poorly designed application.
( not to mention the poor naming convention with fields
like "serial_1", "serial_2", "filler1", "filler2" ??? )
Secondly, if you're updating every single field in a record,
which is how it looks, it would probably be much more effecient
just to delete the old record ( after moving it to a history table ),
and then inserting a new record. Updates are notoriously expensive,
especially cumbersome ones like this. It doesn't look like the
programmer
took the care to insure they weren't updating the primary key(s).
> >
> > Last parsed SQL statement :
> > UPDATE shclog SET> >
> > msgtype=?,pan=?,pcode=?,txntype=?,amount=?,aval_balance=?,amount_equiv=?,ca
> >
> > sh_back=?,iss_conv_rate=?,iss_currency_code=?,iss_conv_date=?,acq_conv_rate
> >
> > =?,acq_currency_code=?,acq_conv_date=?,tra_amount=?,tra_conv_rate=?,tra_cur
> >
> > rency_code=?,tra_conv_date=?,fee=?,new_fee=?,new_amount=?,new_setl_amount=?
> > ,settlement_fee=?,settlement_rate=?,settlement_code=?,settlement_amount=?,t
> > randate=?,trantime=?,trace=?,local_time=?,local_date=?,settlement_date=?,ca
> > p_date=?,pos_entry_code=?,pos_condition_code=?,pos_pin_cap_code=?,pos_cap_c
> > ode=?,life_cycle=?,acquirer=?,issuer=?,transferee=?,originator=?,processori
> > d=?,respcode=?,reason_code=?,revcode=?,shcerror=?,saf=?,origmsg=?,origtrace
> > =?,origdate=?,origtime=?,merchant=?,acq_country=?,track2=?,track3=?,refnum=
> > ?,authnum=?,termid=?,acceptorname=?,termloc=?,addresponse=?,acctnum=?,branc
> > h=?,serial_1=?,serial_2=?,acqagent=?,issagent=?,storeid=?,lane=?,terminal_t
> > race=?,checker_id=?,supervisor=?,shift_number=?,batch_id=?,extract_flags=?,
> > o_rowid=?,card_region=?,from_acct_region=?,from_acct_group=?,to_acct_region
> > =?,to_acct_group=?,to_acct_bin=?,to_acct_sub_inst=?,force_post=?,term_locat
> > ion=?,term_type=?,term_number=?,term_city=?,term_country=?,term_acq_bank=?,
> > term_language=?,suspect_code=?,merchant_name=?,misid=?,extra=?,user_txncode
> > =?,user_msgtobank=?,bill_count=?,x200_time=?,x210_time=?,response_time=?,de
> > vice_devcap=?,shc_devcap=?,formatter_devcap=?,auth_devcap=?,filler1=?,fille
> > r2=?,filler3=?,filler4=?,issuer_data=?,acquirer_data=?,new_amount_equiv=?,a
> > cq_aval_balance=?,acq_ledger_balance=?,setl_aval_balance=?,setl_ledger_bala
> > nc=?,aval_balance_type=?,ledger_balance_typ=?,new_setl_fee=?,txn_amount=?,t
> > xn_new_amount=?,txn_currency_code=?,txn_conv_rate=?,txn_conv_date=?,ch_amou
> > nt=?,ch_new_amount=?,ch_currency_code=?,ch_conv_rate=?,ch_conv_date=?,ledge
> > r_balance=?,slot_num=?,device_fee=?,shc_data_buffer=? WHERE CURRENT OF
> > CUR205dff88
> >
droberts@acus.com wrote: > Look no further than this statement. > > First of all, a table with 134 fields?? > > None of this data could have been normalized ? > Or perhaps group the related data elements into smaller tables ? > > That's your problem: a very poorly designed application. > ( not to mention the poor naming convention with fields > like "serial_1", "serial_2", "filler1", "filler2" ??? ) > > Secondly, if you're updating every single field in a record, > which is how it looks, it would probably be much more effecient > just to delete the old record ( after moving it to a history table ), > and then inserting a new record. Updates are notoriously expensive, > especially cumbersome ones like this. It doesn't look like the > programmer > took the care to insure they weren't updating the primary key(s). <SNIP> Spawn of a C++ programmer! Looks like someone instantiated a persistent object by making the constructor SELECT * and the destructor UPDATE <all columns>. I am definitely doing a session on this kind of stuff at IDUG/IIUG 2008! Art S. Kagel