Grouper Users - Open Discussion List

[Peter DiCamillo <>]

Thanks for the quick replies.  Analyzing the tables solved the problem.

Peter

Shilen Patel wrote:
> We use Oracle and find that analyzing all tables every night is 
> helpful.  And after a large data load (or during the middle of one) 
> analyzing tables can have a huge benefit.
>
> https://spaces.internet2.edu/pages/viewpage.action?pageId=11076532#APIBuilding%26Configuration-AnalyzingTablestoImproveQueryPerformance 
>
>
> Thanks!
>
> -- Shilen
>
>
> On 9/29/10 12:09 AM, Jim Fox wrote:
> > We use postgres, and have found that "analyze" is a necessary command 
> > to run every so often.  Does Oracle also require an occasional analyze?
> >
> > Jim
> >
> > On Sep 28, 2010, at 8:56 PM, Peter DiCamillo wrote:
> >
> >   
> > > I'm working on putting Grouper 1.6.1 into production as an upgrade from
> > > 1.3.  Things were going fine until I started to load a lot of data into
> > > the database, and now I'm seeing a performance problem.  With our full
> > > database in Grouper 1.3, we can add or delete a few people per second
> > > from a typical group.  With Grouper 1.6.1, the same operations on the
> > > same groups have a rate of about 3 seconds per person, which is about an
> > > order of magnitude slower.  With 1.6.1, performance has gotten worse as
> > > more groups are loaded, and I'm getting that performance with less than
> > > half the database loaded.  We're using an Oracle database, and LDAP as
> > > our person source.
> > >
> > > Since performance was fine when I first started to load the database, I
> > > suspect that the problem is related in some way to the database.  Any
> > > obvious things I should check in a new Grouper installation that might
> > > affect performance?  Any suggestions on how to start tracking down the
> > > source of the delays?  Thanks for your help.
> > >
> > > Peter
> > >      
> >