Re: Designer 2.1.1 Never finishes reverse engineering

Hi,

Here is the quotation from Des2k Installation guide.

I hope it will help you.

Good Luck.

"...
Repository Tuning

The DBA or the Repository owner can perform a number of actions that are designed to improve Repository performance:

     Setting the database initialization parameters 
     Analyzing the Repository tables 
     Truncating the temporary tables 
     Rebuilding fragmented indexes 
     Reorganizing permanent storage tables 
     Keeping the Repository tidy 

Setting the Database Initialization Parameters

The file INITxxx.ORA at the server contains parameters for configuring the Oracle database at startup.

Following are some example parameter settings. The settings show the minimum values, and assume that a single Repository instance has been installed for up to four concurrent users. If more concurrent users are required, or more than one Repository instance is installed, then these parameters will require more tuning. If you are running other systems on the same Oracle database which already require larger settings, then do not make these any smaller.

The setting for shared_pool_size affects the size of the System Global Area (SGA). Be especially careful with the setting for shared_pool_size, as the value is expressed as a number of bytes. Thus to set this to about 16 Mb, for example, you can enter a value of 16000000, taking care to enter the correct number of zeroes.

Example parameter settings for different types of database server machine are:

     PC with 32 Mb RAM

     shared_pool_size = 16000000
     db_block_buffers = 1000 
     global_names = false
     open_cursors = 400 
     processes = 100

     PC with 48 Mb RAM 

     shared_pool_size = 18000000
     db_block_buffers = 1000 
     global_names = false
     open_cursors = 400 
     processes = 100

     Sun Sparc with 64 Mb RAM 

     shared_pool_size = 28000000
     db_block_buffers = 5000 
     global_names = false
     open_cursors = 400 
     processes = 100
     log_buffer = 65536

     Sun Sparc with 128 Mb RAM 

     shared_pool_size = 28000000
     db_block_buffers = 25000 
     global_names = false
     open_cursors = 400 
     processes = 150 
     log_buffer = 65536

Carefully consider whether to use or modify the above example settings. It is the responsibility of the DBA to monitor the system and ensure that these parameters are appropriate for the current period of activity.

Retune the INITxxx.ORA parameters when adding users or switching activities. The Oracle Enterprise Manager monitors and tuning tools can help here.

We recommend that the OPTIMIZER_MODE parameter is set to its default value CHOOSE.

Following are some specific modifications you might want to make. On some systems, such as UNIX, these changes need to be made in harmony with tuning of the operating system I/O; refer to the specific server documentation for your system. Take care not to increase these parameter values to the point where the SGA will no longer fit in memory.

Set DB_BLOCK_BUFFERS to 1000 or higher

If enough memory is available, try a setting of up to 2000 (check its effectiveness using the DB_BLOCK_BUFFER cache hits monitor).

Keeping table data rows cached is effective for speeding up the loading of a large data file or for other operations requiring a lot of API validation. There should be an observable drop in the number of physical disk accesses.

This is the tuning parameter which can most influence the execute and fetch times of SQL statements. Note, however, that any increase in the setting of db_block_buffers causes an increase in SGA memory requirements equivalent to (extra * block_size) bytes, where extra is the increase in the db_block_buffers setting and block_size is the value of the db_block_size parameter in the INITxxx.ORA file.

Set SHARED_POOL_SIZE to 18Mb or higher

Doing so reduces reloading and reparsing caused by PL/SQL blocks and SQL being swapped out of cache.

For a multi-user Repository, where users are working with different element types, e.g. system modeling and system design, higher values are needed because more (or most) of the API will be required at the same time.

This is the tuning parameter which most effects parsing and loading times. It is most effective if the block or statement is already in memory and ready to run.

Set LOG_BUFFER to 64K

Higher values reduce I/O to the redo log file. Try increasing the value from the default (32K on UNIX) if your system performs a lot of long running transactions (e.g. Archive/Restore), or a large number of smaller ones.

In general, the transaction sizes for diagrammers and other tools tend to be small and infrequent. This parameter probably has little effect in these circumstances, but consider changing it if a large number of users are accessing the Repository, as in this case the frequency and transaction sizes could increase dramatically.

Set OPEN_CURSORS to at least 400

If the Repository is being used by more than four active users, this value may have to increase.
..."

I'm terribly sorry for size of quotation...  

dperez_at_juno_nospam.com wrote:
>
> In my most astonished and generically screaming voice - the one normally used
> when trying to get an Oracle product to actually work.......
>
> YOU MEAN I'M NOT THE ONLY ONE THAT'S EXPERIENCING THIS UNBELIEVABLY POOR
> PERFORMANCE FROM THIS PIECE OF FECES???????????
>
> Jeez, they've done it again....................................
>
> Unfortunately, I have NO ideas so far to get this POS to work even REMOTELY
> acceptably........ OK, DBA guys, any of you got any suggestions?????? Anybody
> else even using 2.1.1 for anything?

-- 
Valery A. Sorokin
ProSoft, Russia, Moscow, Information Systems Division
Phone: +7 (095) 234 0636 (6 lines) FAX: +7 (095) 234 0640
E-mail: vsorokin_at_dd.ru OR vsorokin_at_prosoft.ru
http://www.dd.ru