[Date Prev][Date Next][Thread Prev][Thread Next]
[Author Index]
[Date Index]
[Thread Index]
[SQR-USERS Info]
[SQRUG Home Page]
Re: [sqr-users] suggestions for bestpracticewith insertsinto temptable
- Subject: Re: [sqr-users] suggestions for bestpracticewith insertsinto temptable
- From: "David Thorburn" <thorburn@conl.net>
- Date: Thu, 30 Sep 2004 10:12:25 -0700
- Delivery-date: Fri, 01 Oct 2004 08:26:50 -0500
- List-id: "This list is for discussion about the SQR database reportinglanguage from Hyperion Solutions." <sqr-users.sqrug.org>
- References: <200409301636.i8UGa8N4017922@webmail1.magma.ca>
Why don't you choose to run this on the server instead of the local client
workstation?
Regards,
David
__________________________________________________
David Otis Thorburn (916) 712-2272
thorburn@conl.net www.geocities.com/david_thorburn
__________________________________________________
----- Original Message -----
From: "Kevin Laroche" <bydesign@magma.ca>
To: <sqr-users@sqrug.org>
Sent: Thursday, September 30, 2004 9:36 AM
Subject: RE: [sqr-users] suggestions for best practicewith insertsinto
temptable
> Thanks George
> The reports that we have rollback problems with run 15-20 minutes and do
10-12000 inserts.
> The elderly database is being upgraded but we dont want to have capacity
expand to fill
> the space available.
> I will try the /*+APPEND */ and batch commits within the SQR. A global
table sounded
> good until the DBA pointed out that 1 or 2 users running the large reports
at the same
> time could cause problems for the other 100 users who are not putting any
sort of load on
> the database.
> Are there functional limits on the size of an array that SQR can hold?
> Is an array of 10-15,000 records with 5 columns held in a client memory PC
going to make
> their PC as slow as molasses?
>
> Does anyone else work with large in memory arrays in SQR?
>
> Thanks
>
> Kevin LaRoche
> Oracle Forms Developer
>
> On Sep 30, "George Jansen" <GJANSEN@aflcio.org> wrote:
> >
> > Rollback problems depend on the rate of database change and on the
> > (time) length of the query. Either you generated so much rollback that
> > you filled the segment, or your query lasted umpteen hours and Oracle no
> > longer has the rollback blocks to reconstruct what the tables looked
> > when your query started. If you are filling up the segment, then either
> > you need larger segments or you need to use a strategy, e.g. INSERT /*+
> > APPEND */ that generates less undo. If your query is running too long,
> > then maybe you need to rethink how it runs.
> >
> > In general you'll get better performance with Oracle doing
> > set-at-a-time processing:
> >
> > Begin-SQL
> > INSERT INTO blah
> > (x, y, z)
> > SELECT a + b, c*d, e
> > FROM w
> > End-SQL
> >
> > If you must do row-at-a time processing, then perhaps you could use a
> > GLOBAL TEMPORARY TABLE to hold the rows, then do a big INSERT /*+ APPEND
> > */ at the end.
> >
> > Need I mention that you can't use the GLOBAL TEMPORARY TABLE for the
> > next report? Even if created with ON COMMIT PRESERVE ROWS, the contents
> > disappear with your session.
> >
> >
>
> _______________________________________________
> sqr-users mailing list
> sqr-users@sqrug.org
> http://www.sqrug.org/mailman/listinfo/sqr-users
>
>
_______________________________________________
sqr-users mailing list
sqr-users@sqrug.org
http://www.sqrug.org/mailman/listinfo/sqr-users