Designer 2000 Tuning


Published on

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

Published in: Technology, Business
  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Designer 2000 Tuning

  1. 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. 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. 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. 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(; 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. 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. 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. 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. 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. 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. 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. 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).