In this section: |
The Workspace Manager is the component of the Reporting Server that is responsible for managing all server administrative tasks. These tasks, generally performed by Server Administrators, include monitoring server activity, configuring and adjusting the server configuration profile, adding users, enabling and creating services, defining deferred execution characteristics, and enabling and disabling email alerts.
The Server Administrator responsible for the installation, configuration, security, and maintenance of the server uses the Web Console to manage and configure the Workspace Manager in order to keep the server available to clients and running at peak efficiency. To use the Web Console, open Internet Explorer and navigate to the HTTP port on the host machine where the Server is running, as in http://host:http_port.
Your Server must be running in order to use Web Console to access the Workspace Manager.
Tip: This chapter references a number of Workspace related keywords. Within the help system, you can access detailed information about these keywords by clicking the keyword links in this document. You can also click the question mark (?) icon next to parameters on the Workspace configuration panes.
Access to the administrative features of the Web Console can be restricted by defining a list of users with admin privileges and storing the list in a release-independent file called admin.cfg. This file is located, by default, in .../ibi/profiles.
The list of users and user roles defined in admin.cfg defines a list of administrators and users that can be used for authorization and/or authentication according to established security. Administrators are responsible for installing, configuring, and maintaining the Server with varying degrees of responsibility, depending on their administration levels (SRV, APP, OPR). At least one administrator must be defined in the list, although most sites identify other persons to act as backups.
For example, a Server Administrator (SRV) can perform all the administrative tasks available through Web Console operations. If more than one Server Administrator is defined, the first valid member on the list is used to impersonate FOCUS Database Server (FDS) and other special services. An Application Administrator (APP) is limited to the administrative tasks that do not require changing configuration or restarting the server. Both Server Administrators and Application Administrators can edit user profiles in the user.prf file. However, Server Administrators can edit all user.prf files, while Application Administrators can only edit their own profiles.
Any IDs (beyond the original ID used to configure the server) that are used for server or application administration require read/write privileges to the respective locations that the IDs are expected to manage. To assign these privileges, you must establish group rights for the locations at the operating system level. To view and run Resource Governor procedures, for example, IDs must be at least at the Application Administrator level.
How to: |
A server administrator can change the server state to quiesce to disable new connections. Existing connections are not terminated, but will finish processing and disconnect, while new connections will be rejected. A server administrator can still connect to the server. This is done to gradually move the server to the state where maintenance can be performed safely or to collect diagnostic information. It can also be used as the first step before stopping the server without terminating any connections.
A server administrator can enter a custom message that will be displayed for a new user connection when the server is in Quiesce mode.
Only a server administrator can change the server state. To Quiesce the server, and define a custom message that will be delivered from the server:
The Quiesce Connections page opens.
You will be asked if you want to disable new connections.
Note: To restore the server to normal operation, click the Console icon, and select Enable New Connections.
How to: Reference: |
A server configuration requires at least one agent service with the name DEFAULT, defined by a SERVICE block. An agent service is an entity used to define the parameters for a group of data access agents, so that a configuration can manage different groups of data access agents for different purposes. Each data access agent runs for a specific Data Service, and each service may have different values for the settings defined on the services configuration panes. These settings include:
The service agents are available from the Workspace folder.
The properties page for the particular Data Service opens.
The server includes four predefined Data Services:
The following image shows the parameters for the DEFAULT service.
Note: Changing values with an asterisk (*) requires restarting the server.
Data Services have the following parameters:
Defines the name of the service.
Defines the maximum number of data access agents that the Workspace Manager will allow to run simultaneously for a specific service.
Defines the number of data access agents that the Workspace Manager will create at startup for a specific service.
Controls resource sharing between users who are connecting to the same agent in this service. The values are:
Controls whether queuing is on or off.
Defines the maximum number of connections that could be queued for a specific service. Only available when queuing is set to on. Set to -1 for an unlimited queue size.
Defines the amount of time in seconds a queued connection will wait before being timed out if an agent is still unavailable. A setting of -1 mean unlimited.
Defines the time limit in seconds that connected agents will wait for client input before they are disconnected. A setting of -1 mean unlimited.
Defines the time limit in seconds that disconnected agents in excess of number_ready can stay idle before they are killed. A setting of -1 mean unlimited.
Specifies a focexec file that will be executed during agent startup.
Defines the amount of CPU time in seconds an agent is allowed to use before being killed by the Workspace Manager.
Defines the maximum amount of memory in kilobytes an agent is allowed to use. If an agent process grows above this limit, it will be killed by the Workspace Manager.
Defines the maximum amount of disk space in kilobytes an agent is allowed to use. This would add sizes of all files in agent edatemp directory, such as FOCSORT, HOLD files and other temporary files created by requests. If an agent process grows above this limit, it will be killed by the Workspace Manager.
Defines the time limit in seconds allowed for connection. When it is exceeded, the connection will be terminated, and the agent serving this connection will be stopped.
Restricts the number of concurrent connections for the same userid for a specific service. When a user exceeds the maximum number allowed, additional connections requested by that user are rejected, and the server displays the message
Connection refused due to the max_connections_per_user (n)
being exceeded
where n is the number of allowed connections.
You have the option to queue user connections that are refused by the server, using the queue_max_user_conns property on the Data Service Properties page. That option is available only if the Queuing property for the Data Service is On.
Enables queuing of concurrent connections for the same userid for a specific service in excess of max_connections_per_user. This setting allows new connections that would otherwise be rejected to be queued for later processing. Only available when queuing is set to on.
Defines the maximum number of new connections which can be accepted during the life of each agent process. Beyond this limit, additional new connections will be assigned to a fresh agent. Agent processes which have reached the limit will be terminated when the last accepted session disconnects.
Defines the scheduling priority of each agent process running under the specified service entry. The scheduling priority of a process defines how the operating system scheduler treats the process after it gains control of the CPU, and should be set according to the relative importance of the work being done by the service. Values range from -20 (highest priority) to 20 (lowest priority).
How to: |
The deployment mode of a service defines how data access agents are assigned to connections:
With security set to a value other than OFF, authentication is processed for every client logging on to the server. With security OFF, user identification and authentication are not required. The effective user ID becomes the connecting user for the duration of the session.
With security set to a value other than OFF, all users have the same rights because the effective pooled user is unique, regardless of the connecting user.
Connection pooled deployment provides significant performance advantages and is recommended when a large number of users share the same operating system and DBMS credentials. It cannot be used when each connecting user has specific operating system and DBMS rights, nor can it be used for the service DEFAULT with the server security mode set to DBMS because, in this situation, the profile is disabled for connection authentication.
To set the server configuration parameter deployment:
The New Data Service page opens.
Tip: For an existing service (for example, DEFAULT, WC_DEFAULT, DMC_DEFAULT, DEFAULT_CPOOL), right-click the service and choose Properties from the menu to open the Services pane.
With security set to a value other than OFF, the effective user ID is switched to the connecting user for the duration of the connection.
Skip to step 6.
When you select this option, pooled_user and pooled_password are displayed.
With security set to a value other than OFF, all users have the same rights because the effective user is unique (configured using pooled_user and pooled_password) regardless of the connecting user.
Continue with steps 4 and 5.
This service level keyword is required for connection_pooling deployment with security mode OPSYS. It defines the user ID under which all agents will run. The DBMS user IDs are determined by the connection setting type.
Advanced parameters have been added for multiple cluster nodes. The parameters include:
These parameters work on the cluster node level and override the values defined in the CLM node.
iWay Software |