Re: [?] Designer Repository Performance

Have you thoroughly tuned the Repository and Designer environment? In my experience,
this is the one place that a lot of shops just sort of 'forget' about....the Repository is a database
like any other and there are a variety of things which you can do to optimize its performance.

First - how many elements are in your Repository - and what was the initial size of the Repository
set at? If it was set too small - conflicts and slowing will occur. Remember - this isn't just what's in
one application - it's in the entire Repository. Small repositories can handle up to 20,000 elements -
Medium between 20,000 and 100,000 and Large is for more than 100,000. Small repositories don't
seem to do welll with over 50 tables and two designers working in them at a time.

And then....<g>...

Have you checked the RAU for invalid and/or missing objects?

Have you checked your temporary table sizes and truncated them if they're getting
too large?

Have you dropped and rebuilt your indexes lately?

Have you truncated the RMS$HASH_ELMS tables? (Do it now, if not before!!! <g>)

How many and how large are your roll-back segments - Designer works on immediate
commit - and this can definitely impact your performance. The most common number I have
heard is

Tune INITxxx.ora....

Set your DB_BLOCK_BUFFERS to 1000 or higher

Set your SHARED_POOL_SIZE to 18 MB or higher...(I've seen some big performance gains by
just doing this...)

Pin all Packages!!! This can be done from the RAU.

Set your LOG_BUFFER to 64K....higher values reduce I/O to the redo log file. This will have the most effect if you are working in something other than the diagrammers - and if
you have only a few developers hitting it at a time.

Set OPEN_CURSORS to at least 400 - if you have more than four users - this may have to go up..

Use the Export facility followed by the Import utility to reorganize permanent storage tables when
they become fragmented.

Tune the PCTFREE and PCTUSED parameters depending on the requirements for UPDATES and
DELETES... Run the Repository analyzer regularly...!!!

If you've had a lot of 'Forced Deletes' look for invalid references - these tend to leave 'pieces' behind which can affect overall performance over time.

Display the Repository object sizes, click the View Objects and choose Object Sizes - if any any objects
in SDD_ELEMENTS in particular have a large number of extends (>10 in Ext(s) field)...Let me know if you
need a full description (my fingers are getting tired <g>...)

In our shop we had COBOL programmers dumping their - er, highly unrelational - tables into Designer - kind of using it like Coreldraw...this did not make the Designer happy (or me either for that matter!!!)

ALSO - make certain that your client machines are using their virtual memory appropriately. If things are hanging a
lot and you have several applications open - try setting the Performance 'down' from giving full throttle to the primary window...sometimes this can help with overall performance when you can't get past the 'hung' window.

Are your client machines using their SecondaryCache if they have the memory...most machines don't come with
the SecondaryCache configured even though they're shipping with a lot more memory today.

OK...I'm sure you're sick of this by now....<g>...but my point is really just this - and you're certainly not alone in this - most people think of Designer as a tool they can install like Word and sort of just let it run...It really needs as much, if not more, attention from your DBA and your Repository owner as your database. We really can't blame the tool's performance until we've done our job in optimizing and tuning it!!!

[Quoted] Hope this helps a bit...let me know if you need further details...

Chana Campos

Bradley G. Smith <bgsmith/r6pnw_deschutes_at_fs.fed.xxus> wrote in message news:otfzvguecajqrfpuhgrfsfsrqhf.fcnizc0.pminews_at_news.newsguy.com...
> We have Oracle for Workgroups (7.3 or close) installed on a dual Pentium
II
> 200 SMP server. Oracle is used only to house a Designer/2000 (1.x)
> repository. It appears that with 10 or so users, CPU activity is averaging
> close to 60-70% each for both CPUs. Does this correspond to other user's
> experience? This effectively means we cannot run other applications on the
> server.
>
> Thanks,
>
> Brad
>
>
>
Received on Wed Jun 02 1999 - 20:28:59 CEST