Optimizing Repository Performance
Go Up to Managing Repository Files
The following tips can help optimize the performance of the Repository:
- Dedicated Server: The performance of the Repository is directly affected by the number and size of diagrams and the size of the data transfers between the client and the Repository. We recommend using a dedicated server for the Repository, unless you’re using industrial-strength hardware such as multi-processor rack servers that can manage many applications simultaneously.
- Separate the Repository Server from the Repository Database: The Repository Server and Repository Database do not have to reside on the same machine, however such a configuration may reduce wait times due to reduced contention. If you decide to separate the Repository Server and the Repository Database, for optimal performance, the Server should reside in the same physical local as the users.
- Clearing Repository Folders: On the Repository Server machine there are RepoIn and RepoOut folders in the \...\Embarcadero\Repository\ folder. Sometimes network problems cause entries to be created in these folders. Many files in these folders can hinder Repository performance. Periodically purging the files in these folders should be done frequently, such as nightly, when no one is connected to the repository.
- Anti-Virus: Disabling scanning of Repository files and folders will prevent the anti-virus software from interfering with Repository operations. Since the Repository writes and deletes files in the RepoIn and RepoOut folders in the \...\Embarcadero\Repository\ folder, it is recommended to disable any anti-virus scanning of those folders on the server machine. The Repository also writes temporary files with the extensions .IN and .CNL to the installation folder and on older versions these were written to Windows\System32 . It is recommended to disable scanning of files with those extensions in that folder.
- For Oracle environments:
- Separate Tablespaces: Create separate tablespaces for Repository tables, ERSTUDIO_DAT and indexes, ERSTUDIO_IDX . The extent of each of these tablespaces should be 1 MB or larger. In some very large Repository environment it may be beneficial to further separate the larger tables and their indexes creating, for example ERSTUDIO_DAT2 and ERSTUDIO_IDX2 in addition to the original tablespaces.
- Rebuild Indexes: The Repository index, ERSTUDIO_IDX should be rebuilt at least once a month. Depending on how many diagrams are added, the index may need to be rebuilt on a weekly basis.
- Analyze and Compute Statistics: The response of queries to the Repository can be improved by running DBMS_STATS for recent Oracle version or the Analyze Table and Compute Statistics statements for older versions. These commands gather information about data distribution within the tables and indexes and update the data dictionary with this information. This enables the cost-based query optimizer to make more intelligent decisions about how to efficiently process SQL statements that access the tables or indexes.
- Oracle Logs: Check In operations can cause checkpointing to occur which can interrupt other Repository actions to the detriment of response time. To minimize the effect checkpoint has, increase the size of the logs, set the log_checkpoint_interva l parameter in init.ora to zero, and reduce the size of the log buffer.