StreamServe Persuasion SP5 Oracle Database

Transcription

1 StreamServe Persuasion SP5 Oracle Database Database Guidelines Rev A

2 StreamServe Persuasion SP5 Oracle Database Database Guidelines Rev A STREAMSERVE, INC. ALL RIGHTS RESERVED United States patent #7,127,520 No part of this document may be reproduced or transmitted in any form or by any means, electronic or mechanical, for any purpose, without the express written permission of StreamServe, Inc. Information in this document is subject to change without notice. StreamServe Inc. assumes no responsibility or liability for any errors or inaccuracies that may appear in this book. All registered names, product names and trademarks of other companies mentioned in this documentation are used for identification purposes only and are acknowledged as property of the respective company. Companies, names and data used in examples in this document are fictitious unless otherwise noted. StreamServe, Inc. offers no guarantees and assumes no responsibility or liability of any type with respect to third party products and services, including any liability resulting from incompatibility between the third party products and services and the products and services offered by StreamServe, Inc. By using StreamServe and the third party products mentioned in this document, you agree that you will not hold StreamServe, Inc. responsible or liable with respect to the third party products and services or seek to do so. The trademarks, logos, and service marks in this document are the property of StreamServe, Inc. or other third parties. You are not permitted to use the marks without the prior written consent of StreamServe, Inc. or the third party that owns the marks. Use of the StreamServe product with third party products not mentioned in this document is entirely at your own risk, also as regards the StreamServe products. StreamServe Web Site

3 3 Contents About StreamServe repositories...5 Overview of StreamServe repositories...6 StreamServe Enterprise Repository... 7 Runtime repository... 8 StreamServe archive... 9 Web content repository Tools for handling StreamServe repositories...11 Installing StreamServe repositories...13 Hardware and software requirements...14 Software requirements Hardware requirements Server configuration Installing an Oracle database...16 Creating an Oracle database Increasing Unicode support Changing non-default database parameters Disabling changed locking behavior Placing data files and redo-log files Configuring of Oracle Net Creating StreamServe repositories...21 Checking StreamServe repositories...22 Adjusting StreamServe repositories...23 Tables with highest growth rate and number of rows Editing the StreamServe tablespaces Indexing Columns suitable for indexing Indexing columns in the runtime repository Indexing columns in the StreamServe archive Partitioning Tables suitable for partitioning Uninstalling StreamServe repositories...30 Maintaining StreamServe repositories...31 Top jobs, input jobs and output jobs...33 Deleting expired jobs from the runtime repository...34 Job deletion process Prerequisites and recommendations Design Center configurations Job deletion schedule Scheduling StreamServers to delete jobs Scheduling Task Schedulers to delete jobs Scheduling the database to delete jobs... 40

4 4 Updating top job statuses in the runtime repository Job status update process Recommendations Scheduling StreamServers to update job statuses Scheduling Task Schedulers to update job statuses Scheduling the database to update job statuses Gathering statistics Gathering sample statistics Gathering system statistics Rebuilding indexes Ensuring sufficient free space Running maintenance procedures as database jobs Creating database jobs using DBMS_SCHEDULER Creating database jobs using DBMS_JOB Monitoring maintenance sessions and jobs Monitoring jobs in the runtime repository Queries when monitoring jobs and job statuses Queries when monitoring job delete performance Performing backup of StreamServe repositories Appendix A - Time scheduling syntax Appendix B - SQL EXPLAIN PLAN and datatype RAW... 65

5 About StreamServe repositories 5 About StreamServe repositories This document provides an overview of how to install, maintain, and back up the StreamServe repositories running on Oracle Database. Intended audience This document is intended for developers, for example StreamServe consultants, who are also familiar with Oracle databases. The document also contains some information that may be of interest for a database administrator, for example information about the tables with the highest growth rate and how StreamServe jobs are deleted from the runtime repository. Information about third party products This document does not describe how to carry out configurations in third party products, for example in Oracle SQL*Plus or Oracle SQL Developer. For such information, see the Oracle user documentation. In this section Overview of StreamServe repositories on page 6. Tools for handling StreamServe repositories on page 11.

6 6 Overview of StreamServe repositories About StreamServe repositories Overview of StreamServe repositories StreamServe uses the following repositories: StreamServe Enterprise Repository. Runtime repository. StreamServe archive (for StreamStudio Collector). Web content repository (for StreamStudio Composition Center). Figure 1 Overview, StreamServe repositories and components For detailed information about the StreamServe components that interacts with the repositories, see the Control Center documentation.

7 Overview of StreamServe repositories 7 About StreamServe repositories StreamServe Enterprise Repository A StreamServe Enterprise Repository contains information about computers, StreamServe applications, and StreamServe application domains for a company or organization. You use one central enterprise repository, installed on a specified database server. If document types are used to categorize documents (for example, as invoices or orders), the enterprise repository is the master storage for these document types. The enterprise repository is also the master storage for the StreamStudio Composition Center template versions. All communication with the enterprise repository is handled via a management gateway. For example, Control Center communicates with the enterprise repository through a management gateway. Several management gateways can connect to the same enterprise repository. Figure 2 Communicating with the enterprise repository Default schema owner and password Default database user name The schema owner and password are the same as the database user name. That is, StrsSERAccess StrsSERAccess The management gateway uses this default user when accessing the enterprise repository.

8 8 Overview of StreamServe repositories About StreamServe repositories Runtime repository The runtime repository stores jobs and job related information in queues. The repository also contains security profiles and web access information for the StreamStudio web applications. Any persistent resources are also stored in the repository. For example, document definitions for StreamStudio Composition Center and exception rules to pause service-enabled StreamServe Messages. If you pause Messages, the Messages are stored in a separate queue called the Message storage. If you use the Document Broker Plus solution, the documents are stored in a queue called the Post-processing storage. Each StreamServe application domain requires a separate runtime repository. For example, one repository can be used for the StreamServe applications in development, and another for the StreamServe applications in production. One runtime repository is shared by all the applications in the application domain. The runtime repository is accessed by StreamServer, Archiver and Task Scheduler applications. When a StreamStudio web portal accesses the runtime repository, the requests and responses are sent through the service gateway. Figure 3 Communicating with the runtime repository Default schema owner and password dbo Default repository user strsdataandqueues The StreamServer user. The user handles all StreamServe jobs and queues. strssecurity The service gateway user. The user handles the security related tables in the runtime repository, and the user authentication. strsweb The StreamStudio user. The users that you create in StreamStudio use this user to connect to the runtime repository.

9 Overview of StreamServe repositories 9 About StreamServe repositories StreamServe archive The StreamServe archive stores output documents and related metadata to be accessed from StreamStudio Collector. The StreamServe archive is optimized for searching and querying for documents. Each application domain can access one single StreamServe archive. However, one StreamServe archive can be shared by several application domains. An Archiver application transfers documents and related metadata from the runtime repository to the StreamServe archive according to schedules defined in Control Center. When the Collector user searches for documents in the StreamServe archive, all requests and responses are sent through the service gateway. Figure 4 Communicating with the StreamServe archive Default schema owner and password Default repository user The default repository name, which is the name that the Control Center user assigns when the StreamServe archive is created. See the Control Center documentation. strsweb The user that Collector uses to access the StreamServe archive.

10 10 Overview of StreamServe repositories About StreamServe repositories Web content repository The web content repository is used by StreamStudio Composition Center for storing document definitions, resources, and rules during the document design phase. When a document definition is approved, the document definition (together with its resources and rules), is set to published in the runtime repository, and is available to the StreamServer application that produces the document. The web content repository communicates exclusively with Composition Center. Figure 5 Communicating with the web content repository Default schema owner and password Default repository user dbo (if you create the application domain using the Application Domain Editor in Control Center) with the same password as the web content profile with the default user strswebcontent. strswebcontent The user that Composition Center uses to access the web content repository.

11 Tools for handling StreamServe repositories 11 About StreamServe repositories Tools for handling StreamServe repositories When handling StreamServe repositories, it is recommended to use the tools, applications and scripts provided by StreamServe. Priority order Use the priority order below when deciding which tool to use: 1 Handle as much as possible using the configuration tools provided by StreamServe, for example in Design Center, in Control Center or in the StreamStudio web applications. 2 Use StreamServe Database Administration Tool only for tasks which cannot be performed in the configuration tools above. For more information about this tool, see the Database Administration Tool documentation. 3 Use an appropriate Oracle tool, for example Oracle SQL*Plus or Oracle SQL Developer, only for tasks which cannot be performed using the StreamServe tools. When running external tools, you should primarily use the database scripts provided by StreamServe. For example, the StreamServe maintenance scripts referred to in this document.

12 12 Tools for handling StreamServe repositories About StreamServe repositories

13 Installing StreamServe repositories 13 Installing StreamServe repositories This chapter contains information on how to install and configure an Oracle database for StreamServe and how to create the StreamServe repositories. In this section Hardware and software requirements on page 14. Installing an Oracle database on page 16. Creating StreamServe repositories on page 21. Checking StreamServe repositories on page 22. Adjusting StreamServe repositories on page 23. Uninstalling StreamServe repositories on page 30. Related topics For information on how to set up StreamServe for Oracle RAC (Real Application Cluster), see the Cluster Guidelines.

14 14 Hardware and software requirements Installing StreamServe repositories Hardware and software requirements The requirements below applies for the database server where you install the runtime repository and the StreamServe archive. In this section Software requirements on page 14. Hardware requirements on page 14. Server configuration on page 14. Software requirements Oracle Database It is recommended to use Oracle Database Enterprise Edition for large installations where the StreamServe archive is used. For a complete list of supported versions, see the Supported platforms and software documentation. Hardware requirements 2 CPUs (minimum). The required number of CPUs depend on the data volume and the number of users. If several StreamServe processes run concurrently against the same database, more CPUs are recommended. 8 GB RAM (recommended minimum). The required memory depends on the data volume and the number of users. A rule of thumb is 1 GB for the SGA (System Global Area) and 1 GB for the PGA (Process Global Area). It is recommended to run 64-bit Oracle. Server configuration The computer where you install the database needs lots of memory and numerous fast striped disks. Since StreamServer is an update/insert heavy application, it is recommended to use RAID 1+0 (not RAID-5) for data. A good I/O strategy is the Oracle recommended S.A.M.E. method (stripeand-mirror-everything, using a stripe size of 1 MB). For more information, see the Oracle user documentation. Another strategy, especially if the disks are single-disks, is to implement Oracle ASM (Oracle Automatic Storage Management) with fail over groups. ASM uses software raid with stripe size depending on the type of Oracle file, and is capable of re-balancing the disks if new disks are added. If you use ASM, you must use RMAN (Oracle Recovery Manager) for database backups. For more information, see the Oracle user documentation.

15 Hardware and software requirements 15 Installing StreamServe repositories Single-disks are not recommended. S.A.M.E or ASM is recommended (note that ASM is possible to use with single disks). Single disks without ASM are only recommended for very small sites with few users (by small means less than or equals documents in the database, and less than or equal to 10 concurrent sessions). If single disks are to be used, the following general guidelines apply: Place three control files on physically different disks. Place two redo log members per redo log group on different dedicated physical disks. Spread the data files and temp files on the disks, except the one used for redo log files.

16 16 Installing an Oracle database Installing StreamServe repositories Installing an Oracle database A basic Oracle database is sufficient for StreamServe. StreamServe does not depend on any additional database options, such as Java in the database, Oracle Text, Oracle Multimedia, Spatial, etc. When the Oracle database is installed, you can create the StreamServe repositories. See Creating StreamServe repositories on page 21. In this section Creating an Oracle database on page 16. Increasing Unicode support on page 17. Changing non-default database parameters on page 18. Disabling changed locking behavior on page 19. Placing data files and redo-log files on page 20. Configuring of Oracle Net on page 20. Creating an Oracle database Prerequisites The time zone must be set to UTC both for the database server where you install the runtime repository and for the database server where you install the StreamServe archive. Before you create the database, you must specify the following non-default database server parameter. Parameter Recommended Comment db_block_size 8192 Must be at least If the database server has lots of memory (more than 4 GB), this value can be raised to To create an Oracle database 1 Create a UTF database with: Character set AL32UTF8. National character set AL16UTF16.

17 Installing an Oracle database 17 Installing StreamServe repositories 2 Set the database time zone to UTC (that is, GMT). You can do this either by editing the database creation scripts and adding a time zone clause to the CREATE DATABASE command: SET TIME_ZONE = 'UTC' or by running the command below and restarting the database after creation (but before creating the StreamServe repositories): ALTER DATABASE SET TIME_ZONE = 'UTC'; SHUTDOWN IMMEDIATE STARTUP 3 Make all tablespaces locally managed. 4 Make all tablespaces (where applicable) automatic segment space managed (SEGMENT SPACE MANAGEMENT AUTO, which is default on Oracle 11g). 5 If the database character set uses a multi-byte character encoding scheme and the default Unicode support is not enough, you can increase the Unicode support, see Increasing Unicode support below. Increasing Unicode support By default StreamServe uses NVARCHAR2, which normally offers enough Unicode support. To achieve a more general Unicode support, you can specify the database server parameter below. The parameter must be specified before the StreamServe repositories are created. Parameter Value Comment nls_length_ semantics char StreamServe recommends the default byte value, since the char value requires more space in the database. For more information about the nls_length_semantics parameter, see the Oracle user documentation, and the Oracle Support document Examples and limits of BYTE and CHAR semantics usage (NLS_LENGTH_SEMANTICS) (Doc ID ).

18 18 Installing an Oracle database Installing StreamServe repositories Changing non-default database parameters If you are not satisfied with your Oracle installation, you may have to change the following non-default database server parameters. After changing the parameters, you may have to restart the Oracle database. Parameter name Recommended value Comment job_queue_ processes <default> The StreamServer application does not use any database jobs. However, the database administrator may need the job_queue_processes parameter for administrative jobs. processes is a minimum value. Larger environments, where several StreamServer applications are used, may need a higher value. pga_aggregate_ target <Machine RAM> - <Non Oracle RAM> - sga_target The relationship between pga_aggregate_target and sga_target depends on the number of users. Start with: sga_target = pga_target sga_target <Machine RAM> - <Non Oracle RAM> - pga_aggregate_target The relationship between pga_aggregate_target and sga_target depends on the number of users. Start with: sga_target = pga_target

19 Installing an Oracle database 19 Installing StreamServe repositories Disabling changed locking behavior This section applies for Oracle and later, and previous Oracle 11 versions with Oracle patch applied (changed locking behavior). Problem If a service-enabled Message is paused by an exception rule, the Message is stored in a Message storage in the runtime repository. The Message storage tables are created by the StreamServer application the first time the application is started. If there are other ongoing transactions against certain tables in the runtime repository, the StreamServer application may fail when enabling the required foreign key constraints. The following error message is displayed: ORA-00054: resource busy and acquire with NOWAIT specified Solution A supported work-around from Oracle is to disable the patch by running the statement below. Disabling the patch means that no exclusive access to the parent table will be required when enabling foreign key constraints. Since the parameter is dynamic, you do not have to restart the Oracle database after disabling the patch. ALTER SYSTEM SET "_fix_control"=' :off' scope=both; You can run the following query to check that the patch was disabled: SELECT bugno,value,is_default FROM V$SYSTEM_FIX_CONTROL WHERE bugno = ; The following should be returned: BUGNO VALUE 0 IS_DEFAULT 0

20 20 Installing an Oracle database Installing StreamServe repositories Placing data files and redo-log files It is recommended to use S.A.M.E or ASM (see Hardware and software requirements on page 14). However, if neither S.A.M.E. nor ASM is used, the following is recommended (Oracle best practice): At least two control files on different disks. At least two redo-log members per group, placed on different dedicated disks (no data files on these disks). Spread the data files on the remaining disks. For more information, see the Oracle user documentation. Configuring of Oracle Net It is recommended to put the following parameter in sqlnet.ora on the database server: SQLNET.EXPIRE_TIME = 10 This ensures that Oracle looks for and removes sessions that for some reason are left but not used, for example due to network problems or that a client machine goes down. The number set is the minute interval when a probe is sent from Oracle to verify if client connections are still active. For more information, see the Oracle user documentation.

21 Creating StreamServe repositories 21 Installing StreamServe repositories Creating StreamServe repositories You use StreamServe Control Center to configure and create the StreamServe repositories. You can either create the repositories directly in Control Center, or you can generate the database scripts in Control Center and then run the scripts using an external tool. For example, if the company security policy prevents Control Center from connecting to the database, or if you want to have full traceability of the repository creation. If Control Center is not available at all, you can carry out the corresponding procedures using the command line utilities. For more information, see the StreamServe Command line utilities documentation. Modifying repository users In the Control Center configurations, default repository users are suggested (see Overview of StreamServe repositories on page 6). It is recommended to change these users before creating the repositories. If Control Center is not available, you can modify the users directly in the template files. These files are located in: Windows: <StreamServe installation>\applications\management\<version>\ etc\databasescripts\<version>\oracle\security UNIX: <StreamServe installation>/applications/managementgateway/ etc/databasescripts/<version>/oracle/security Prerequisites An Oracle database must be installed before you create the StreamServe repositories, see Installing an Oracle database on page 16. To create the StreamServe repositories See the Control Center documentation for detailed information on how to: Configure the StreamServe repositories. Create the StreamServe repositories directly in Control Center. Generate the database scripts in Control Center and then execute the scripts. Note: Since the scripts contains passwords, it is recommended to delete the scripts after you have created a repository.

22 22 Checking StreamServe repositories Installing StreamServe repositories Checking StreamServe repositories After creating a repository, it is recommended to check the repository. Check the log files for errors When creating a repository in Control Center, you can check a short version of the log file in Control Center, or you can open the full log file in a text editor from within Control Center. When executing the generated scripts using an external tool, you can use the logging features of this tool. For example when using Oracle SQL*Plus, you can use the SPOOL command. For more information, see the Oracle user documentation. Perform a sanity test You should always perform a sanity check to make sure the repository was created according to the configurations. Check the database for INVALID schema objects Check the database for INVALID schema objects. Run the query below in Oracle SQL*Plus as a DBA user. No rows should be returned. SELECT FROM WHERE owner, object_name dba_objects status='invalid'; If you find INVALID objects, you can recompile these objects by running the following query: EXEC DBMS_UTILITY.compile_schema(schema => '<Schema name>');

23 Adjusting StreamServe repositories 23 Installing StreamServe repositories Adjusting StreamServe repositories An enterprise repository that you create in Control Center can be used for development and testing purposes and may also be sufficient for a production environment. If specific security or performance requirements apply, you may have to adjust the enterprise repository to fit the actual conditions. A runtime repository and a StreamServe archive that you create in Control Center are sufficient for development and testing purposes. However, before using these repositories in a production environment, you most likely have to adjust the repositories to fit the actual conditions. For example, you may have to edit tablespaces, index columns, and partition tables and indexes. It is recommended to create the repositories using Control Center and then adjust the repositories using the appropriate Oracle tool, for example Oracle Enterprise Manager or Oracle SQL*Plus. In this section Tables with highest growth rate and number of rows on page 23. Editing the StreamServe tablespaces on page 24. Indexing on page 26. Partitioning on page 29. Tables with highest growth rate and number of rows Runtime repository The runtime repository tables with highest growth rate and highest number of rows are: BinaryObject BlobInfo Part VariableMetadata FixedMetadata CXMESSAGE_<8-DigitNumber> Note: Only if Messages are paused in the Message storage. CXPOST_<8-DigitNumber> Note: Only if documents are stored in the Post Process storage. StreamServe archive The StreamServe archive table with highest growth rate and highest number of rows is: Meta_<5-DigitNumber>

24 24 Adjusting StreamServe repositories Installing StreamServe repositories Editing the StreamServe tablespaces When the runtime repository is created, all segments (tables, indexes, etc) are by default created in a tablespace called USERS. The tablespace is a logical storage unit within the Oracle database. In Oracle Enterprise Manager or Oracle SQL*Plus, you can edit the default tablespace to fit the actual conditions. Using different tablespaces enables you to control the disk layout. For example, you can place a heavily used index on a fast disk and a rarely accessed database table on a less expensive, but slower disk. Tablespaces for dynamically created tables Message / Post-processing storage At runtime, tables and indexes are created in the first found tablespace called <Name>_DATA (for tables) and <Name>_INDEX (for indexes) in which the repository owner has a quota. If no such tablespaces are found, the segments are created in the default tablespace for the repository owner. StreamServe archive At runtime, tables, indexes, and blobs are created in the first found tablespace called <Name>_DATA (for tables), <Name>_INDEX (for indexes), and <Name>_LOB (for blobs) in which the repository owner has a quota. If no such tablespaces are found, the segments are created in the USERS tablespace. To edit the StreamServe tablespaces 1 Create the required tablespaces (locally managed, automatic segment space management). For example: <Name>_DATA for data. <Name>_INDEX for index. <Name>_LOB for blobs. 2 Give quotas to the StreamServe repository owner in the created tablespaces. 3 Open the build_move_segments.sql script, located in: <Base directory>\root\config\database\5.5.0\strsdata\oracle Where <Base directory> is the path specified for StreamServe Projects during the StreamServe Framework and Control Center installation. For example: C:\ManagementGateway\1.0 4 Run the build_move_segments.sql script as the schema owner. The script spools the DDL (Data Definition Language) move commands to a text file. 5 Check/verify the created text file move_streamserve_segments_temp.sql and run the script. For example: running build_move_segments.sql: Enter current index tablespace: USERS Enter current LOB tablespace: USERS Enter new data tablespace: <Name>_DATA Enter new index tablespace: <Name>_INDEX

25 Adjusting StreamServe repositories 25 Installing StreamServe repositories Enter new LOB tablespace: <Name>_LOB 6 Verify that there are no errors in the log file move_streamserve_segments_ TEMP.log.

26 26 Adjusting StreamServe repositories Installing StreamServe repositories Indexing For most tables, performance will be improved by indexing one or several of the columns. You should consider indexing columns that are used when filtering out a relatively small amount of rows from the tables. Indexing columns improves the speed of the data retrieval operations, but at the cost of increased storage space and slower writes. If a table is subjected to lots of inserts, increasing the number of indexes may have negative effect on the insert performance. You must take this into consideration when deciding whether to index or not. You index columns using the appropriate Oracle tool, for example Oracle SQL*Plus or Oracle SQL Developer. Prerequisites To create an index in your own schema, one of the following must apply: The table or cluster to be indexed must be in your own schema. You must have the INDEX object privilege on the table to be indexed. To create an index in another schema, you must have the CREATE ANY INDEX system privilege. Also, the owner of the schema to contain the index must have space quota on the tablespaces to contain the index or index partitions. In this section Columns suitable for indexing on page 26. Indexing columns in the runtime repository on page 27. Indexing columns in the StreamServe archive on page 28. Columns suitable for indexing The columns most suitable for indexing are usually the ones with user defined metadata, configured in StreamServe Design Center. Consult the end-users for information about which document types and which metadata are most frequently used and index the corresponding columns.

27 Adjusting StreamServe repositories 27 Installing StreamServe repositories Indexing columns in the runtime repository If the runtime repository contains Message storages or Post-processing storages, you should consider indexing these storages. Message storage When a Message is paused by an exception rule, the Message is stored in the Message storage. The Messages can then be invoked via service calls, for example web service calls from Ad Hoc Correspondence or Correspondence Reviewer. If a large amount of rows are stored in a Message storage, the service call performance may be improved by indexing one or several of the columns. The columns most suitable for indexing are the ones for user defined metadata (that is, the ones configured with the Message context in Design Center). Example 1 Indexing a column in the Message storage In this example, an index is added to the column COL_1 in a Message storage called CXMESSAGE_ The column is indexed using the following command: CREATE INDEX ixlcol_1 ON CXMESSAGE_ (COL_1); Post-processing storage When Document Broker Plus is used, the documents are stored in a Postprocessing storage. Metadata is used when searching for, retrieving and postprocessing the documents. If a large amount of rows are stored in the storage, the search performance may be improved by indexing one or several of the columns. The columns most suitable for indexing are the ones for user defined metadata (that is, the ones configured with the Post-processing context in Design Center). Example 2 Indexing a column in the Post-processing storage In this example, an index is added to the column COL_1 in the Post-processing storage called cxpost_ The column is indexed using the following command: CREATE INDEX ixlcol_1 ON stc.cxpost_ (col_1);

28 28 Adjusting StreamServe repositories Installing StreamServe repositories Indexing columns in the StreamServe archive When an end-user searches for documents in StreamStudio Collector, metadata is used as search criteria. If a large amount of rows are stored in the metadata tables, the search performance may be improved by indexing the columns for this metadata. The columns most suitable for indexing are the ones for user defined metadata (configured with the Archive context in Design Center). Example 3 Indexing metadata In this example, an index is added to the metadata column Col_1 for the document type table META_ CREATE INDEX ixlcol_1 ON Meta_00001(Col_1);

29 Adjusting StreamServe repositories 29 Installing StreamServe repositories Partitioning For large tables (for example, larger than 2 GB), performance may be improved by partitioning tables and indexes. Tables and indexes are then split into smaller components, where each component can be managed and manipulated individually. For example, when deleting documents from the StreamServe archive you can drop one or several partitions instead of deleting millions of documents. Partitioning is a separately licensed option, on top of Oracle Database Enterprise Edition. When setting up partitioning, it is recommended to consult an Oracle expert. For detailed information, see the Oracle user documentation. If the tables contain data, conversion to partitioning is an extensive operation that requires recreating and reloading of data into the tables. Tables suitable for partitioning Runtime repository BinaryObject The table has no field that is suited for range partitioning, but you can use hash partitioning on the field PartID in order to spread I/O and for parallel SQL operations. BlobInfo The table can be range partitioned on field CreationDate, although it requires global indexes for primary key and foreign keys indexes. You can also hash partition it on, for example, the field PartID. Part The table can be range partitioned on field CreationDate, although it requires global indexes for primary key and foreign keys indexes. You can also hash partitioned it on, for example, the field PartID. VariableMetadata FixedMetadata CXMESSAGE_<8-DigitNumber> CXPOST_<8-DigitNumber> StreamServe archive Meta_<5-DigitNumber> The field BlobInfo.CreationDateTime is suitable for range partitioning.

30 30 Uninstalling StreamServe repositories Installing StreamServe repositories Uninstalling StreamServe repositories When you uninstall StreamServe, you can choose to remove the StreamServe components. This uninstalls the files and services for the StreamServe repositories, but does not delete the repositories or the repository users. Under certain circumstances, you may want to drop a repository. For example, if you upgrade to a later StreamServe release, and want to create a new enterprise repository instead of upgrading the existing repository. When you drop a repository, all data within the repository is lost. Prerequisites Before dropping a repository, the following must be fulfilled: The StreamServe components must be removed. If not, the repository services are not deleted, resulting in a corrupt StreamServe installation. For information on how to uninstall and remove StreamServe components, see the Installation Guide. There must be no active sessions running against the repository. To read active sessions To read active sessions, you can run the following command Oracle SQL*Plus as a DBA user, for example SYSDBA. SELECT username, count(username) FROM v$session WHERE username like 'strs%' GROUP BY username To drop a repository To drop a repository, you can run the following command as a user with privileges at least corresponding to a DBA user. DROP USER <Schema name> CASCADE;

31 Maintaining StreamServe repositories 31 Maintaining StreamServe repositories You maintain the StreamServe repositories using standard Oracle maintenance procedures. For recommended maintenance activities, including error handling and performance improvement strategies, see the Oracle user documentation. StreamServe specific maintenance tasks If you experience performance bottlenecks related to the database, you can tune the StreamServe specific maintenance tasks below to optimize your environment. Note: If you do not experience any performance bottlenecks, you should keep the default setup and the default scheduling. Job deletion You can optimize the way in which expired top jobs and job status information are deleted from the runtime repository. Job status update To be deleted from the runtime repository, the status of a top job must be set to completed. You can optimize the way in which the status of top jobs are updated. Maintenance package StreamServe provides scripts for gathering statistics and rebuilding indexes. These scripts are described in this chapter. Running the StreamServe specific maintenance tasks charges the database and may affect the database performance. This chapter contains some recommendations regarding setting up and scheduling of the maintenance tasks. Rather than being absolute truths, these recommendations are to be considered as starting points for trying out the most optimal settings for your specific job setup and environment. The tuning of the maintenance tasks is a continuous assignment. You must monitor the jobs in the runtime repository to ensure that the tasks are correctly scheduled and that the database does not grow over time. You should always schedule the maintenance tasks in a way that ensures minimum impact on any other database activities.

32 32 Maintaining StreamServe repositories In this section Top jobs, input jobs and output jobs on page 33. Deleting expired jobs from the runtime repository on page 34. Updating top job statuses in the runtime repository on page 41. Gathering statistics on page 46. Rebuilding indexes on page 49. Running maintenance procedures as database jobs on page 52. Monitoring jobs in the runtime repository on page 55.

33 Top jobs, input jobs and output jobs 33 Maintaining StreamServe repositories Top jobs, input jobs and output jobs This section describes the concept of top jobs. You must be aware of this concept when scheduling the tasks for job deletion and the job status update. Top jobs, input jobs and output jobs StreamServe jobs are divided into top jobs, input jobs and output jobs. A top job is created when a StreamServer application receives input, for example from an ERP system. Each top job is divided into one or more input jobs processed by the StreamServer application. When the application processes an input job, it produces one or more output jobs. This means a top job can be divided into several input jobs, and each input job can be divided into several output jobs. All jobs that belong to the same top job are identified by the same Tracker ID. A top job is completed when all included input and output jobs are completed. Figure 6 Top job, input jobs and output jobs

34 34 Deleting expired jobs from the runtime repository Maintaining StreamServe repositories Deleting expired jobs from the runtime repository Expired top jobs and job status information must be deleted from the runtime repository. The job deletion must also include expired Messages/documents in Message/Post-processing storages in the runtime repository. Three ways of deleting jobs In this documentation, three ways of deleting jobs are described: Schedule the StreamServer applications to delete jobs (default). Schedule one or several Task Scheduler applications to delete jobs. Schedule the database to delete jobs. Low volume installation with a single StreamServer application By default, each StreamServer application is set up to perform job data deletion tasks every hour. Successfully completed job data is kept in the repository for 5 days. Failed job data is kept for a month. The job deletion is regulated in the repositorymanager.xml configuration file for each StreamServer application. This job deletion is suitable for less complex, low volume installations with a single StreamServer application. To optimize the delete performance, you may have to update the schedule. High volume installations with several StreamServer applications For medium to high volume installations, where several StreamServer applications try to follow the instructions in repositorymanager.xml at the same time, it is recommended to let one or several StreamServe Task Scheduler applications delete the jobs instead. Using Task Scheduler applications may improve performance by centralizing the status updates and enabling more complex and controlled schedules. If you prefer to handle the job deletion outside the StreamServe software, you can set up a job scheduling task for deleting jobs directly in the database instead of using Task Scheduler applications. In this section Job deletion process on page 35. Prerequisites and recommendations on page 36. Scheduling StreamServers to delete jobs on page 38. Scheduling Task Schedulers to delete jobs on page 39. Scheduling the database to delete jobs on page 40.

35 Deleting expired jobs from the runtime repository 35 Maintaining StreamServe repositories Job deletion process This section describes the order in which expired top jobs and expired Messages/ documents in Message/Post-processing storages are deleted. If you schedule StreamServer applications to delete jobs, the stored procedures are automatically executed in the correct order. If you schedule Task Scheduler applications or the database to delete jobs, you should make sure that the tasks are executed as described below. Step 1 Expire jobs In StreamServe Design Center, expiry times for successfully processed and failed top jobs are configured. The jobs remains in the queues for the expiry time and are then ready to be handled by the job deletion process. Note: You can also manually expire jobs using StreamStudio Reporter or StreamServe Database Administration Tool. Step 2 Delete expired Messages and documents The pc_deleteexpireddocabstraction stored procedure deletes any expired Messages/documents from Message/Post-processing storages. Step 3 Mark jobs for deletion The pq_deletemarkexpiredtopparts stored procedure searches for expired top jobs that are ready to be deleted and marks these jobs for deletion. Step 4 Delete marked jobs The pq_pickdeleteevent stored procedure deletes any expired top jobs marked for deletion. Only top jobs without any related Messages/documents in Message/ Post-processing storages can be deleted. Note: An archiving job cannot be deleted unless all related documents are first transferred to the StreamServe archive.

36 36 Deleting expired jobs from the runtime repository Maintaining StreamServe repositories Prerequisites and recommendations For optimal performance when deleting jobs and job status information, you must consider both the Design Center configurations and the scheduling of the job deletion. In this section Design Center configurations on page 36. Job deletion schedule on page 37. Design Center configurations It is strongly recommended to configure the input and output queues to store both successful and failed jobs (Store information and job should be selected for successful and failed jobs in the Manage Queues dialog box). Note: Both information and jobs are always initially stored in the runtime repository. If the options to store nothing or store information only are used, expired input and output jobs are continuously deleted from the queues. This results in an increased number of delete transactions and a decreased delete performance. To delete successful jobs, the deletion process must be allowed to delete successful jobs (Delete successful jobs must be enabled in the Configure Platform dialog box. It is recommended to configure a short expiry time for the successfully processed jobs (the Allow deletion after setting in the Configure Platform dialog box). As a rule of thumb, you should keep the number of top jobs marked for deletion to a minimum. This has a great impact on the delete performance, especially if each top job generates one single output job. However, you must also consider how long the customer wants to access successful jobs in the queues. To delete failed jobs, the job deletion process must also be allowed to delete failed jobs (Delete failed jobs must be enabled in the Configure Platform dialog box). An expiry time for the failed top jobs must be configured (the Allow deletion after setting in the Configure Platform dialog box). You must consider how long the customer wants to access the failed jobs in the queues. If possible, avoid using notifications (Use notifications should be cleared in the Configure Platform dialog box). For more information about the options, see the Design Center documentation.

37 Deleting expired jobs from the runtime repository 37 Maintaining StreamServe repositories Job deletion schedule It is recommended to schedule the job deletion in the following way: Primarily, you should run the job deletion at a time period when the StreamServer applications are idle or the job throughput is low. For example, after scheduled batch jobs or when the average CPU usage for the database falls below a specified value and remains below this level for a specified time period. Note: You must make sure that the available time period is longer than the time interval required to complete the job deletion after a peak load. If the available time periods are too short or if the workload is continuous, you should start the job deletions at an available time period and then schedule the remaining deletions in the following way: In general, schedule a continuous job deletion with a high frequency. Exception If most of your top jobs generate many output jobs, you may receive a better delete performance by running job deletion less frequent or (if possible) after each top job is successfully completed.

38 38 Deleting expired jobs from the runtime repository Maintaining StreamServe repositories Scheduling StreamServers to delete jobs By default, the job deletion is scheduled in the repositorymanager.xml file for each StreamServer application. Every 20 minutes, each StreamServer application searches for and marks any expired top jobs that are ready to be deleted. Every 60 minutes, each StreamServer application triggers the deletion of marked jobs, expired Messages and expired documents. You can edit the default schedules to fit the actual conditions. Location of repositorymanager.xml You can either edit the configuration in: The template file (used for all new StreamServer applications), located in: Windows: <StreamServe installation>\applications\management\<version>\ etc\config\<version>\strscs\ UNIX: <StreamServe installation>/applications/managementgateway/ etc/config/<version>/strscs/ The changes that you make to s template file only apply for new applications, created after the changes are done. They do not apply for already created applications. The configuration file for a specific StreamServer application, located in: Windows: <Base directory>\root\applications\<application>\<layer> UNIX: <Project location>/applications/<application>/<layer> Prerequisites and recommendations See Prerequisites and recommendations on page 36. To edit the schedule for job deletion 1 Open the repositorymanager.xml file. 2 Edit the following lines: <deleteevent schedule="t II * * MH * * 60" />  <deletemarkevents> <toppart use="default" schedule="t II * * MH * * 20" /> </deletemarkevents> For syntax, see Appendix A - Time scheduling syntax on page 63.

39 Deleting expired jobs from the runtime repository 39 Maintaining StreamServe repositories Scheduling Task Schedulers to delete jobs You can add a StreamServe Task Scheduler application and configure separate tasks for deleting expired top jobs, expired Messages and expired documents. To ensure job deletion even if the Task Scheduler goes down, you can add several Task Scheduler applications. Prerequisites and recommendations See Prerequisites and recommendations on page 36. For information about the order in which the stored procedures should be executed, see Job deletion process on page 35. Post requisites It is recommended to comment out the corresponding lines for job deletion in the repositorymanager.xml files for the StreamServer applications. See Scheduling StreamServers to delete jobs on page 38. To schedule a Task Scheduler to delete jobs 1 In StreamServe Control Center, right-click the application domain and select New Application. The New Application dialog box opens. 2 Configure the application properties for the new Task Scheduler. Note: You cannot use the name Task Scheduler if you run an application on a Windows host, since this name is used by a Windows service. 3 Click OK. The Configuration dialog box opens. 4 Select the (Item list) field and click the button to the right of the field. The Service Configuration dialog box opens. 5 Add and configure the required tasks: Delete expired jobs Delete expired Messages Select to mark expired top jobs for deletion and delete these expired jobs from the runtime repository at the scheduled interval. Threads The maximum number of threads to be used when deleting expired jobs marked for deletion. Several treads enables the application to delete several jobs in parallel. Note that only the first thread searches for and marks jobs for deletion. Note: Each thread consumes system resources Select to delete expired Messages from Message storages in the runtime repository at the scheduled interval.

40 40 Deleting expired jobs from the runtime repository Maintaining StreamServe repositories Delete expired documents Select to delete expired documents from Post-processing storages in the runtime repositoryat the scheduled interval. For more information, see the Control Center documentation. Scheduling the database to delete jobs You can schedule the database to delete expired top jobs, expired Messages and expired documents. The task should be scheduled in a way that ensures minimum impact on any other database activities. You create job scheduling task in the appropriate Oracle tool, for example in Oracle Enterprise Manager. Prerequisites and recommendations See Prerequisites and recommendations on page 36. For information about the order in which the stored procedures should be executed, see Job deletion process on page 35. Post requisites It is recommended to comment out the corresponding lines in repositorymanager.xml files for the StreamServer applications. See Scheduling StreamServers to delete jobs on page 38. To schedule the database to delete jobs 1 Create a job scheduling task, for example in Oracle Enterprise Manager. 2 In the task, use the script run_pickdeleteevent.sql, located in: <Base directory>\root\config\database\<version>\strsdata\ oracle\maintenance\ Where <Base directory> is the path specified for StreamServe Projects during the StreamServe Framework and Control Center installation. For example: C:\ManagementGateway\1.0