This paper describes how the Oracle software Designer 2000/6i can be made to perform well.

1. Mahesh Vallampati 1
DESIGNER 2000-TIPS AND TECHNIQUES FOR A WELL TUNED
ENVIRONMENT
Mahesh Vallampati
Staff Consultant
Oracle Corporation
Houston, TX,USA.
Summary:
The Designer 2000 development environment is a client-server
environment with the data stored in a repository backend database and Windows
front end with SQL*Net as the glue. This presentation will address repository
tuning (database tuning), client-side tuning and SQL*Net tuning. This will also
provide some repository administration tips which will streamline the repository.
This presentation has 15 tuning tips which will provide for a well tuned Designer
2000 environment which in turn will improve productivity.

2. Mahesh Vallampati 2
Designer 2000 - Tips and Techniques for a well tuned environment
Introduction:
The Designer 2000 toolset from Oracle Corporation is a rapid application
modeling and development tool. This tool is based on the client-server paradigm.
The front-end which is typically a MS-Windows client accesses data in a repository
stored in an Oracle database server. This client-server environment needs to be
managed and administered. This article provides some tips and techniques which
when implemented provides a framework for running a well tuned Designer 2000
environment.
Designer 2000 Toolset Components:
The Designer 2000 toolset consists of the following components:
• Client Tools - The client tools are MS-Windows GUI development
tools and modellers.
• Repository - The Repository is an Oracle Database server, multi-
user environment with an open API.
• Network Bind - The client and the server communicate over a
network over SQL*Net.
Hence, tuning the Designer 2000 toolset reduces to tuning the above three
components.
Repository Administration Tips
Tip1: Recreate Indexes and Hash tables frequently:
It is important to understand the Designer 2000 Repository. The
repository consists of a set of tables, views, indexes, procedures, packages and
triggers. There are hash tables which were added in Release 1.2 to improve access
performance. In a Designer 2000 environment, one begins with an empty
repository and start filling the repository with application data. The indexes and
hash tables which were created at the beginning with an empty repository might
not be efficient as the repository is filled with data. Periodic recreation of the
indexes and hash tables should improve performance.
The Designer 2000 Repository Administration Utility provides a method for doing
it. Figure 1 illustrates the method to implement it. Note that no clients should be
logged in the repository when doing this task. Note that the recreating the hash
tables is basically a process of truncating the RM$HASHES table and re-
populating it with the data in the SDD_ELEMENTS and
SDD_STRUCTURE_ELEMENTS which are owned by the repository owner and
are the two main driving tables for the repository. This process requires full

3. Mahesh Vallampati 3
updates on both the tables and hence will use up a lot of rollback segment space
and time.
Figure1: Periodic Recreation of Indexes and Hash Tables Improve
Performance
Tip2: Pin Procedures to the SGA
The Designer 2000 application is procedure/package driven. That is, a lot
of application logic is stored in the stored procedures and packages. Pinning the
packages in the SGA will improve performance as these packages need not be
loaded from the system tablespace into the SGA. Pinning can be accomplished by
pressing the PIN button in the RAU which is shown in Fig.1. Note however this
procedure is manual and pinning is lost if the database is shutdown and started up.
The following SQL script when run as the repository owner will pin the
procedures to the SGA. This script when run after the database is started will
accomplish the objective of pinning the procedures to the SGA. The Database
Administrator can have the scripts as a part of his repository database startup
procedure. Note that pinning the procedures to the SGA means that the shared
pool size should be at least 18Megabytes in size. This only loads the minimum
required portion of the SGA. This script needs to be run when the command
‘ALTER SYSTEM FLUSH SHARED_POOL’ is executed. It is our
recommendation that the shared pool size be set to at least 30Mb for good

4. Mahesh Vallampati 4
performance. This prevents swapping of the API packages improving
performance.
connect syscase/syscase
declare
begin
for obj in (select nvl(ci_owner,user)||'.'||ci_name name from ck_installed_objects where
ci_pin_flag='Y' )
loop
sys.dbms_shared_pool.keep(obj.name);
end loop;
end;
/
Fig2: Pinning Procedures to the SGA improves performance.
Tip 3. Rollback Segments and Sizing
The Designer 2000 application follows a commit immediate model. That is
when the user insert, update, deletes data, it is immediately committed to the
database. This implies that the transactions are short and frequent hence
resembling a low volume OLTP environment. It is a good practice to have one
rollback segment for every 4 concurrent users. Even though Designer 2000
follows a commit immediate model, the Designer 2000 utilities are complex
programs requiring large rollback segment space. It is recommended to have at
least two large rollback segments for these utilities. Some utilities allow
specification of rollback segments for the execution and using these large rollback
segments is bound to give good performance. It is recommended that the rollback
segments for the Designer 2000 be sized at 50 Kilobytes for each extent, and
optimal to be set at 1Mb for the rollback segments used by concurrent users.
Rollback segments need to be monitored frequently at sites and settings for
rollback should be made from these observations. It is further suggested that
optimal parameter not be specified for the rollback segments used by Designer
2000 utilities, since the size of the transaction initiated by these utilities is not
known causing the “snapshot too old” error. The minextents should be set in the
range of 20-40 and max extents can be set to a high value.
Tip 4: MTS server setup for Designer 2000
The Designer 2000 toolset being client-server and SQL*Net a necessity
brings in a possibility to set up Multi-Threaded server if SQL*Net 2.0 is used. This
possibility is further enhanced by the short-transactional nature of the Designer
2000 application The MTS setup and parameters are beyond the scope of the
discussion. It should be noted that MTS setup will involve increasing the shared

5. Mahesh Vallampati 5
pool size by 1k for each concurrent user. This is in addition to the
Shared_Pool_size for the Repository API. The SQL*Net configuration files
should be set up to exploit the MTS. That is to say that the connect string
specified by the Designer 2000 user should use a shared_server_process. However,
When running the utilities one should use the dedicated server process and a
service name should be set up for this type of connection.
Tip 5: Redolog Sizing
The online redo log files are a set of two or more files that record all
committed changes made to the database. It is used to recover the database from
system or media failure. It is a good practice to have four on-line redo log files
each sized at approximately 5Mb. It is standard practice to run development
databases in archived log mode to enable point-in-time recovery and be able to
take on-line backups. Needless to say, a good backup recovery strategy is crucial
in any serious development environment and the sizing of the redo’s has to be
made based on this. Large redo-logs give good performance because of fewer log
switches while they cause recovery to be slower because of the larger size of the
redo-logs because the bigger the redo-log the more number of changes need to be
made to the database to make it current. Redo-log files of 5Mb seem to be an
optimal choice. It is a good idea to mirror the redo-log files and have multiple
copies of control-files to ensure redundancy and reliability.
Tip 6. Sizing of SGA
Shared_Pool_Size: We have already mentioned that a SHARED_POOL_SIZE
of at least 18Mb is needed for loading the minimum required portion of the API.
We have observed that a shared_pool_size of 30Mb is optimal for the Designer
2000 environment. Note that higher the value of shared_pool_size the better the
performance because of fewer SQL statements being swapped out of the
shared_pool.
DB_Block_Buffers: The Designer 2000 Installation requires that
db_block_buffers need to be set at least 1000. We have observed that setting this
parameter in the range of 1500-2000 improves performance significantly. It
should be noted that the Installation parameters mentioned in the guide are the
minimum required to install the product. The size of the SGA due to the
db_block_buffers is also a function of the database block size. The choice of
database block size is Operating system specific and should be chosen from the
suggested values in the Oracle Installation guide for that platform.
Redo_Log_Buffers: The size of the redo-log buffer should be set to a value
which causes minimum waiting time for user processes to get space in the redo-log
buffer. Oversizing the redo-log-buffer will increase performance but at the cost of
real memory which could be deployed elsewhere for valuable purposes like
shared_pool_size. We have observed that a value of 64K is optimal for our

6. Mahesh Vallampati 6
database. The DBA should tune this value by observing V$SYSSTAT tables and
obtain an optimal value for his/her site.
Tip 7. Placement of Datafiles on various disks for I/O tuning
By far one of the common methods for improving I/O throughput is to
spread the database’s datafiles across several disks. We recommend a variation of
a multiple disk solution mentioned in [2].
Disk
1. Oracle Software
2. System Tablespace
3. Rollback Segments Tablespace.
4. Temporary Tablespaces.
5. Repository Tables Tablespace.
6. Repository Index Tablespace.
7. User Tablespace,Tools tablespace.
8. On-line redo-logs tablespace
9. Archived redo-log destination disks.
10. Export Dump file destination disks and User Workspace.
The system tablespace should be at least 100Mb and the Repository Tables
tablespace should be at least 200Mb and the indexes at least 100Mb. It should be
observed that a lot of information is inserted into the repository and hence the
above requirements. One would wonder on the need for the system tablespace to
be at 100Mb. This is because the repository API is stored in the System
tablespace and Designer 2000 being a rapid development tools encourages the user
to experiment with database objects and hence in the process create a lot of
database objects requiring space in the system tablespace. The temporary
tablespace should be sized at 50Mb and the sort_area_size should be set to 64K
because the Designer 2000 does a lot of sorts to present data to the user. This
value is specific to our site and can be tuned to the specific site by observing
sysstat tables.
Tip 8: Do not Analyze Repository tables.
The SQL Statements of the Designer 2000 application have been written
and tested using the rule-based approach to optimization. Analyzing the tables
could have a serious impact on performance, which uses the cost based approach.
Tip 9: Database requirements
In order to use Designer 2000, the repository should be stored in an Oracle
database 7.1.3 or higher. The procedural option should be turned on and all
DBMS packages should be valid in order to begin installation. In order to exploit
the Designer 2000 reverse engineering utilities, the Oracle server should be
installed with the Distributed option linked. The open cursor parameter should be
set to at least 200 in the database initialization file. The repository owner should
be granted execute privileges on the DBMS packages DBMS_SHARED_POOL,

7. Mahesh Vallampati 7
DBMS_LOCK, STANDARD, DBMS_PIPE and DBMS_SQL prior to
installation. Each Repository requires at least 70Mb of System tablespace for
storing the API’s and at least 18Mb of shared_pool_size in the SGA.
Tip 10: Recreating The Repository through Import/Export:
The two main tables in a repository are SDD_Elements and
SDD_Structure_Elements. These two tables are designed for average size
installations upto 200,000 rows. These two tables can be fragmented due to the
frequent insert, update and deletion of rows from these tables. Sometimes there
might not be enough extents for the table to extend. When this happens, the
following steps should be done.
1. Export the Repository owner.
2. Drop the Repository owner including contents.
3. Import the Repository owner back.
Note that Exporting and Importing data back reduces row chaining to its
lowest theoretical limit [1]. Exporting and Importing tables with the compress
extent option on will import the table data in a single contiguous extent provided
such an extent can be created. This will speed up access of the tables dramatically
improving performance. Note that during this process, the repository API
packages become invalid and the Recompile objects option in the recreate menu
should be run to recompile the invalid API’s to become valid. Also the Hash
tables and Indexes will need to be recreated again. Before doing this procedure, it
is recommended to take a backup of the repository. This process also takes a long
time and hence repository down time risk should be taken into consideration.
Tip 11: Multiple Application systems and Repositories
A Designer 2000 Repository can consists of many applications. It is
possible to share objects between applications in the same repository. However it
is not possible to share objects across repositories. It is possible to move objects
across repositories using Designer 2000 utilities.
It is a good practice to have two repositories, one for doing proof of
concepts and other for actual development. It should be noted that the Designer
2000 toolset is based on the Rapid Application Development paradigm(RAD) and
hence gives the developer to explore the capabilities of the tool. The developer
can do RAD in the test repository and move his objects to the development
repository after testing and meeting functional requirements. Doing RAD in the
development repository has the risk that in the process of experimentation, the
developer might change some objects to test and may not be able to reset it back.
Moreover, in the development of templates the developer needs to be granted
administration privilege on applications in development which is not a good idea.
The test repository can be a useful site where the developer is free to experiment
and come out with interesting results, validate them against the requirements in the

8. Mahesh Vallampati 8
development repository and initiate change control procedures in the project to
make the changes official.
Tip 12: Impact of Sharing Objects in a Repository
The Designer 2000 paradigm of sharing objects among applications can be
an administrative problem when done indiscriminately. This impacts versioning of
application systems and backing up of the same. Consider the following scenario.
There are three applications: Applications A, B and C. A is the main application
and objects from B and C are shared into it. That is A contains objects from B and
C which are shared. When application A is versioned, the following happens:
1. A new version of the Application is created. It is version 2.
2. A copy of application B and C is made and they will be called 01B and 01C
and they will be frozen along with version1 of application A. Hence creating one
version of the applications creates multiple copies of the shared applications
Client-Side Tuning:
Tip 13: PC Client Requirements and Suggested settings
The optimal requirements for running a Designer 2000 clients on a
PC are
• 486 -25 DX2 Processor or better
• 32Mb of Random Access Memory
• A minimum of 500Kb of conventional memory before starting windows
• MS-Windows 3.1 or Windows 95 running Dos 5.0 or higher.
• SQL*Net supported Networking Software
a. Config.sys Settings:
It is suggested that the parameters
FILES=40
BUFFERS=40,0
STACK=9,256
be set in the config.sys file. This is specific to Windows 3.1.
b. PATH settings
Designer 2000 executables are executed using two types of windows files,
exe’s and DLL’s which are dynamic link libraries. Using the Designer 2000
executables involve using a lot of DLL access in ORACLE_HOME/bin and it is
recommended to have it in the PATH variable first. For example, it is a good idea
to set PATH as follows
PATH J:ORAWINBIN; C:NETWORK;C:WINDOWS;C:DOS. Note that
J:orawin which is the Client’s ORACLE_HOME is actually on a network drive.
c. Loading share.exe

9. Mahesh Vallampati 9
The latest versions of DOS provide an executable called share.exe in the
DOS directory. Loading this executable during booting of the PC’s gives file
sharing and locking capabilities to local and network drives. This is very much
needed when multiple users are loading executables from a file server. This is
specific to Windows 3.1.
d. Pre-Load Designer/Developer 2000 DLL’s
One way of tuning the clients is to pre-load Designer/Developer 2000
DLL’s by executing the programs ORACLE_HOME/bin/CDEINIT.exe and
R25SRV.exe. This can be accomplished by putting these programs in the
windows startup group. This could be particularly useful if Designer 2000 is
stored on a network drive.
e. Swap File size
The MS-Windows operating system implement virtual memory by the use
of swap files. The size of the permanent swap file should be set at 40Mb.
f. Working Directory settings
If Designer 2000 is installed on a file server, it is a good idea for the
Designer 2000 working directory to be on the client’s local disk drive. If it is set
to a network directory , there will be lot of contention for the drive causing
bottlenecks.
Tip14: Install Designer 2000 client tools on a File Server
The Designer 2000 client tools take up upto 300 Mb of disk space. It is
not feasible to install Designer 2000 clients on every PC.
Keeping track of these clients on Multiple PC’s can be an administrative
nightmare. It is recommended that the Designer 2000 be installed on a file server
like Novell or NT and the PC clients load the tools from the file server and execute
it. Figure 3 shows an architecture to accomplish this. Note that loading of the
executables from the file server can decrease performance. The Designer 2000
Installation document has guidelines on installing Designer 2000 on a file server.
It is recommended that the guidelines be followed closely for good performance.
In the architecture shown below, the PC Clients load the Designer 2000
software from the file server and use SQL*Net to connect to the database server .
In a large development environment, this is what should be done. In addition,
tools like Developer 2000 should be installed on the network thus facilitating
administration of these tools. Backing up of these tools should be done before and
after upgrades of various components. This is by far the most common
configuration adopted in serious development environments.

10. Mahesh Vallampati 10
Des2000 Client
Database Server
Ethernet
Des2000 Clients
Des2000 Clients
Designer 2000/Developer 2000 Tools Server
Figure 3: Install Designer 2000 Software on a File Server
Network Tuning:
Tip15 : SQL*Net Configuration
A. Pre-Spawned Server Processes
By far, one of the most common complaints against client-server
tools like Designer 2000 is the amount of time taken to connect to the server. This
is because of the overhead involved in authentication, verification and resource

11. Mahesh Vallampati 11
involved in spawning a process on the server. SQL*Net 2.x provides a feature
which enables the Network administrator to pre-spawn processes which will
reduce the time taken to accept client-connections thereby speeding up the time
taken to connect to a server. A good rule of thumb is to pre-spawn x+3 number of
processes for x users, the other 3 processes being for running the utilities. The
parameters PRE_SPAWN_MAX, PRE_SPAWN_LIST, PRE_SPAWN_DESC
need to be configured in the listener.ora file on the server to set up pre-spawned
processes.
B. Dead Connection Detection
One other common problem in client-server tools is the client-side
tool crashing, but the server process still running consuming resources and holding
locks degrading performance. SQL*NET provides detection of dead processes and
handling them cleanly and usage of this feature is recommended. The parameter
that provides this feature is the EXPIRE_TIME parameter. This parameter is set in
the sqlnet.ora file. This specifies the time interval in minutes a probe is sent out to
detect dead connections and if found cause the server process to exit cleanly
clearing locks and release resources. Otherwise the system administrator will have
to resort to the “alter system kill session” command to release locks and resources
held by dead processes. This facility comes with overhead such as increased
network traffic due to dead connection probes being sent out at EXPIRE_TIME
intervals and additional processing on the server to differentiate between dead
processes and regular processes.
Conclusions:
The Designer 2000 toolset is a valuable modeling and development tool.
This toolset needs to be managed and administrated in an organized fashion for
software productivity which is coming under increasing scrutiny. The use of the
above techniques should go a long way in providing a well tuned Designer 2000
environment.
BIBLIOGRAPHY:
1. Cary Millsap, Oracle for UNIX, (1993).
2. Kevin Loney, Oracle DBA Handbook, (1994).