| Oracle® Calendar Administrator's Guide 10g Release 1 (10.1.2) Part Number B25485-05 |
|
|
View PDF |
| Oracle® Calendar Administrator's Guide 10g Release 1 (10.1.2) Part Number B25485-05 |
|
|
View PDF |
A regular schedule of Oracle Calendar maintenance is the best protection against unscheduled down time and loss of data. Following the procedures outlined later in this chapter will minimize problems and ensure that your Calendar server runs smoothly and without unexpected interruption.
This chapter outlines the following tasks:
This section explains daily procedures that should be performed in order to monitor the Oracle Calendar server. Moreover, daily and monthly procedures are outlined to help you maintain the Oracle Calendar server.
The following system monitoring procedures should be performed daily. Oracle recommends scripting these procedures:
Check that all relevant daemons/services are operational using the unistatus and uniping utilities. You can also use Oracle Enterprise Manager to accomplish this task.
Check that ample space is left in the $ORACLE_HOME/ocal directory or file system. For more information about calculating the storage requirements for your node, see Appendix A, "Calendar Disk Space and Memory Requirements". You can also use Oracle Enterprise Manager to accomplish this task.
Verify that the previous night's backup has run.
Search for unusual entries in the log files in the $ORACLE_HOME/ocal/log directory. This task can be automated by using grep or searching the log files for specific errors, and sending the results by email to the administrator.
Check for recent writes to the $ORACLE_HOME/ocal/log/dbv.log. This file is created only if there is a problem and should be manually removed once the problem is resolved. If the file is present and is not empty, you might analyze the contents and use the unidbfix utility, or consult Oracle Support for further assistance. For more information on the unidbfix utility, see "Calendar Server Utilities" in Chapter 6 of Oracle Calendar Reference Manual.
Oracle Calendar Administrator
Use the Oracle Calendar administrator to view the server status.
Click the Server Administration tab.
Click on the Servers secondary tab. From this page, you can already see which servers are up and which ones are down based on the icons in the Actions column.
Click the View icon in the Actions column for the server you want to view. The Identification section displays whether the server is running and the number of users currently logged on.
Other server settings (indicating whether user passwords can be changed, whether the server is connected to a Directory Server, and so on) are also displayed.
Command Line
The unistatus utility displays the current status of the calendar server. The uniwho utility can be used to display the list of users currently logged on to the calendar server. Use the -nolist if you only want to see the total number of signed-in calendar users. For more information about the use and syntax of these utilities, see "Calendar Server Utilities" in Chapter 6 of Oracle Calendar Reference Manual.
It is possible to turn on logging of specific calendar activities using server parameters. Most of these options should be only turned on for short periods of time as it increases the amount of data written to log files and can cause these files to grow rapidly. Statistical data can be compiled regarding user connections, activity information of the unicwsd daemon/service, directory server access, and so on.
To view elapsed time and CPU statistics for each client connection, set [ENG] stats=TRUE in unison.ini. When a client connection is closed, stats results are appended to the $ORACLE_HOME/ocal/log/stats.log file. Once the period being analyzed has passed, you must not forget to set the parameter [ENG]stats back to FALSE to disable logging, as the file grows quickly.
For more information about the [CWS]log_activity , [CWS]log_modulesinclude, [ENG]stats, activity and dac_failederrlog parameters, see "Calendar Server Parameters" in Chapter 3 of Oracle Calendar Reference Manual.
A nightly backup of the calendar database ($ORACLE_HOME/ocal/db) and configuration files ($ORACLE_HOME/ocal/misc) is your best protection against database corruption that may occur as a result of a power failure or disk crashes. Use the unidbbackup to back up Oracle Calendar. While database corruption is rare, even under the aforementioned conditions, nightly backups serve as a safeguard if your database cannot be restored. For more information on back up and restore, see Server Backup and Restore later in this chapter.
The following system maintenance procedures should be done after peak volume hours on a monthly basis:
The unidbfix utility should be run in check mode once a week with the calendar server running, and in fix mode once a month, which requires the calendar server to be down. If the weekly check discovers an error, it should be corrected as soon as possible using unidbfix in fix mode; if the weekly check produces a warning, maintenance can be delayed until the monthly fix.
It is possible to stop one node at a time. This allows you to run unidbfix on a single stopped node while the rest of the nodes are still active. Use the -n option to specify which nodes to fix. More than one instance of the unidbfix utility can be run at the same time on different nodes. For more information about the use and syntax of the unidbfixutility, see "Calendar Server Utilities" in Chapter 6 of Oracle Calendar Reference Manual.
When starting the Oracle Calendar server, a clean up of unneeded data is preformed in the Calendar stores. Oracle recommends restarting the Oracle Calendar server once per month, either using the unistop and unistart utilities or the Oracle Process Management and Notification (OPMN) tool. For more information about stopping and starting Oracle Calendar server, see "Starting and Stopping the Oracle Calendar Server".
If you have not enabled automatic log rotation for the Oracle Calendar server, the log files should be rotated manually. When the Oracle Calendar server has been stopped for regular unidbfix maintenance, archive the log files prior to restarting. Log files can also be automatically rotated using the Log Rotation feature. For more information about log rotation, see Managing Log File Rotation later in this chapter.
To improve performance and minimize disk space requirements, the unirmold utility should be run monthly to remove all events and tasks older than 12-36 months, based on your organization's data retention policies. It is advisable to run unirmold during off-peak hours for the calendar server. For more information about the use and syntax of unirmold, see "Calendar Server Utilities" in Chapter 6 of Oracle Calendar Reference Manual.
|
WARNING: Oracle recommends running the |
Verify the consistency of the server database using the unidbfix utility.
When managing user accounts, often it is necessary to delete users from an Oracle Calendar server node or move Oracle Calendar users from one node to another. Use the uniuser utility with the -del option and the unimvuser utility respectively to accomplish these tasks. Use the unimvuser utility to keep users per node approximately the same across your node network. Moreover, Oracle recommends grouping users that have the most Calendar interaction with one another on the same node. This can reduce traffic between nodes in your node network. If you believe that a user has been provisioned to a node that is not a logical workgroup, use the unimvuser utility to move the user to a more logical node. Always use the most recent version of unimvuser in your node network. For full information about use and syntax of the unimvuser utility, including a number of crucial warnings and considerations, see "Calendar Server Utilities" in Chapter 6 of Oracle Calendar Reference Manual.
|
WARNING: Oracle recommends running these utilities only during off-peak hours. |
If you are using a directory server, run unidsdiff to detect and resolve any discrepancies in the mapping between users and resources in the directory server with those in the calendar server node. For more information about the use and syntax of unidsdiff, see "Calendar Server Utilities" in Chapter 6 of Oracle Calendar Reference Manual. You should perform this synchronization procedure every two to four weeks or as required when making a batch of changes to the calendar node, particularly when deleting users. You may also synchronize your calendar and directory servers through the Oracle Calendar administrator.
When Oracle Calendar is deployed with Oracle Collaboration Suite, delete notifications sent by the Oracle Internet Directory may not delete user accounts on the Oracle Calendar server. Use the unidsdiff utility with the -d option, or the uniuser utility with the -del option to delete these users. For more information about delete notifications from Oracle Internet Directory, and calendar user deprovisioning, see "Controlling Delete Notifications from Oracle Internet Directory" in Chapter 7.
Calendar Store Consistency Scan
The Corporate-Wide Services daemon periodically scans the database for certain inconsistencies and fixes them. This scan is not a replacement for unidbfix. It fixes inconsistencies that cannot be fixed by unidbfix. The scan places an informational message in the $ORACLE_HOME/ocal/log/eng.log file, every time it fixes an inconsistency.
There are three types of scans, continuous, incremental and full. The continuous scan is done every few minutes (every 23 minutes by default) and only scans those events that have recently been modified. The continuous scan should not affect the performance and scalability of the server during normal hours, while it regularly scans the database for inconsistencies. Any events that may have been missed by the continuous scan should be found by the incremental scan.
The incremental scan is done only at specific times (once a day, by default). It scans events and address book entries that were modified during the previous day or so, thus it scans a larger range of data than the continuous scan. It may also look for more inconsistencies than the continuous scan. Since it scans more data, and may look for more types of inconsistencies, the incremental scan should be done during off-peak hours.
The full scan is done only on specific days (once a week, by default). It looks for inconsistencies in address book data. The full scan reads the entire contents of user address books, and checks for inconsistencies that cannot be detected by the other scans. The full scan should be scheduled for off peak hours.
The calendar store consistency scan can be configured using the following parameters in the [CWS] section of the $ORACLE_HOME/ocal/misc/unison.ini file:
cscs_continuousenable
cscs_continuousfrequency
cscs_fullenable
cscs_fulltime
cscs_fulltrigger
cscs_incrementalenable
cscs_incrementalfrequency
For more information about the calendar store consistency scan parameters, see "Calendar Server Parameters" in Chapter 3 of Oracle Calendar Reference Manual.
To minimize the impact on your users, back up your calendar server only during periods of low user activity. If you use an external directory server, back up your directory server concurrently with your calendar server to minimize inconsistencies should it become necessary to restore a backup.
You have three options for backing up your calendar server:
Using the unidbbackup utility
Stopping the calendar server and running the uniarch utility
Stopping the calendar server and copying or zipping the database files directly
Oracle recommends the unidbbackup utility, as it provides online or hot backups allowing users to logon during a backup. An online backup cannot be achieved by simply copying the database files while the server is still running, as the files on disk are not necessarily an accurate reflection of the state of the database at any given time. If you choose to copy the database files directly, you must stop your server to allow all database contents to be written to the disk first.
While unidbbackup is running, users can still log in and log out. They may view but not modify their agenda. If more than one node exists on a host, each node is locked and backed up in succession. The -lockall option can be used to lock all the specified nodes at the same time instead of one by one. This will improve the data consistency for connected nodes. The unidbbackup utility can be used to make a backup of a single node using the -n option.
unidbrestore is the complementary utility used for database restoration. For more information about the use and syntax of the unidbbackup and unidbrestore utilities, see "Calendar Server Utilities" in Chapter 6 of Oracle Calendar Reference Manual.
Execute the unidbbackup utility through the command line. A backup will be made of all database and configuration files on your calendar server. If more than one node exists on the host, unidbbackup will back up each node in turn. To make backups of specific nodes only use the -n option. For more information about the unidbbackup utility, see "Calendar Server Utilities" in Chapter 6 of Oracle Calendar Reference Manual.
The destination of the backup is specified using the -d option. It is important to verify that there is sufficient space available in the destination directory.
|
Important: This operation restores only the database and configuration files. Calendar data stored in a directory server must be restored separately. If you have any reason to expect that inconsistencies may exist between the data in the calendar server and that in the directory server, use the |
Shut down the server.
Run unidbrestore to restore the backup. Your calendar database and configuration files will be restored to the $ORACLE_HOME/ocal directory on the host.
|
Note: The unidbrestore utility will overwrite data currently in the Calendar server's$ORACLE_HOME/ocal/db and misc directories, replacing it with the specified backup. |
Archived backups should be managed to ensure full data recovery capabilities without sacrificing large amounts of disk space. Remove backups that are no longer needed. For more information about the unidbrestore utility, see "Calendar Server Utilities" in Chapter 6 of Oracle Calendar Reference Manual.
It is possible to restore a single user through the Oracle Calendar administrator or using the unirestore utility. The restore is done using the backup files made using the unidbbackup utility.
Oracle Calendar Administrator
Use the Calendar Administrator to restore a user account.
Click the Server Administration tab.
Click on the Nodes secondary tab.
Click the Pencil icon in the Actions column for the node where you will restore the calendar account.
Click Restore Calendars.
Enter the path to the backup file and select the type of calendar account you are restoring (user, resource or event calendar).
Click Apply to continue.
Search for the user, resource, or event calendar to be restored.
Select the user, and click Apply.
Command Line
Use unirestore to restore a calendar account. Use the -path option to specify the path to the directory containing the backup db directory. Use the -u option to specify the UID of the user to be restored.
For example:
% unirestore -u "smithj" -path "/backups/cserver/jan0799" -noAddAttendee -host hubert3 -n 10
For more information about the use and syntax of the unirestore utility, see "Calendar Server Utilities" in Chapter 6 of Oracle Calendar Reference Manual.
To view a log file, go to the $ORACLE_HOME/ocal/log directory and open the file using a text editor. Note that log files for utilities are created the first time the utility is has encountered an error. Table 14-1 shows a list of different log files, and provides a description of the information logged in each file.
Table 14-1 Calendar Server Log Files
| Filename | Description |
|---|---|
|
|
Tracks calendar usage and monitors possible security violations. To track all sign-ons and sign-offs, set the |
|
|
For the Oracle Calendar Server Manager. |
|
|
For the Corporate-Wide Services. Set the |
|
|
For the Directory Access Server. |
|
|
For Directory Access Server statistics. |
|
|
For node (database) initialization. |
|
|
Database operation file. Created only if there is a problem. |
|
|
For directory server (LDAP) calls. |
|
|
For the Engine. |
|
|
For the Lock Manager. |
|
|
For the Oracle Calendar Administrator. The |
|
|
For all UNIX utilities. |
|
|
For the Synchronous Network Connections. |
|
|
Tracks CPU consumption, user wait times, and network traffic for calendar server user sessions. Session statistics are output once a client session is terminated normally. To enable this logging, set the |
|
|
For various utilities that create and update self-named log files when they are run. |
Much of the content of the calendar server log files is self-explanatory, namely the sections referring to the status of the various daemons/servers. For more information about error code categories, see "Calendar Server Error Codes" in Appendix A of Oracle Calendar Reference Manual. Form more information about calendar server error codes, see "Calendar Server Error Codes" in Appendix B of Oracle Calendar Reference Manual.
Interpreting other sections may require the knowledge and resources of a qualified Oracle Support Analyst. If you are uncertain about the content of a log file, use Oracle MetaLink to search for log file information or to log a Technical Assistance Request (TAR) online.
Log files in the $ORACLE_HOME/ocal/log directory can grow rapidly over time. You can help manage the size and age of these logs using the log rotation feature. If this feature is not enabled on your Oracle Calendar server, you can turn it on by setting the value of the [LOG] rotation_enable parameter to TRUE in the $ORACLE_HOME/ocal/misc/unison.ini file.
|
NOTE: Configurable parameters that control log rotation and attic maintenance can be found in the |
The log rotation feature has two tasks:
Periodically rotating log files from the $ORACLE_HOME/ocal/log directory to the $ORACLE_HOME/ocal/log/attic directory -- known as the attic.
Periodically removing logs from the attic, by deleting stale log files from the $ORACLE_HOME/ocal/log/attic directory
Configuring Log Rotation
Two criteria can trigger a log rotation: size and age. When a log file meets these criteria, it is moved to the $ORACLE_HOME/ocal/log/attic directory. During the rotation process, the log file is renamed according to the following convention: <log name>.YYYYMMDDHHMMSS. In this convention, YYYYMMDDHHSMMSS represents the year, month, day, and time the file was moved to the attic.
For example: If the $ORACLE_HOME/ocal/log/eng.log exceeds the maximum allowable 10-megabyte default value, it will be moved to the attic directory, and will be renamed to:
eng.log.20050217050000
Configuring Attic Maintenance
As with the configurable log rotation, attic maintenance is also based on age and size. By default, log files older than 120 days will be deleted from the $ORACLE_HOME/ocal/log/attic directory. Moreover, if the attic directory exceeds the configurable default size of 200 Megabytes, log files will be deleted from the directory based on their age. The oldest log file being deleted first, based on the log file's time stamp.
