Re: primary keys and dictionary overhead
- From: Subodh Deshpande <deshpande.subodh@xxxxxxxxx>
- To: oracledbaquestions@xxxxxxxxx, niall.litchfield@xxxxxxxxx
- Date: Thu, 20 Oct 2011 15:42:47 +0530
first I will share my experience..
yes, DBA was just responsible for backup purpose..mostly used as support
team group member..as database operator..
lead programmer or senior programmer used to take care of overall
functioning of applications...
atleast in a month entire root backup(OS level as well as application level)
process was carried out..using standard scripts
We (our entire team) used to face slowness in functioning because oracle was
new to us at that time, hence architecture of oracle was not known
completely..slowness in application was because of limited use tablespaces,
system tablespace used to come into picture when usertablspace becomes
full..we were having lot of problems due to hardware and space.because both
were very costly at that time..the problems of slowness were not because of
coding..but because of hardware used and space constraints..
Time to time our management used to take the descision of migrating the
application from lower version to higher versions, cause oracle itself is
very keen on client shoud use the latest versions..
Upto oracle 7 it was client server technology..when oracle 8i, java, php,
asp, apache server were introduced webbased application era was started..
now we all know and use oracle 10g 11g , forms and reports 10g, 10gas,
weblogic server etc.
now I coming to you.
Quote
Never mind that their code was suspiciously absent of bind variables forcing
a hard parse for every run of a query where only the
string literal value was changed
UnQuote
if the forms is based on some base tables and if it inserts only one record
at a time then it is going to happen..these type of forms are generally used
to insert master data..
if the form is inserting multiple records using bases tables or even
procdures multiple records will be inserted..again same sql will be
fired..these type of forms used for inserting transaction data..
in all these forms when the you move from one field to another business
logic, database logic code must be present..
if you have docs for these it is very easy to do a reverse engineering..if
not then enter wrong data, error will be thrown (on Vt100 terminals press f7
key to check the error, base table used and query used, columns used..)
The only thing which is not changed is SQL..so you should be able to check,
spool or migrate the data at any time using sql also..
But remember one thing 20+ yes back application will not run on todays
present hardware, software..study is important..
And also business logic has hardly changed..there are buyers and hence
sellers..hence product exists.
Todays standard procedures such as intdent, inventory requisition, POs,
invoices, and account entries have not changed at all..
so knowing the logic its possible to change the application for today..but
the past 20+ yrs application can not be used as it is today..
thanks..subodh
On 20 October 2011 14:17, Niall Litchfield <niall.litchfield@xxxxxxxxx>wrote:
> Oracle 7 was also the first release with declarative referential integrity.
> So up until that point not only were string literals the standard way to
> program against databases, ensuring data integrity was a job for the
> database programmer in code rather than in database. Then you have the
> education cycle, the adoption cycle and the release cycle. It seems to me
> that any commercial product released before about 1995/1996 that used
> declarative referential integrity and bind variables would have been way
> ahead of its time - and almost certainly hit bugs with the new features.
>
> On Thu, Oct 20, 2011 at 2:59 AM, Chitale, Hemant Krishnarao <
> Hemant.Chitale@xxxxxx> wrote in response to David:
>
> > > Apparently a few vendors did that 20+ years ago and claimed it was for
> > performance reasons. Never mind that their code was suspiciously absent
> of
> > bind variables forcing a hard parse for every run of a query where only
> the
> > string literal value was changed.
> >
> >
> > Oracle V7 was released around 1991 or so. That was the first time a
> > "Shared Pool" was introduced. Awareness of Binds was still sometime in
> the
> > future.
> >
> >
> > Hemant K Chitale
> > -----Original Message-----
> > From: oracle-l-bounce@xxxxxxxxxxxxx [mailto:
> oracle-l-bounce@xxxxxxxxxxxxx]
> > On Behalf Of David Fitzjarrell
> > Sent: Thursday, October 20, 2011 4:53 AM
> > To: mark.powell2@xxxxxx; ORACLE-L
> > Subject: Re: primary keys and dictionary overhead
> >
> > Apparently a few vendors did that 20+ years ago and claimed it was for
> > performance reasons. Never mind that their code was suspiciously absent
> of
> > bind variables forcing a hard parse for every run of a query where only
> the
> > string literal value was changed. Never mind that their idea of
> referential
> > integrity was 'enforced' in the application code and not the database.
> > Never mind that they also enforced uniqueness in the same way. Which
> > explains why migrating from one of these types of applications to one
> which
> > uses database constraints requires far more data cleanup than should be
> > necessary.
> >
> > It's funny sometimes what vendors do in the name of 'performance'.
> > David Fitzjarrell
> >
> >
> >
> > This email and any attachments are confidential and may also be
> privileged.
> > If you are not the addressee, do not disclose, copy, circulate or in any
> > other way use or rely on the information contained in this email or any
> > attachments. If received in error, notify the sender immediately and
> delete
> > this email and any attachments from your system. Emails cannot be
> > guaranteed to be secure or error free as the message and any attachments
> > could be intercepted, corrupted, lost, delayed, incomplete or amended.
> > Standard Chartered PLC and its subsidiaries do not accept liability for
> > damage caused by this email or any attachments and may monitor email
> > traffic.
> >
> > Standard Chartered PLC is incorporated in England with limited liability
> > under company number 966425 and has its registered office at 1
> Aldermanbury
> > Square, London, EC2V 7SB.
> >
> > Standard Chartered Bank ("SCB") is incorporated in England with limited
> > liability by Royal Charter 1853, under reference ZC18. The Principal
> Office
> > of SCB is situated in England at 1 Aldermanbury Square, London EC2V 7SB.
> In
> > the United Kingdom, SCB is authorised and regulated by the Financial
> > Services Authority under FSA register number 114276.
> >
> > If you are receiving this email from SCB outside the UK, please click
> > http://www.standardchartered.com/global/email_disclaimer.html to refer
> to
> > the information on other jurisdictions.
> > --
> > //www.freelists.org/webpage/oracle-l
> >
> >
> >
>
>
> --
> Niall Litchfield
> Oracle DBA
> http://www.orawin.info
>
>
> --
> //www.freelists.org/webpage/oracle-l
>
>
>
--
=============================================
TRUTH WINS AT LAST, DO NOT FORGET TO SMILE TODAY
=============================================
--
//www.freelists.org/webpage/oracle-l
Other related posts:
