| Oracle® Collaboration Suite Administrator's Guide 10g Release 1 (10.1.1) for Windows or UNIX Part Number B14476-03 |
|
|
View PDF |
| Oracle® Collaboration Suite Administrator's Guide 10g Release 1 (10.1.1) for Windows or UNIX Part Number B14476-03 |
|
|
View PDF |
This chapter describes how to manage the Oracle Collaboration Suite Database. Oracle Collaboration Suite uses one or more Oracle Database 10g databases to store messages, files, and other data for users.
Generally, a single Oracle Collaboration Suite Database resides on the same computer hosting the Infrastructure, in a separate Oracle Home. Other configuration options include separating the OracleAS Metadata Repository, the Oracle Internet Directory 10g, or application data into one or more distributed databases hosted on separate computers.
You should be sure you have a good understanding of the architecture of your specific Oracle Collaboration Suite deployment, so that you can apply a comprehensive database management methodology.
Note:
In addition to the Oracle Collaboration Suite Database, Oracle Calendar uses its own separate database to store Calendar information. The Oracle Calendar database periodically synchronizes user information with the Oracle Internet Directory. You can force this synchronization using the UNIDSSYNC utility. See "UNIDSSYNC" in Chapter 6 of Oracle Calendar Reference ManualFor more information about maintaining the Oracle Calendar database, see "Server Maintenance Procedures" in Chapter 14 of Oracle Calendar Administrator's Guide
This chapter contains the following sections:
SQL Statements and Other Management Tools: SQL*Plus and iSQL*Plus
Starting and Stopping the Oracle Collaboration Suite Database
When you install Oracle Collaboration Suite, the Oracle Universal Installer also installs the Database Control Console. The Web-based Database Control serves as the primary tool for managing your Oracle database and sets a new standard in ease-of-use.
If you have installed and deployed Oracle Enterprise Manager 10g Grid Control, you can also use the Grid Control Console to manage the Oracle Collaboration Suite Database.
The following topics introduce you to the Database Control:
From the Database Control Console, you can perform administrative tasks such as creating schema objects (tablespaces, tables, and indexes), managing user security, backing up and recovering your database, and importing and exporting data. You can also view performance and status information about your database instance.
You can access context sensitive online Help by clicking Help displayed on every page. In addition to viewing the help specific to the task at hand, there is a View Contents link that takes you to top level Help where you can view a table of contents and link to topics. A search facility enables you to search the contents of Help.
Navigational features of Oracle Enterprise Manager include the following:
Property pages on each home page help you organize management tasks into distinct categories; for example, click Maintenance to perform tasks associated with backing up and maintaining your data.
Figure 6-1 Database Home Page Navigational Property Pages
Drill down links that provide increasing levels of detail.
Figure 6-2 Database Home Page Drill Down Link
Clicking the 100 link shown in Figure 6-2 provides additional levels of detail about the database's availability.
Suggested related links for more information.
Figure 6-3 Database Home Page Related Links
To access the Database Control Console from a client browser, the dbconsole process needs to be running on the server. This process is automatically started after installation.
However, if the process is not running because of a system restart or other event, you can manually start it at the command line.
To start the dbconsole process:
Navigate into your Oracle Collaboration Suite Database $ORACLE_HOME/bin directory
Run the following statement:
./emctl start dbconsole
Additionally, you can stop the process and view its status.
To stop the dbconsole process:
./emctl stop dbconsole
To view the status of the dbconsole process:
./emctl status dbconsole
In Windows, in addition to using the command line, you can start the dbconsole process as a service.
To start dbconsole as a service:
Click Start->Control Panel->Administrative Tools->Services. The Services page appears.
Oracle services begin with Oracle. The dbconsole service is listed as Oracle<oracle_home><SID>DBConsole. The status of this process is listed in the Status column, either Started or Stopped. Double click the service. The property page appears.
In the properties page, ensure that the Startup Type is either Manual or Automatic and not Disabled. Click Start, if the process is not already started. Click OK.
You can also use the Services page to stop the process.
At the end of a successful database creation, Database Control is automatically launched and the database is started. At other times, provided the dbconsole process is running on the server, you can navigate to your Database Control from your client browser as follows:
Point your Web browser to the following URL:
http://hostname:portnumber/em
For example, if you installed the database on a host computer named comp42, and the installer indicated that your Database Control Console HTTP port number is 5500 (also recorded in the $ORACLE_HOME/install/portlist.ini file), enter the following URL:
http://comp42:5500/em
If the database is up, Enterprise Manager displays the Database Control Login page.
If the database is down and needs to be re-started, Enterprise Manager displays the Startup/Shutdown and Perform Recovery page. If this is the case, click Startup/Shutdown. You are then prompted for the host and target database login user names and passwords, which you must enter. For the database user and password, use SYS and the password you specified during installation.
Click OK to start the database. In the Confirmation screen, click YES to start the database in open mode.
Log in to the database using a username that is authorized to access the Database Control. This initially could be SYS or SYSTEM. Use the password you specified for the account during the database installation.
Enterprise Manager displays the Database Home page (Figure 6-4).
The property pages across the top of the page enable you to access performance, administration, and maintenance pages for managing your database. The functionality provided by these pages is discussed in other chapters of this book.
The various sections of the Database Home page, and related links, provide a wealth of information about the database's environment and health. For example, the Alerts, Related Alerts, and Performance Analysis sections warn you of errors and performance problems that are impacting the operation of your database. You can click the provided links to see more detail about the problem area, and even to obtain recommendations for resolving the problem. For more information, see Chapter 10, "Monitoringand Tuning Oracle Collaboration Suite Performance".
To create new database users or administer existing ones select the Administration property page on the Database Home page (Figure 6-4, "Database Home Page").
From the Database Administration page, under the Security heading, click Users.
The Users page shown in Figure 6-5, "Database Users Page" is displayed. From this page you can view, add, edit, or delete database users.
In this section, you create a user named MYUSER, set the password, and assign MYUSER to the USERS tablespace. This enables MYUSER to log in to the database
Later, you will learn how to edit and assign roles to this user.
To create a database user, do the following as user SYS or SYSTEM:
Click Create on the right hand side of the Users page. The Create Users General page shown in Figure 6-6 is displayed.
The General page is one of a series of pages in the Users property page.
Enter a user Name. For example: MYUSER
Leave Profile set to DEFAULT. The profile specifies the resource limit
Note that this profile does not allow the user to log in to Database Control. To do so, the user needs to be assigned the DBA role.
Leave Authentication set to password. For advanced authentication schemes, see Oracle Database Security Guide.
Enter the password of your choice in the Enter Password and Confirm Password boxes.
Do not check Expire Password now. If the account status to set to expired, then the user or the Database Administrator must change the password before the user can log in to the database.
For the Default Tablespace field, click the browse button (flashlight) and select the USERS tablespace. While users can specify different defaults for each user, it is easiest to define a default permanent tablespace and a default temporary tablespace at the database level, instead of the user level. For more information on the USERS tablespace, see "Some Tablespaces in the Database".
For the Temporary Tablespace field, click the browse button (flashlight) and select the TEMP tablespace. For more information on the TEMP tablespace, see "Some Tablespaces in the Database".
For Status, select Unlocked. Note that you can later lock an account to keep a user out of the database. Locking an account is preferable to deleting a user which deletes all associated tables and data.
Click OK. The Users page is displayed, and you can now see an entry for the new user, MYUSER.
The Users General page has links to several other property pages. For example, you can specify user roles, privileges, quotas, consumer groups, and proxy users. Consumer groups are groups of users, or sessions, that are grouped together based on their processing needs.
|
Note: This section creates a regular database user. If you want to grant the user system administrator privileges, you need to complete additional steps described in "Granting Database ControlAdministrative Privileges" |
See Also:
Oracle Database Administrator's Guide and Oracle Database Security Guide for more information on roles, privileges, quotas, consumer groups and proxy authenticationIf you later want to create other database users similar to user MYUSER, or another existing database user, Oracle provides a shortcut for doing so. On the Users page, you can create a user with the same attributes as another user as follows:
Select the user that you want to duplicate.
From the Actions menu, select Create Like.
Click Go. The Create User General page appears for a new user with the same attributes as the duplicated user.
The Actions box also provides shortcuts for other actions, as well as providing a means to display the SQL DDL used to create a user.
You can change the attributes of database users by clicking Edit on the Users page (Figure 6-5, "Database Users Page") and selecting the properties page with the attributes that you want to change. The following procedure changes the tablespace quotas assigned to user MYUSER.
From the Users page, select MYUSER in the results list, then click Edit. The Edit User General page is displayed.
Click the Quotas property page to display the Quotas page.
You can see that this user has 0 MB quota on all tablespaces. This means that MYUSER has no quota in any tablespace. Since MYUSER belongs to the users tablespace, he must have quota to create tables and other schema objects in this tablespace.
In the Quota column for tablespace users, click the drop-down list and select Value.
In the corresponding Value column, enter 100.
Click Apply.
User MYUSER can now create objects in the users tablespace.
Click the Database property page to return to the Administration home page.
Locked database accounts cannot be accessed by the database user. During installation, you can unlock and reset the Oracle supplied database user accounts. If you did not choose to unlock those accounts at that time, you can do so now as follows:
From the Users page shown inFigure 6-5, "Database Users Page", in the Select column of the table, mark a user whose Account Status is shown as EXPIRED AND LOCKED and that you want to unlock and reset.
From the pull down menu in the Actions pull-down menu, select Unlock User and click Go. Click Yes to the confirm that you want to unlock the user.
This unlocks the user account (the Account Status is now EXPIRED), but does not reset the password. The user still is unable to log in to the database.
From the Users page, again mark the user in the Select column, then click Edit.
The Edit User General page is displayed. You can also display this page for a user by clicking the user name in the UserName column.
Use the General page to change the password for the account. Note that you can also use this page to unlock the account.
You must follow the preceding steps individually for each account that you want to unlock and reset.
Locking an account is similar. You select the user and then choose Lock User from the Actions pull-down menu. Locking an account denies access to the account.
To better understand the ramifications of unlocking and resetting accounts, see the other property pages available on the Edit user page. Specifically, explore the Roles, System Privileges, and Object Privileges property pages to see the privileges of the user whose account you are enabling.
As a system administrator, you can use Database Control to grant roles to database users. For example, you can grant a user the DBA role, which allows the user to administer the database. You can also grant user-created roles.
To grant the DBA role to MYUSER:
From the Administration Page, under the Security heading, click Users.
From the list of users, select MYUSER and click Edit. The Edit User: MYUSER page appears.
In the top navigation bar, click Roles. A page appears with the list of roles for MYUSER.
Click Modify on the right hand side of the page. The Modify Roles page appears.
In the Available Roles list, select the DBA role and click Move to make it part of the Selected Roles list. You can also select the APDEV role you created earlier in this chapter.
Click OK. Then click Apply.
You can also revoke roles from database users. To revoke the DBA role from MYUSER:
From the Administration page, click Users under the Security heading.
From the list of users, select MYUSER and click Edit. The Edit User: MYUSER page appears.
In the top navigation bar, click Roles. A page appears with the list of roles for MYUSER.
Click Modify on the right hand side of the page. The Modify Roles page appears.
In the Available Roles list, select the DBA role and click Remove to make it part of the Available Roles list.
Click OK. Then click Apply.
Database Control enables you to drop users. However, you must exercise caution when doing so, since dropping a database user will drop all schema objects owned by the user including tables and indexes. If you want to deny a database user access to the database, it is better to lock the user account or expire the user password.
To drop a database user such as MYUSER:
From the Administration page, under the Security heading, click Users.
Select the MYUSER user, and click Delete. At the confirmation page, click Yes.
When you log in to the Database Control Console using the SYS or SYSTEM user account, you are logging in as the Oracle Enterprise Manager super user. These are the only accounts that are automatically granted the roles and privileges required to access all the management functionality provided the Database Control.
To grant management access to other database users, use the following procedure:
Start your Web browser and log in to the Database Control as the SYS or SYSTEM database user.
Click Setup at the top of the Database Home page.
Click Administrators in the left navigation bar.
If you need to create a new administrator, you must first create the user and then assign administrative privileges as described in this section. To create a new user, see "Administering Database Users".
Click Create to create a new Enterprise Manager user by assigning the management privileges to an existing database user.
Click the flashlight icon next to the Name field and select an existing database user from the pop-up window.
Enter the password for the selected user and click Finish.
Enterprise Manager assigns the management privileges to the selected user. The selected database user is now included in the list of management users on the Setup Administrators page. All the users shown on this page can log in to the Database Control and perform database management tasks.
Enterprise Manager enables you to set up preferences that help you manage the database. These include the following:
Notification—These are settings that enable Oracle to e-mail you alert notifications. Alerts are notifications of when a database is in an undesirable state and needs your attention. By default, the Database Control Console home page lists all alerts. However, set up is required for e-mail notification. For more information about alerts and setting up notifications, see "Setting up Notification".
Blackout Administration—When you have planned downtime for database maintenance, you can indicate to Oracle that you do not want false alerts to be sent to you. To do so, you define a blackout period. See "Defining Database Alert Blackout Time Periods".
Preferred Credentials—Enterprise Manager can automatically execute many routine administrative tasks, such as backups, on your behalf. This is done using sophisticated job scheduling system built into the Enterprise. To keep your environment secure, setting up tasks for automatic execution in Enterprise Manger requires you to provide login information for the machine and database. To avoid having to enter this information every time you create a job or task, Enterprise Manager enables you to save this information as preferred credentials. Preferred credentials are stored in the database in encrypted mode to protect it from unauthorized use. See "Setting Database Preferred Credentials".
When you plan to bring your database down for maintenance, you can indicate that you do not want alert notifications to be sent to you. Alerts are notifications of when the database is in an undesirable state and needs your attention. For more information about alerts, see "Alerts".
To define a blackout time period, follow these steps
From the Database Control Console home page, click Setup at the top of the page. The Setup page appears.
Click Blackouts in the left hand pane. The Blackouts page appears.
Click Create. This starts the Create Blackout wizard. On the Properties page, name your blackout, and select the target that has planned downtime. Click Next.
On the Schedule page, enter the start time of your planned blackout, or choose immediately if you are bringing the database down now. Also select the duration of the blackout, either as indefinite, as a length or time, or until a time in the future. Under Repeating, accept the default of Do Not Repeat. If you want to repeat the blackout periodically, you can select a repeat frequency in the pull down menu. Click Next.
The review page appears. Review what you have entered, and if satisfied, click Finish. If not, you can click Back to change a setting.
You can have Enterprise Manager automatically fill in host and database login credentials for you, such as when you schedule jobs and tasks to perform administrative operations like backup and recovery. For security, Oracle stores preferred credentials in encrypted mode.
To set preferred credentials for the database, do the following:
From the home page, click Preferences at the top of the page. The Preferences page appears.
Click Preferred Credentials in the left hand pane. The Preferred Credentials page appears. For the Database target, click the icon under Set Credentials. The Database Preferred Credentials page appears.
For your database, enter the credentials for Normal Username/Password, SYSDBA Username/Password, and Host Username/Password.
Click Test to test your credentials. You should get a confirmation message if your credentials can be verified.
Click Apply to apply the changes.
Database Control is a Web-based graphical interface that enables you to perform management operations on the database like startup and shutdown, object creation, and schema management.
When you use Database Control to perform database management tasks, the underlying operations are performed using Structured Query Language (SQL) statements. SQL is an English-like computer programming language for accessing and manipulating data contained in a database. It is an industry-standard language for accessing databases, including those provided by vendors other than Oracle.
The following is an example of a SQL query:
SELECT COUNTRY_ID, COUNTRY_NAME FROM HR.COUNTRIES;
SQL is a powerful language and can be used to perform a variety of database administrative tasks. While performing these tasks, you can click Show SQL to see the underlying SQL statements being issued.
For more details on this language, see Oracle Database SQL Reference.
In addition to Database Control and Grid Control, you can use other Oracle tools to issue SQL statements such as SQL*Plus and its Web version iSQL*Plus. These tools enable you to perform the same database management operations, as well as to query, insert, update or delete data directly in the database.
SQL*Plus is a command line program you use to issue SQL statements to an Oracle database. You can issue these statements interactively or in batch. SQL*Plus comes with your Oracle installation and is located in your Oracle Collaboration Suite Database $ORACLE_HOME/bin directory.
To start SQL*Plus, enter the following at the command line on all platforms:
sqlplus username/password
You can use the SYS administrative user and password you set up during installation. SQL*Plus starts and connects you to the default database. At the SQL prompt, you can enter statements that perform administrative tasks such as database startup and shutdown. You can also query, insert, update and delete data.
On Windows, you can use the SQL*Plus Windows GUI. To start this, select Start->Programs->Oracle-OraHomeName->Application Development->SQL*Plus.
For more information about SQL*Plus, see SQL*Plus User's Guide and Reference.
For more information about SQL statements, see Oracle Database SQL Reference.
iSQL*Plus is the Web version of SQL*Plus. Before you can connect to it with a URL, you must start the iSQL*Plus application server. To do so, enter the following at the command line:
isqlplusctl start
After the server is started, you can connect to iSQL*Plus with a URL such as
http://machine_name:5560/isqlplus
Alternatively, you can connect to iSQL*Plus using Enterprise Manger. To do so from the home page, click iSQL*Plus under Related Links.
For more information about iSQL*Plus, see SQL*Plus User's Guide and Reference.
The Oracle Collaboration Suite Database must be running in order for Oracle Collaboration Suite to operate.
Many typical Oracle Collaboration Suite configurations include a single instance of the Collaboration Suite Database, installed on the Infrastructure tier. In these scenarios, you can start up and shut down the Collaboration Suite Database automatically when you start up or shut down the Infrastructure, by using an automatic script. The most simple method for starting the Collaboration Suite Database manually is also listed in the instructions for manually starting the Infrastructure.
See Also:
To start the Infrastructure and Collaboration Suite Database by using a script, follow the instructions provided in "Starting the Infrastructure Tier".
To stop the Infrastructure and Collaboration Suite Database by using a script, follow the instructions provided in "Stopping the Infrastructure Tier".
In other deployment scenarios, you may be hosting the Collaboration Suite Database on a separate computer, or you may have multiple instances of the Collaboration Suite Database. If you upgraded from a previous version of Oracle Collaboration Suite to Oracle Collaboration Suite 10g Release 1 (10.1.1), your OracleAS Metadata Repository may be in a separate database from the Collaboration Suite Database. In these scenarios, you will have to start and stop your database instances directly (or write a specialized script for your particular environment).
This section describes all of the options for manually starting and stopping the Collaboration Suite Database.
Note:
You can also start and stop the Oracle Collaboration Suite Database using Database Control or Grid Control. For more information about using Database Control, see "Using the Oracle Enterprise Manager 10g Database Control Console".When you start up a database, you create an instance of that database and you determine the state of the database. Normally, you start up an instance by mounting and opening the database. Doing so makes the database available for any valid user to connect to and perform typical data access operations. Other options exist, and these are also discussed in this section.
This section contains the following topics relating to starting up an instance of any Oracle Database 10g:
Preparing to Start an Oracle Collaboration Suite Database Instance
Using SQL*Plus to Start Up an Oracle Collaboration Suite Database
Scenarios for Starting a Oracle Collaboration Suite Database Instance
Options for Shutting Down an Oracle Collaboration Suite Database
Shutting Down an Oracle Collaboration Suite Database with the NORMAL Clause
Shutting Down an Oracle Collaboration Suite Database with the IMMEDIATE Clause
Shutting Down an Oracle Collaboration Suite Database with the TRANSACTIONAL Clause
Shutting Down an Oracle Collaboration Suite Database with the ABORT Clause
You can start up and administer a database instance in several ways, as described in the sections that follow.
You can use Oracle Enterprise Manager Grid Control 10g (Grid Control) to administer your database, including starting it up and shutting it down. Grid Control is a separate Oracle product that combines a GUI console, agents, common services, and tools to provide an integrated and comprehensive systems management platform for managing Oracle products. Grid Control enables you to start a database using a GUI interface, rather than command line operations.
See Also:
Oracle Enterprise Manager Grid Control Installation and Basic Configuration
Oracle Enterprise Manager Managing Oracle Collaboration Suite
You can use the Database Control Console to administer your database, including starting it up and shutting it down. If you are using Grid Control, there is no need to also use Database Control (although you may do so if you want to). The Database Control Console allows you to use a graphical user interface (GUI) to manage the Oracle Collaboration Suite Database.
For more information about using Database Control, see "Using the Oracle Enterprise Manager 10g Database Control Console"
To start up a database using a SQL*Plus session, connect to Oracle Application Server 10g with administrator privileges, and then issue the STARTUP command. Using SQL*Plus in this way is the only method described in detail in this section.
You can also use Recovery Manager (RMAN) to execute STARTUP and SHUTDOWN commands. You may prefer to do this if your are within the RMAN environment and do not want to invoke SQL*Plus.
See Also:
Oracle Database Backup and Recovery Basics for information on starting up the database using RMANYou must perform some preliminary steps before attempting to start an instance of your database using SQL*Plus.
Start SQL*Plus without connecting to the database:
SQLPLUS /NOLOG
Connect to Oracle Collaboration Suite Database as SYSDBA:
CONNECT username/password AS SYSDBA
Now you are connected to the database and ready to start up an instance of your database.
See Also:
SQL*Plus User's Guide and Reference for descriptions and syntax for theCONNECT, STARTUP, and SHUTDOWN commands. These are SQL*Plus commands.You use the SQL*Plus STARTUP command to start up a Oracle Collaboration Suite Database instance. To start an instance, the database must read instance configuration parameters (the initialization parameters) from either a server parameter file or a traditional text initialization parameter file.
When you issue the STARTUP command, by default, the database reads the initialization parameters from a server parameter file (SPFILE) in a platform-specific default location. When you install Oracle Collaboration Suite, the server parameter file is automatically created. If you wish to use a traditional text parameter file instead, you must specify the PFILE clause of the STARTUP command to identify the initialization parameter file.
Note:
For UNIX, the platform-specific default location (directory) for the server parameter file (or text initialization parameter file) is:ORACLE_HOME/dbs
For Windows the location is:
ORACLE_HOME\database
In the platform-specific default location, Oracle Database locates your initialization parameter file by examining filenames in the following order:
spfile$ORACLE_SID.ora
spfile.ora
init$ORACLE_SID.ora
Note:
Thespfile.ora file is included in this search path because in a Real Application Clusters environment one server parameter file is used to store the initialization parameter settings for all instances. There is no instance-specific location for storing a server parameter file.
For more information about the server parameter file for a Real Application Clusters environment, see Oracle Database Oracle Clusterware and Oracle Real Application Clusters Administration and Deployment Guide.
You can direct the database to read initialization parameters from a traditional text initialization parameter file, by using the PFILE clause of the STARTUP command. For example:
STARTUP PFILE = /u01/oracle/dbs/init.ora
It is not usually necessary to start an instance with a non-default server parameter file. However, should such a need arise, you can use this PFILE clause to start an instance with a non-default server parameter file as follows:
Create a one-line text initialization parameter file that contains only the SPFILE parameter. The value of the parameter is the non-default server parameter file location.
For example, create a text initialization parameter file /u01/oracle/dbs/spf_init.ora that contains only the following parameter:
SPFILE = /u01/oracle/dbs/test_spfile.ora
Note:
You cannot use theIFILE initialization parameter within a text initialization parameter file to point to a server parameter file. In this context, you must use the SPFILE initialization parameter.Start up the instance pointing to this initialization parameter file.
STARTUP PFILE = /u01/oracle/dbs/spf_init.ora
The server parameter file must reside on the machine running the database server. Therefore, the preceding method also provides a means for a client machine to start a database that uses a server parameter file. It also eliminates the need for a client machine to maintain a client-side initialization parameter file. When the client machine reads the initialization parameter file containing the SPFILE parameter, it passes the value to the server where the specified server parameter file is read.
You can start an instance in various modes:
Start the instance without mounting a database. This does not allow access to the database and usually would be done only for database creation or the re-creation of control files.
Start the instance and mount the database, but leave it closed. This state allows for certain DBA activities, but does not allow general access to the database.
Start the instance, and mount and open the database. This can be done in unrestricted mode, allowing access to all users, or in restricted mode, allowing access for database administrators only.
Note:
You cannot start a database instance if you are connected to the database through a shared server process.In addition, you can force the instance to start, or start the instance and have complete media recovery begin immediately. The STARTUP command clauses that you specify to achieve these states are described in "Scenarios for Starting a Oracle Collaboration Suite Database Instance".
The following scenarios describe and illustrate the various states in which you can start up a Oracle Collaboration Suite Database instance. Some restrictions apply when combining clauses of the STARTUP command.
Note:
It is possible to encounter problems starting up an instance if control files, database files, or redo log files are not available. If one or more of the files specified by theCONTROL_FILES initialization parameter does not exist or cannot be opened when you attempt to mount a database, Oracle Database returns a warning message and does not mount the database. If one or more of the datafiles or redo log files is not available or cannot be opened when attempting to open a database, the database returns a warning message and does not open the database.See Also:
SQL*Plus User's Guide and Reference for information about the restrictions that apply when combining clauses of theSTARTUP commandNormal database operation means that an instance is started and the database is mounted and open. This mode allows any valid user to connect to the database and perform typical data access operations.
Start an instance, read the initialization parameters from the default server parameter file location, and then mount and open the database by using the STARTUP command by itself (you can, of course, optionally specify the PFILE clause):
STARTUP
You can start an instance without mounting a database. Typically, you do so only during database creation.
Note:
Generally, you should use the Oracle Universal Installer from the Oracle Collaboration Suite CD to create Oracle Collaboration Suite Database instances, rather than creating them manually. The Oracle Universal Installer will create an Oracle Database instance, and seed it with all of the necessary Oracle Collaboration Suite schemas, automatically.For more information about creating Oracle Collaboration Suite Database instances, see the Oracle Collaboration Suite Installation Guide for Microsoft Windows or Oracle Collaboration Suite Installation Guide for Solaris Operating System.
Use the STARTUP command with the NOMOUNT clause:
STARTUP NOMOUNT
You can start an instance and mount a database without opening it, allowing you to perform specific maintenance operations. For example, the database must be mounted but not open during the following tasks:
Enabling and disabling redo log archiving options. For more information, see "Redo Log Files"
Performing full database recovery. For more information, see Oracle Database Backup and Recovery Basics
Start an instance and mount the database, but leave it closed by using the STARTUP command with the MOUNT clause:
STARTUP MOUNT
You can start an instance, and optionally mount and open a database, in restricted mode so that the instance is available only to administrative personnel (not general database users). Use this mode of instance startup when you need to accomplish one of the following tasks:
Perform an export or import of database data
Perform a data load (with SQL*Loader)
Temporarily prevent typical users from using data
Perform certain migration and upgrade operations
Typically, all users with the CREATE SESSION system privilege can connect to an open database. Opening a database in restricted mode allows database access only to users with both the CREATE SESSION and RESTRICTED SESSION system privilege. Only database administrators should have the RESTRICTED SESSION system privilege. Further, when the instance is in restricted mode, a Database Administrator cannot access the instance remotely through an Oracle Net listener, but can only access the instance locally from the machine that the instance is running on.
Start an instance (and, optionally, mount and open the database) in restricted mode by using the STARTUP command with the RESTRICT clause:
STARTUP RESTRICT
Later, use the ALTER SYSTEM statement to disable the RESTRICTED SESSION feature:
ALTER SYSTEM DISABLE RESTRICTED SESSION;
If you open the database in nonrestricted mode and later find you need to restrict access, you can use the ALTER SYSTEM statement to do so, as described in "Restricting Access to an Open Database".
In unusual circumstances, you might experience problems when attempting to start a database instance. You should not force a database to start unless you are faced with the following:
You cannot shut down the current instance with the SHUTDOWN NORMAL, SHUTDOWN IMMEDIATE, or SHUTDOWN TRANSACTIONAL commands.
You experience problems when starting an instance.
If one of these situations arises, you can usually solve the problem by starting a new instance (and optionally mounting and opening the database) using the STARTUP command with the FORCE clause:
STARTUP FORCE
If an instance is running, STARTUP FORCE shuts it down with mode ABORT before restarting it.
See Also:
"Shutting Down an Oracle Collaboration Suite Database with the ABORT Clause" to understand the side effects of aborting the current instanceIf you know that media recovery is required, you can start an instance, mount a database to the instance, and have the recovery process automatically start by using the STARTUP command with the RECOVER clause:
STARTUP OPEN RECOVER
If you attempt to perform recovery when no recovery is required, Oracle Database issues an error message.
Many sites use procedures to enable automatic startup of one or more Oracle Database instances immediately following a system start. The procedures for performing this task are specific to each operating system. For information about automatic startup, see your operating system specific Oracle documentation.
You can alter the availability of a database. You may want to do this in order to restrict access for maintenance reasons or to make the database read only. The following sections explain how to alter the availability of a database:
When you need to perform specific administrative operations, the database must be started and mounted to an instance, but closed. You can achieve this scenario by starting the instance and mounting the database.
To mount a database to a previously started, but not opened instance, use the SQL statement ALTER DATABASE with the MOUNT clause as follows:
ALTER DATABASE MOUNT;
See Also:
"Starting an Instance and Mounting a Database" for a list of operations that require the database to be mounted and closed (and procedures to start an instance and mount a database in one step)You can make a mounted but closed database available for general use by opening the database. To open a mounted database, use the ALTER DATABASE statement with the OPEN clause:
ALTER DATABASE OPEN;
After executing this statement, any valid Oracle9i Application Server user with the CREATE SESSION system privilege can connect to the database.
Opening a database in read-only mode enables you to query an open database while eliminating any potential for online data content changes. While opening a database in read-only mode guarantees that datafile and redo log files are not written to, it does not restrict database recovery or operations that change the state of the database without generating redo. For example, you can take datafiles offline or bring them online since these operations do not affect data content.
If a query against a database in read-only mode uses temporary tablespace, for example to do disk sorts, then the issuer of the query must have a locally managed tablespace assigned as the default temporary tablespace. Otherwise, the query will fail.
Ideally, you open a database in read-only mode when you alternate a standby database between read-only and recovery mode. Be aware that these are mutually exclusive modes.
The following statement opens a database in read-only mode:
ALTER DATABASE OPEN READ ONLY;
You can also open a database in read/write mode as follows:
ALTER DATABASE OPEN READ WRITE;
However, read/write is the default mode.
Note:
You cannot use theRESETLOGS clause with a READ ONLY clause.To place an instance in restricted mode, where only users with administrative privileges can access it, use the SQL statement ALTER SYSTEM with the ENABLE RESTRICTED SESSION clause. After placing an instance in restricted mode, you should consider killing all current user sessions before performing any administrative tasks.
To lift an instance from restricted mode, use ALTER SYSTEM with the DISABLE RESTRICTED SESSION clause.
See Also:
Oracle Database Administrator's Guide for directions for killing user sessions
"Restricting Access to an Instance at Startup" to learn some reasons for placing an instance in restricted mode
You can shut down an instance of your database in several ways, as described in the sections that follow.
You can use Grid Control to administer your database, including starting it up and shutting it down. Grid Control is a separate Oracle product that combines a GUI console, agents, common services, and tools to provide an integrated and comprehensive systems management platform for managing Oracle products. Grid Control enables you to start a database using a GUI interface, rather than command line operations.
You can use the Database Control Console to administer your database, including starting it up and shutting it down. If you are using Grid Control, there is no need to also use Database Control (although you may do so if you want to). The Database Control Console allows you to use a GUID interface to manage the Oracle Collaboration Suite Database.
For more information about using Database Control, see "Using the Oracle Enterprise Manager 10g Database Control Console"
You can also use Recovery Manager (RMAN) to execute STARTUP and SHUTDOWN commands. You may prefer to do this if your are within the RMAN environment and do not want to invoke SQL*Plus.
See Also:
Oracle Database Backup and Recovery Basics for information on starting up the database using RMANYou can start a SQL*Plus session, connect to Oracle Database with administrator privileges, and then issue the SHUTDOWN command. Using SQL*Plus in this way is the only method described in detail in this section.
To initiate database shutdown, use the SQL*Plus SHUTDOWN command. Control is not returned to the session that initiates a database shutdown until shutdown is complete. Users who attempt connections while a shutdown is in progress receive a message like the following:
ORA-01090: shutdown in progress - connection is not permitted
Note:
You cannot shut down a database if you are connected to the database through a shared server process.To shut down a database and instance, you must first connect as SYSOPER or SYSDBA. There are several modes for shutting down a database. These are discussed in the following sections.
To shut down a database in normal situations, first connect as SYSOPER or SYSDBA. Then use the SHUTDOWN command with the NORMAL clause:
SHUTDOWN NORMAL
Normal database shutdown proceeds with the following conditions:
No new connections are allowed after the statement is issued.
Before the database is shut down, the database waits for all currently connected users to disconnect from the database.
The next startup of the database will not require any instance recovery procedures.
Use immediate database shutdown only in the following situations:
To initiate an automated and unattended backup
When a power shutdown is going to occur soon
When the database or one of its applications is functioning irregularly and you cannot contact users to ask them to log off or they are unable to log off
To shut down a database immediately, first connect as SYSOPER or SYSDBA. Then use the SHUTDOWN command with the IMMEDIATE clause:
SHUTDOWN IMMEDIATE
Immediate database shutdown proceeds with the following conditions:
No new connections are allowed, nor are new transactions allowed to be started, after the statement is issued.
Any uncommitted transactions are rolled back. (If long uncommitted transactions exist, this method of shutdown might not complete quickly, despite its name.)
Oracle Database does not wait for users currently connected to the database to disconnect. The database implicitly rolls back active transactions and disconnects all connected users.
The next startup of the database will not require any instance recovery procedures.
When you want to perform a planned shutdown of an instance while allowing active transactions to complete first, first connect as SYSOPER or SYSDBA. Then use the SHUTDOWN command with the TRANSACTIONAL clause:
SHUTDOWN TRANSACTIONAL
Transactional database shutdown proceeds with the following conditions:
No new connections are allowed, nor are new transactions allowed to be started, after the statement is issued.
After all transactions have completed, any client still connected to the instance is disconnected.
At this point, the instance shuts down just as it would when a SHUTDOWN IMMEDIATE statement is submitted.
The next startup of the database will not require any instance recovery procedures.
A transactional shutdown prevents clients from losing work, and at the same time, does not require all users to log off.
You can shut down a database instantaneously by aborting the database instance. If possible, perform this type of shutdown only in the following situations:
The database or one of its applications is functioning irregularly and none of the other types of shutdown works.
You need to shut down the database instantaneously (for example, if you know a power shutdown is going to occur in one minute).
You experience problems when starting a database instance.
When you must do a database shutdown by aborting transactions and user connections, first connect as SYSOPER or SYSDBA. Then issue the SHUTDOWN command with the ABORT clause:
SHUTDOWN ABORT
An aborted database shutdown proceeds with the following conditions:
No new connections are allowed, nor are new transactions allowed to be started, after the statement is issued.
Current client SQL statements being processed by Oracle Database are immediately terminated.
Uncommitted transactions are not rolled back.
Oracle Database does not wait for users currently connected to the database to disconnect. The database implicitly disconnects all connected users.
The next startup of the database will require instance recovery procedures.
The listener runs on your database server machine and brokers incoming client requests. With the Database Control Console, you can view the status of the listener.
To view the status of the listener, navigate to the Oracle Collaboration Suite Database home page. Under General, click Listener. The Listener: listener_name page appears. Under General, note the listener status, which is either Up or Down.
This page also gives the listener version, its net address, and start time.
You can additionally view the listener status at the command line using
lsnrctl status
You can start and stop the Oracle listener at the command line. To start the listener, use the following:
lsnrctl start
You can also stop it at the command line using the following:
lsnrctl stop
You can use the Database Control Console to stop the listener. To do so, navigate to the Listener: listener_name page by clicking Listener on the Oracle Collaboration Suite Database Home page. To shut down the listener, click Stop.
This section discusses using the Database Control Console to explore and manage the storage structures of your database. This section contains the following topics:
An Oracle database is comprised of physical and logical structures, which you, as a DBA, are responsible for managing. Physical structures are those that can be seen and operated upon from the operating system, such as the physical files that store data on disk.
Logical structures are created and recognized by the Oracle database server, and are not known to the operating system. The primary logical structure in a database, a tablespace, contains physical files. The applications developer or end user may be aware of the logical structure, but is not usually aware of this physical structure. The DBA must understand the correlation between the physical and logical structures of a database and control the mapping of the logical structure of the database to the physical structure.
Oracle has functionality within the database server to automate the management of its structure. Further, the Database Control Console provides a Web-based graphical user interface to enable easy management and monitoring of your database.
You view database storage structure by clicking the links shown under the Storage heading on the Administration Home page (see Figure 6-8, "Database Administration Page"). Figure 6-7, "Storage Options" shows these links.
The following sections provide a closer look at the database storage structure:
A control file tracks the physical components of the database and other control information. It is essential to the functioning of the database. Because of this, Oracle recommends that the control file be multiplexed. In other words, it should have multiple identical copies. For databases created using DBCA, three copies of the control file are automatically created.
If any control file fails, then your database becomes unavailable. But as long as you still have any of the control file copies intact, you can shut down your database and re-create the failed control file from one of the other control files, then restart your database. Another option is to delete the failed control file from the CONTROL_FILES initialization parameter and restart your database with the remaining control files. There are other options, depending upon circumstances. See Oracle Database Administrator's Guide for detailed information about control files.
Click the Controlfiles link. The Controlfiles General page shows that your database has a multiplexed control file. There are two other property pages, in addition to the General page, for viewing control file information. The Advanced and Record Section pages give you more detailed information about your control file. Explanations of this information are contained in the online help.
Every Oracle database has a set of two or more redo log files. The set of redo log files is collectively known as the redo log for the database. A redo log is made up of redo entries (also called redo records). The primary function of the redo log is to record all changes made to data. If a failure prevents modified data from being permanently written to the datafiles, then the changes can be obtained from the redo log, so work is never lost. To protect against a failure involving the redo log itself, Oracle allows a multiplexed redo log so that two or more copies of the redo log can be maintained on different disks.
Your database's redo log consists of groups of redo log files. A group consists of a redo log file, and its multiplexed copies. Each identical copy is said to be a member of that group, and each group is defined by a number, such as group 1. The database log writer process writes redo records from the memory buffer to a redo log group until the group fills up, or a log switch operation is requested, then it writes to the next group. This is done in a circular fashion, where the oldest group is overwritten by the most recent redo records.
Click Redo Log Groups. The Redo Log Groups page appears, showing the attributes of the redo log groups for your database. A database typically consists of three groups. Note the status attribute for the redo log groups. The CURRENT status group is the one currently being written to disk by the log writer process.
You can see that each group contains only one member. This is because the database does not have a multiplexed redo log. Select a redo log group and click View to see information about the redo log group members.
While not multiplexing redo log groups is acceptable in a small database environment, you should consider adding multiplexing as your database grows in users and applications. This provides better protection for data in the case of instance or media failure.
To multiplex your redo log, you must add members to each redo log group. This example will add one member to each redo log group. It is not required that redo log groups be symmetrical (all have the same number of members), but in practice it is recommended that this be the case. It is required that a database have a minimum of two redo log groups.
To create a multiplexed redo log for your database, follow these steps:
Navigate to the Redo Log Groups page.
Select a group and click Edit, or click the group number link.
The Edit Redo Log Group page appears.
In the Redo Log Members section, click Add.
The Add Redo Log Member page appears.
Enter the file name. For example, if your existing member file name is REDO01, you might name this member REDO01a. Enter the file directory. Click OK.
You can create this file in the same directory, but it is recommended that you store members on separate drives. That way, if there is a drive failure, you still have access to one member.
Repeat these steps for every existing group.
When you add the redo log member to a group, the group's status is marked INVALID. This is a normal state because there is a member that has not been written to yet. When a log switch occurs, and the invalid group becomes the current group, then its status is marked CURRENT.
To see the status change on a log switch:
Navigate to the Redo Log Groups page.
From the Actions pull down menu, select Switch logfile. Click Go.
You can see that the next groups status changes from INVALID to CURRENT.
When you archive your redo log, you write redo log files to another medium location prior to their being overwritten. This location is called the archive log. You can archive to multiple locations, including a standby database.
These copies of redo log files extend the amount of redo information that can be saved and used for recovery. Archiving can be either enabled or disabled for the database, but Oracle recommends you enable archiving.The status of a log group that is actively being archived is ACTIVE.
Click Archive Logs. The Archive Logs page is displayed. This page lets you view archive log files and their attributes.
For placing the database into archive log mode, or adding archive log locations, see Chapter 11, "Backing Up and Recovering Oracle Collaboration Suite".
In earlier releases of the Oracle database, rollback segments were database structures used to track undo information for the database. Now, Oracle's preferred way of managing undo is with the undo tablespace. For more information, see "Managing Undo for Your Database".
Click Rollback Segments. You see the attributes of the system rollback segment. The system rollback segment is self managing.
A database consists of one or more tablespaces. A tablespace is a logical structure, or container, created by and known only to the Oracle database server in which database objects are stored. A tablespace consists of one or more datafiles or tempfiles.
There are various types of tablespaces, including undo tablespaces, temporary tablespaces, and permanent tablespaces.
A database running in automatic undo management mode transparently creates and manages undo segments. You can create an undo tablespace and determine the maximum retention time for undo data kept in that tablespace.
Temporary tablespaces improve the concurrence of multiple sort operations, reduce their overhead, or avoid Oracle space management operations altogether. Temporary tablespaces are the most efficient tablespaces for disk sorts. Space management (extent allocation and deallocation) is locally managed. After temporary tablespaces, tablespaces of type TEMPORARY are the next best tablespaces to use for sort operations. Space management is dictionary managed. Permanent tablespaces (which are not of type TEMPORARY) are least efficient for performance of disk sorts.
See Also:
Oracle Database Administrator's GuideClick Tablespaces. The Tablespaces page provides high level information about tablespace structure and space usage. You can see how much space is allocated for the tablespace and what portion of it is used. Select a tablespace and click View to see the underlying datafile attributes.
Table 6-1, "Tablespaces and Descriptions" provides a description some of the tablespaces included in the database.
Table 6-1 Tablespaces and Descriptions
| Tablespace | Description |
|---|---|
|
This is an auxiliary tablespace to the Some components and products that prior to Oracle Database 10g used the Components that use this as their default tablespace during installation include Automatic Workload Repository, Oracle Streams, Oracle Text, and Enterprise Manager Repository. For more information, see the Oracle Database Administrator's Guide. |
|
|
The |
|
|
This tablespace stores temporary data generated when processing SQL statements. It would, for example, be used for sort work space. Every database should have a temporary tablespace that is assigned to users as their temporary tablespace. In the preconfigured database, the |
|
|
This is the undo tablespace used by the database server to store undo information. See "Managing Undo for Your Database" to understand Oracle's use of the undo tablespace. Every database must have an undo tablespace that can be created at database creation. |
|
|
This tablespace contains the sample schemas that Oracle includes with the database. The sample schemas provide a common platform for examples. Oracle documentation and educational materials contain examples based on the sample schemas. |
|
|
This tablespace is used to store permanent user objects and data. Like the |
Temporary tablespace groups let users consume temporary space from multiple tablespaces. Using a tablespace group, rather than a single temporary tablespace, can alleviate problems caused when one tablespace is inadequate to hold the results of a sort, particularly on a table that has many partitions. A tablespace group enables parallel execution servers in a single parallel operation to use multiple temporary tablespaces.
You can assign a tablespace group name as a default temporary tablespace for the database or as a temporary tablespace for a user.
Click the Temporary Tablespace Groups link. You see the temporary tablespace groups that are defined for your database. Initially, there are none.
See Also:
Oracle Database Administrator's Guide for details on using tablespace groupsDatafiles are the operating system files that hold the data within the database. The data is written to these files in an Oracle proprietary format that cannot be read by programs other than the database server. Tempfiles are a special class of datafiles that are associated only with temporary tablespaces.
Datafiles can be broken down into the following components:
Segments and extents
A segment contains a specific type of database object. For example, tables are stored in data segments, and indexes are stored in index segments.
An extent is a contiguous set of data blocks within a segment. Oracle initially allocates an extent of a specified size for a segment, but if that extent fills, then more extents can be allocated.
Data block
Data blocks, also called database blocks, are the smallest unit of I/O to database storage. An extent consists of several contiguous data blocks. The default database block size is specified by a DBA at database creation or defaulted by Oracle.
After the database has been created, it is not possible to change the default block size without re-creating the database. However, it is possible to create tablespace with a block size different than the default block size. For details on how to create tablespaces with non-default (or non-standard) block size, see Oracle Database Administrator's Guide.
To view more information about your database datafiles, click Datafiles. Your database datafiles are displayed. Select a datafile and click View to see more attributes for the datafile, or select a tablespace link to see the attributes of the owning tablespace.
Other storage structures that can exist in an Oracle database include the following:
Initialization parameters are used by the database server at startup to determine the runtime resources for the database. They are actively monitored by the database and can be set or modified while the database is running.
Initialization parameters and the initialization parameter file are discussed in "Viewing and Modifying Initialization Parameters".
A database might use a password file to authenticate administrative users who can have SYSDBA connect privileges. SYSDBA connect privileges enable a DBA to start up and shut down the database and perform other high level administrative tasks. This password file is outside of the database itself, because it must sometimes be referenced when the database is not yet running.
This is not the only form of administrator authentication, so not all databases require a password file.
Backup files are technically not database files, but rather copies of the database in some form that can be used to recover the database should a failure causing loss of data occur.
Backup files are discussed in Chapter 11, "Backing Up and Recovering Oracle Collaboration Suite".
The remainder of this section presents examples of some common database administration tasks relating to the storage structure:
You can see all tablespaces in your database. From the Database Control Console Administration page, click Tablespaces under Storage. This takes you to the Tablespaces page.
The Results page shows all tablespaces, including the following information about each: type of tablespace, type of extent management, type of segment management, status, size, and percent used. Click the tablespace name for more information.
With Database Control Console, you can modify a tablespace, such as extend it, set it to automatically extend, change its space thresholds, or change its status to offline. A tablespace might need extending when you get a critical and warning alert. You might need to offline a tablespace to perform recovery operations on it.
This section shows you how to set a tablespace to automatically extend when it reaches its limit. To enable autoextend tablespace, do the following:
From the Database Control Console Administration page, click Tablespaces under Storage. This takes you to the Tablespaces page.
Select a tablespace to autoextend, such as USERS, and click Edit. The Edit Tablespace:USERS General property page appears.
Select the datafile associated with the tablespace, and click Edit. The Edit Datafile page appears.
Check Automatically extend datafile when full (AUTOEXTEND). Set a suitable increment, such as 1 M. You can optionally set a maximum file size or set file size to unlimited depending on your resources.
You can use SQL statements to add datafiles and associate them with a tablespace. You can either specify the file specifications for the datafiles being created, or you can use the Oracle Managed Files feature to create files that are managed by the database server.
You can also use SQL statements to manually resize a datafile. This lets you add space to your database without adding datafiles, if you are concerned about reaching the maximum number of datafiles allowed in your database. Manually reducing the sizes of datafiles lets you reclaim unused space in the database. This is useful for correcting errors in estimates of space requirements. For more information on managing datafiles, see the Oracle Database Administrator's Guide.
Click Continue. This brings you back to the Edit Tablespace page. Click Apply. A confirmation message appears.
Similarly, you can change tablespace thresholds by selecting a tablespace on the Tablespaces page and navigating to the Threshold property page. Here you can alter your space thresholds that generate the warning and critical alerts. For more information about thresholds and alerts, see Chapter 10, "Monitoringand Tuning Oracle Collaboration Suite Performance".
To take a tablespace offline, on the Edit Tablespace page, under Status, select Offline and click Apply.
After a tablespace has been dropped, the objects and data in it will no longer be available. To recover them can be a time consuming process. Oracle recommends performing a backup before and after dropping a tablespace. Oracle Collaboration Suite applications will stop functioning properly if any of their required tablespaces have been dropped.
From the Administration page, click Tablespaces under Storage. This takes you to the Tablespaces page.
Select the tablespace that you want to drop, and click Delete. Enterprise Manager will ask for confirmation that you want to delete the tablespace and associated datafiles from the operating system.
Over time, inserts, updates, and deletes (DML operations) to objects within a tablespace can create pockets of empty space that individually are not big enough to be reused. Collectively these pockets can constitute large amounts of wasted space.
Oracle lets you reclaim wasted space through a shrink operation. In a shrink operation, data is compacted to the front of the table. Free space can either be given back to the tablespace or kept in the table for future inserts. A shrink operation on a table does not affect DML operations to the table during the operation.
The Segment Advisor performs growth trend analysis on individual objects to determine if there will be any additional space left in the object in 7 days. It then uses the reclaim space target to select candidate objects to shrink. The Segment Advisor can be invoked in the comprehensive mode. In this mode, in addition to using the pre-computed statistics in the workload repository, the Segment Advisor samples the objects under consideration to refine the statistics for the objects. Although this operation is more resource intensive, it may be used to perform a more accurate analysis, when desired.
You can run the advisor at the tablespace or object level. To run the advisor from the tablespace level do the following:
From the Database Control Console Administration page under Storage, click Tablespaces. This takes you to the Tablespaces page.
On the Tablespaces page, select a tablespace and select Run Segment Advisor from the Actions menu. Note the used space before the operation for later comparison. Click Go. Note that the Segment Advisor can also be launched from the Advisor Central page.
The Segment Advisor: Advisor Mode page appears. On this page, accept the default Complete Analysis of All Segments (Comprehensive) mode. Click Continue.
The Segment Advisor: Options page appears. Accept Unlimited as the time limit for Analysis. Click Next.
The Segment Advisor: Schedule page appears. Select Standard as the Schedule Type and accept Immediately as the Start time. Otherwise, you can schedule the task to run later. Click Next.
The Segment Advisor: Review page appears summarizing the task and selected objects. Verify that the task will run as you want, and click Submit.
The Advisor Central page appears listing the advisor related tasks that have run. Select the Segment Advisor task that you submitted, and click View Result.
The Segment Advisor Task page appears showing the recommendations for the selected table. To implement one or more recommendations, select the recommendations to implement. This will launch the shrink wizard, which is described in the following section.
Over time, it is common for segment space to become fragmented or for a segment to acquire a lot of free space as the result of update and delete operations. The resulting sparsely populated objects can suffer performance degradation during queries and DML operations.The Segment Advisor provides advice on whether an object has space available for reclamation based on the level of space fragmentation within an object.
Select Shrink Options at the bottom of the page. You can choose to Compact Segments and Release Space, which releases freed space to the tablespace, or you can Compact Segments only. Click Schedule Implementation to run the shrink operation.
The Schedule Implementation page appears. Accept a start time of Immediately, and click Submit.
The scheduler Jobs page appears showing the status of the job. Click Refresh to update the page until the status of the job is Completed. On successful completion, you can navigate back to the Tablespace page and compare the current used space with the previous.
This section discusses undo management which involves storing the changes of database transactions long enough to accommodate rollback, read consistency, and flashback features.
When you install the database, Oracle automatically enables auto-tuning of the undo retention period. (This parameter is discussed in "Undo Tablespace Size and Retention Time" .) Auto-tuning of undo retention enables you to start running Oracle Collaboration Suite without immediately managing undo. Later, as your database activity and transaction rate increase, understanding how to manage undo will become more useful to you.
Undo data stores changes made to the database by transactions. Undo is necessary for the following:
To undo any uncommitted changes made to the database in the event that a rollback operation is necessary. A rollback operation can be the result of a user (application) specifically issuing a rollback statement to undo the changes of a misguided or unintentional transaction, or it can be part of a recovery operation.
To provide read consistency. This means that each user can get a consistent view of data, even while other uncommitted changes may be occurring against the data. For example, if a user issues a query at 10:00 a.m. and the query lasts for 15 minutes, the query results should reflect the entire state of the data at 10:00 a.m. regardless of any updates or inserts by other users during the 15 minute query.
To enable Oracle's flashback features, which enables you to view or recover data to a previous point in time. These features include Flashback Query and Flashback Table.
See Also:
"Recovering Messages with Oracle Flashback Query" in Chapter 10 of Oracle Mail Administrator's GuideIn order for changes to be rolled back or undone, Oracle makes a copy of the original data before modifying it. The original copy of the modified data is called undo data. Undo data is stored in a logical database structure called an undo tablespace.
The undo tablespace is of a finite size. Space usage within the tablespace is such that records can be overwritten. The undo data needs to be saved at least until the transaction has been committed. Until then the undo data is said to be in the active state. The amount of space available in the undo tablespace should, therefore, be at least large enough to hold the active undo data generated by currently active transactions. Otherwise some of these transactions may fail. After the active undo data is stored in the undo tablespace, Oracle automatically ensures that it is never overwritten until the corresponding transaction has been committed.
Even after the transaction has been committed, the undo data still cannot be overwritten immediately. It is important to the success of flashback functionality, and for read consistency for long running transactions, that records not be overwritten too soon. For example, if your longest query takes 15 minutes, the undo tablespace should be big enough to hold 15 minutes worth of undo information.
To control the retention of undo records, Oracle maintains an undo retention period, which in turn affects the size of the undo tablespace; the longer the retention period, the bigger the tablespace. The undo retention period should be at least as long as your longest running query. In addition, if you plan to use flashback features to recover from human errors such as unintentional changes, the undo retention should be set equal to the amount of time in the past you want to go back. For more details on Flashback features, see Oracle Database Administrator's Guide.
Oracle Database automatically determines how long undo data should be preserved after the transaction has been committed based on queries running against the database. During this time, the undo data is said to be in the unexpired state. Oracle will keep the undo data in the unexpired state as long as needed by queries currently running against the database or as long as any low undo retention threshold (whichever is longer). After this time, the state of undo data changes to expired. Undo data is a good candidate for overwriting only when it is in the expired state.
If the undo tablespace does not have adequate free or expired space to store active undo data generated by current transactions, Oracle may be forced to overwrite the unexpired undo data. As this may cause your queries to fail, this is not a desirable situation. In order to avoid this, Oracle recommends you allow the size of the undo tablespace to be automatically increased by enabling auto-extend. See "Extending the Undo Tablespace".
If you cannot enable auto extension for any reason and choose to adjust the size of the undo tablespace manually, Oracle Database includes an undo advisor to help you determine the optimal size. See "Using the Undo Advisor".
With Database Control, you can access the Undo Management page from the database Administration page by selecting Undo Management under the Instance heading.
You can use the Undo Management page to view undo configuration, including the auto-tuned undo retention period, the low threshold retention period, and the name and size of the undo tablespace. Auto-tuning of undo retention cannot be disabled.
You can also use this page to set the low threshold retention or to extend your tablespace. While Oracle automatically tunes the undo retention period, low threshold undo retention lets you define the floor value under which Oracle should never bring down the undo retention. When Oracle Collaboration Suite Database is installed, the low threshold undo retention is set to a default value. You may need to alter this value only when you need to build a recovery strategy using Flashback Query.
To change the low threshold, click its value. The Undo Advisor page appears, which can help you determine a better setting. See "Using the Undo Advisor" for more information.
The Configuration section also shows if auto-extending the tablespace is enabled, which is the default. When auto-extend tablespace is enabled, Oracle automatically increases the size of the undo tablespace when more space is needed. By combining automatic extension of the undo tablespace with automatically tuned undo retention, you can ensure that long-running queries will succeed by guaranteeing the undo required for such queries.
The methods for determining the undo retention period are described in the following sections:
See Also:
Oracle Database Administrator's Guide for more information about Automatic Undo Management and undo tablespaces.In the Recommendations section of the Undo Management page, you can specify a past time period for Oracle to analyze system activity. The current recommendations for your undo configuration are summarized. To update the analysis, click Update Analysis.
If Oracle recommends that you extend the undo tablespace, you can do so. See "Extending the Undo Tablespace" for more information.
To obtain more detailed information about the recommendations, click Undo Advisor. See also "Using the Undo Advisor".
When auto-extend tablespace is enabled, the system will automatically extend the undo tablespace if it is under space pressure.
However, when the auto-extend tablespace feature is disabled, you might need to manually extend the undo tablespace. You might discover this ahead of time while planning with the Undo Advisor. See "Using the Undo Advisor".
You might also need to extend the undo tablespace when you get an undo tablespace alert (warning or critical), or when you get "query too long" alert or "snapshot too old" error.
To resize the tablespace, click Edit Undo Tablespace. The Edit Tablespace page appears. To extend the tablespace, select a datafile and click Edit. Enter the new size in the File Size field. You can also opt to have the system automatically extend the datafile by enabling Automatically extend datafile when full under Storage and specifying an increment size.
Click Continue. Click Apply. A confirmation message should appear.
You can use the undo advisor to advise on the undo tablespace size and the low threshold undo retention setting. To navigate to the Undo Advisor page, navigate to the Undo Management page and do one of the following:
Click Undo Advisor.
Click the value adjacent to Low Threshold Undo Retention.
The top of the page shows the current auto-tuned undo retention time and undo tablespace size.
The Undo Advisor helps you answer the following questions about your undo configuration:
What is the maximum undo retention time required to guarantee successful query? This time period corresponds to the duration of your longest running query. You can find Longest Running Query on the Undo Management page under System Activity and Tablespace Usage.
Does my database have enough space to accommodate the maximum undo retention given the current tablespace configuration? To figure this out, note the Best Possible Undo Retention under analysis on the Undo Advisor page. If this time period is longer than your longest running query, your undo tablespace is adequately configured.
What if the best possible retention time is less than my longest running query? If this is the case, your undo tablespace is too small. You need to either set your tablespace to auto-extend or manually extend it. To figure out the required new size of your tablespace, on the Undo Advisor page New Undo Retention field, plug in the value of your longest running query. Enter an appropriate Analysis Time Period and click Update Analysis and Graph. Under Analysis, note the Required Tablespace size for New Undo Retention. To learn how to alter your tablespace, see "Extending the Undo Tablespace".
How do I configure undo to accommodate Flashback operations? If you are interested in using flashback features such as Flashback Query or Flashback Table, you can use the Undo Advisor to advise on how to configure your tablespace and undo retention. In order for flashback operations to go back in time, the database must ensure that undo data is not overwritten. To build a flashback recovery strategy, you can set the low threshold parameter, which determines the lowest value for automatic undo tuning. For example, if the low threshold is set to 15 minutes, Oracle never lowers the undo retention time to less than 15 minutes. Consequently, if your flashback recovery strategy requires you to go back 8 hours to recover from human errors, set the low threshold to 8 hours. To learn how to set a new retention time, see "Setting New Threshold Undo Retention Time".
The Required Tablespace Size by Undo Retention Length graph shows the relationship between retention period and undo tablespace size, highlighting key data points, such as the Auto-tuned and Best Possible Retention.
To set a new low threshold retention time from the Undo Advisor page, enter the value in New Undo Retention and click OK.
Alternatively, you can set this parameter as you do for other system parameters by navigating to the All Initialization Parameters page. The parameter is called undo_retention. For more information about this page, see"Viewing and Modifying Initialization Parameters".
When you install the Oracle Collaboration Suite Database, the initialization parameters are optimized for normal use in the environment. It is not necessary for you to alter any initialization parameters at this time. The steps described in this section will familiarize you with the initial parameter setting for your database and indicate how to modify parameters.
To view or modify the initialization parameters for your database:
From the Database Control Console Database Home page, click the Administration property page. The next page that you see is the Administration home page shown in Figure 6-8.
Click All Initialization Parameters under the Instance heading.
Enterprise Manager displays the Initialization Parameters page comprised of a table listing the current value of each initialization parameter as seen by the database instance. You can also use this page to alter initialization parameter values, using the Show SQL, Revert, and Apply buttons.
There are two property pages shown on the Initialization Parameters page:
Current—The table on this property page displays all of the initialization parameter values currently seen by the database instance (in memory).
You can use this page to make dynamic changes to parameters in the current running instance. Only parameters marked dynamic can be changed. To do so, enter a new value and click Apply.
SPFile—This property page is present when you are using a server parameter file, whose location is displayed a the top of the table. This property page shows parameter settings in the server parameter file.
Changes to parameter settings in this file are persistent across instance startup and shutdown. To make persistent changes to an initialization parameter, enter the new value and click Apply. You can optionally apply changes to the current running instance by checking Apply changes in SPFile to the current running instance. If you do not check this box, your changes will not take effect until the database is shut down and restarted.
Parameters marked as Basic represent a small subset of all initialization parameters, and are considered necessary to keeping the database running smoothly.
As the number of database users grows and workload increases, you might need to alter some initialization parameters. You can make these changes directly using the Initialization Parameter page as described, or indirectly using one of the advisors provided by Oracle. One such advisor, the memory advisor, is described in "Managing Memory Parameters".
Some initialization parameters, referred to here as memory parameters, determine the total size of the system global area (SGA) and the program global area (PGA), and of the subcomponents of the SGA. The settings of memory parameters can affect the performance of your database. When you install your database, these parameters are tuned to meet the requirements of the environment that you specify.
If you enabled Automatic Shared Memory Configuration when you configured your database, Oracle automatically sizes the subcomponents of the SGA, which include the shared pool and buffer cache. Oracle recommends that you enable memory auto tuning.
If Automatic Shared Memory Management is disabled, you can enable it on the Memory Parameters page. You can navigate to this page from the Administration page by clicking Memory Parameters under the Instance heading. From this page you can enable or disable Automatic Shared Memory Management and view your SGA and PGA memory settings from their property pages.
To modify the size of an SGA subcomponent without shutting down your instance, you can disable Automatic Shared Memory Management on the Memory Parameters page. With the Advice button on the Memory Parameters page, the Memory Advisor (discussed in "Using the Memory Advisor") gives you advice on optimal memory settings. If you choose to modify your memory settings manually, you can enter new sizes and apply changes dynamically while the instance is up. You can also do so from the Current property page on the Initialization Parameters page. However, there are some restrictions on dynamic modification of memory parameters. For more information, see Oracle Database Administrator's Guide.
To make changes to memory parameters persistent across instance startup and shutdown, you must alter your parameter file. You can do so by navigating to SPFile property page from the Memory Parameters page and making your changes there.
See Also:
Oracle Database Performance Tuning Guide for more information about memory parameters and their tuningThe OracleAS Metadata Repository stores schemas used by Oracle Collaboration Suite components for organizing data in the database. These schemas are automatically pre-seeded with appropriate values during installation. This section describes how to manage the OracleAS Metadata Repository, primarily using Grid Control.
This section contains the following topics:
Frequently Asked Questions About OracleAS Metadata Repository
Renaming and Relocating OracleAS Metadata Repository Datafiles
OracleAS Metadata Repository is an Oracle Database 10g database and can be managed using standard database procedures and tools. However, there are some considerations for managing OracleAS Metadata Repository within the Oracle Collaboration Suite environment. This section answers frequently asked questions about managing the OracleAS Metadata Repository.
What is the OracleAS Metadata Repository?
The OracleAS Metadata Repository is a database. It is pre-seeded with schemas to support Oracle Collaboration Suite components and services.
See Also:
{X-REF?} for information on the schemas that are pre-seeded in the OracleAS Metadata RepositoryWhen is the OracleAS Metadata Repository required?
The OracleAS Metadata Repository is an optional component of Oracle Application Server, but it is required for all Oracle Collaboration Suite installations. All of the Oracle Collaboration Suite applications require the OracleAS Metadata Repository.
How can I create an OracleAS Metadata Repository?
The OracleAS Metadata Repository is a part of any Oracle Collaboration Suite Infrastructure installation. The Oracle Universal Installer installs the OracleAS Metadata Repository from scratch. Under the most common deployment scenarios, the OracleAS Metadata Repository is created as part of a single Oracle Collaboration Suite Database. However, in some scenarios you might have several Oracle Collaboration Suite Databases, one of which contains the OracleAS Metadata Repository.
Are there any tools for managing the OracleAS Metadata Repository?
You can use Database Control to manage the OracleAS Metadata Repository. Refer to "Using the Oracle Enterprise Manager 10g Database Control Console".
Can I use the OracleAS Metadata Repository to deploy applications?
No. The Metadata Repository is not supported for deploying applications.
Are there any database features that are not supported by the OracleAS Metadata Repository?
The following tablespace management features are not supported:
Using ALTER TABLESPACE to assign a different default tablespace to a user
Using ALTER TABLESPACE to reduce the number of tablespaces that were created when you initially created the OracleAS Metadata Repository
Renaming a tablespace
It is, however, possible to use ALTER TABLESPACE to do segment management using autoextend or any other feature.
Can a OracleAS Metadata Repository coexist on a host with other databases?
Yes. When you install Oracle Collaboration Suite, the OracleAS Metadata Repository is created within the Oracle Collaboration Suite Database. However you can host the OracleAS Metadata Repository as a separate database in its own Oracle Home, on the same host as other databases, as long as each database has a unique SID and global database identifier. The databases may be able to share a Net listener as follows:
Multiple Oracle9i and Oracle 10g databases can share the same Net listener port. If the other databases on your host are Oracle9i or Oracle 10g databases, the OracleAS Metadata Repository can use the same Net listener port (for example, 1521) as the other databases.
If the other databases on your system are Oracle 8i databases running Oracle Net8 listener, then the OracleAS Metadata Repository must use a different port for its Net listener.
Can I change the OracleAS Metadata Repository Net listener port after installation?
Yes. Refer to "Changing theOracleAS Metadata Repository Net Listener Port".
Can I change the OracleAS Metadata Repository SID and global database name after installation?
No. This is not supported.
Can I change the character set of the OracleAS Metadata Repository?
Yes. Follow the instructions for changing the character set in the database documentation, then refer to "Changing the Character Set of OracleAS Metadata Repository" for updates you need to make to Oracle Application Server.
Can I tune the OracleAS Metadata Repository?
Yes, you can apply database tuning strategies to the OracleAS Metadata Repository.
One important point to be aware of is that the processes and sessions parameters in the Oracle init$SID.ora configuration file should be tuned to allow the OracleAS Metadata Repository to handle the maximum number of database sessions used by Oracle Collaboration Suite Applications tier installations.
The primary consumers of database sessions are OracleAS Portal and Oracle Mobile Collaboration. An init$SID.ora setting of processes=150 should support four Applications tier installations that include these components. Note that an OracleAS Portal best practice recommendation is to relocate the Portal instance out of the Infrastructure, which would reduce the database connections requirement.
See Also:
Oracle Application Server Performance Guide for a detailed description of the database connection usage of
mod_plsql in an OracleAS Portal installationCan I change OracleAS Metadata Repository schema passwords?
Yes. However, you must make sure to use the correct procedure. Some schemas store their passwords in Oracle Internet Directory and you must change their passwords using the Oracle Collaboration Suite Control so the password is updated in Oracle Internet Directory and the database.
Can I delete schemas from the OracleAS Metadata Repository that I am not using?
No. You should never delete any of the schemas that come with the OracleAS Metadata Repository.
Can I rename or relocate OracleAS Metadata Repository datafiles after installation?
Yes.
How can I backup and recover the OracleAS Metadata Repository?
Oracle provides a backup and recovery strategy for your entire Oracle Collaboration Suite environment, including the OracleAS Metadata Repository.
If a OracleAS Metadata Repository is registered with Oracle Internet Directory, then some schema passwords are stored in the directory and you can view them using Oracle Internet Directory tools.
You can view the passwords using the following procedures:
Viewing OracleAS Metadata Repository Schema Passwords using Oracle Directory Manager
Viewing OracleAS Metadata Repository Schema Passwords using ldapsearch
You can view OracleAS Metadata Repository schema passwords using Oracle Directory Manager as follows:
Start Oracle Directory Manager with the following command:
Unix:
ORACLE_HOME/bin/oidadmin
Windows:
Start > Programs > Oracle Application Server > OracleHome > Integrated Management Tools > Oracle Directory Manager
Log in to Oracle Directory Manager as the orcladmin user.
In the System Objects frame, expand Entry Management, expand cn=OracleContext, expand cn=Products, expand cn=IAS, expand cn=IAS Infrastructure Databases, and expand the orclReferenceName for the OracleAS Metadata Repository.
Select the OrclResourceName entry for the schema whose password you want to view.
In the Properties tab, you can view the password in the orclpasswordattribute field.
You can view OracleAS Metadata Repository schema passwords using ldapsearch, a command-line tool, as follows:
ORACLE_HOME/bin/ldapsearch -p oid_port -h oid_hostname -D "cn=orcladmin" -w orcladmin_password -b "orclresourcename=schema_name, orclreferencename=metadata_rep_global_db_name, cn=ias infrastructure databases, cn=ias, cn=products, cn=oraclecontext" -s base "objectclass=*" orclpasswordattribute
The command returns several lines of output. The password is listed in the following line:
orclpasswordattribute=password
The following is an example for viewing the ORASSO schema password. In this example, the ORASSO schema password is Og23NI78.
ORACLE_HOME/bin/ldapsearch -p 3060 -h myhost -D "cn=orcladmin"
-w mypassword -b "orclresourcename=ORASSO,
orclreferencename=orcl.mycompany.com,
cn=ias infrastructure databases, cn=ias, cn=products,
cn=oraclecontext" -s base "objectclass=*" orclpasswordattribute
OrclResourceName=ORASSO,orclReferenceName=orcl.mycompany.com
cn=IAS Infrastructure Databases,cn=IAS,cn=Products,cn=OracleContext
orclpasswordattribute=Og23NI78
The method for changing schema passwords in the OracleAS Metadata Repository varies by schema. Some schemas store their passwords in Oracle Internet Directory; you must change their passwords using the Oracle Collaboration Suite Control so that both Oracle Internet Directory and the database are updated. Other schemas do not store their passwords in Oracle Internet Directory; you can change their passwords in the database using SQL*Plus. A few schemas require special steps for changing their passwords.
See "Changing Oracle Collaboration Suite Schema Passwords" for special instructions for changing the Oracle Collaboration Suite Application schema passwords.
Table 6-2 lists the appropriate method for changing some OracleAS Metadata Repository schema passwords.
Table 6-2 Methods for Changing OracleAS Metadata Repository Schema Passwords
| Schema | Method for Changing Password |
|---|---|
|
You must change the password in two places:
|
|
|
If the OracleAS Metadata Repository is registered with Oracle Internet Directory, you must change the password in two places:
If the OracleAS Metadata Repository is not registered with Oracle Internet Directory, you only need to change the password directly in the database using SQL*Plus. |
|
|
Use the Oracle Collaboration Suite Control. Navigate to the Application Server Home Page for the Applications tier instance that uses this schema and follow the instructions in "Changing Schema Passwords using the Oracle Collaboration Suite Control". |
|
|
|
Use the Oracle Collaboration Suite Control. Navigate to the Application Server Home Page for the Applications tier instance that uses this schema and follow the instructions in "Changing Schema Passwords using the Oracle Collaboration Suite Control". |
|
|
You must change the password in two places:
|
|
This schema requires special steps. Refer to Oracle Application Server Certificate Authority Administrator's Guide for advanced topics in administration. |
|
|
This schema requires special steps. Refer to Oracle Internet Directory Administrator's Guide for information on resetting the default password for the database. |
|
|
This schema requires special steps. Refer to Oracle Application Server Certificate Authority Administrator's Guide for advanced topics in administration. |
|
|
Use the Oracle Collaboration Suite Control. Navigate to the Application Server Home Page for the Infrastructure (Identity Management) installation and follow the instructions in "Changing Schema Passwords using the Oracle Collaboration Suite Control". After you change the password, restart Oracle HTTP Server: opmnctl stopproc ias-component=HTTP_Server opmnctl startproc ias-component=HTTP_Server |
|
|
Use the Oracle Collaboration Suite Control. Navigate to the Application Server Home Page for the Infrastructure (Identity Management) installation and follow the instructions in "Changing Schema Passwords using the Oracle Collaboration Suite Control". |
|
|
Use the Oracle Collaboration Suite Control. Navigate to the Application Server Home Page for the Infrastructure (Identity Management) installation and follow the instructions in "Changing Schema Passwords using the Oracle Collaboration Suite Control". |
|
|
Use the Oracle Collaboration Suite Control. Navigate to the Application Server Home Page for the Infrastructure (Identity Management) installation and follow the instructions in "Changing Schema Passwords using the Oracle Collaboration Suite Control". Changing the ORACLE_HOME/portal/conf/ptlconfig -dad dad_name -site [-pw PORTAL_schema_password] Refer to Oracle Application Server Portal Configuration Guide. |
|
|
Use the Oracle Collaboration Suite Control. Navigate to the Application Server Home Page for the Infrastructure (Identity Management) installation and follow the instructions in "Changing Schema Passwords using the Oracle Collaboration Suite Control". |
|
|
You must change the password in two places:
|
|
|
Use the Oracle Collaboration Suite Control. Navigate to the Application Server Home Page for the Applications tier instance that uses this schema and follow the instructions in "Changing Schema Passwords using the Oracle Collaboration Suite Control". After you change the password, restart Oracle HTTP Server: opmnctl stopproc ias-component=HTTP_Server opmnctl startproc ias-component=HTTP_Server |
|
|
Use the Oracle Collaboration Suite Control. Navigate to the Application Server Home Page for the Applications tier instance that uses this schema and follow the instructions in "Changing Schema Passwords using the Oracle Collaboration Suite Control". |
|
|
Use the Oracle Collaboration Suite Control. Navigate to the Application Server Home Page for the Applications tier instance that uses this schema and follow the instructions in "Changing Schema Passwords using the Oracle Collaboration Suite Control". |
|
|
Use the Oracle Collaboration Suite Control. Navigate to the Application Server Home Page for the Applications tier instance that uses this schema and follow the instructions in "Changing Schema Passwords using the Oracle Collaboration Suite Control". |
|
|
Use SQL*Plus to change the password directly in the database. Refer to "Changing Schema Passwords using SQL*Plus". |
|
|
Use SQL*Plus to change the password directly in the database. Refer to "Changing Schema Passwords using SQL*Plus". |
|
|
Use SQL*Plus to change the password directly in the database. Refer to "Changing Schema Passwords using SQL*Plus". |
|
|
Use the Oracle Collaboration Suite Control. Navigate to the Application Server Home Page for the Applications tier instance that uses this schema and follow the instructions in "Changing Schema Passwords using the Oracle Collaboration Suite Control". |
|
|
Use the Oracle Collaboration Suite Control. Navigate to the Application Server Home Page for the Applications tier instance that uses this schema and follow the instructions in "Changing Schema Passwords using the Oracle Collaboration Suite Control". |
|
|
Use the Oracle Collaboration Suite Control. Navigate to the Application Server Home Page for the Applications tier instance that uses this schema and follow the instructions in "Changing Schema Passwords using the Oracle Collaboration Suite Control". |
|
|
Use SQL*Plus to change the password directly in the database. Refer to "Changing Schema Passwords using SQL*Plus". |
|
|
Use the Oracle Collaboration Suite Control. Navigate to the Application Server Home Page for the Applications tier instance that uses this schema and follow the instructions in "Changing Schema Passwords using the Oracle Collaboration Suite Control". |
|
|
Use the Oracle Collaboration Suite Control. Navigate to the Application Server Home Page for the Applications tier instance that uses this schema and follow the instructions in "Changing Schema Passwords using the Oracle Collaboration Suite Control". |
Some schemas store their passwords in Oracle Internet Directory. You must change their passwords using the Oracle Collaboration Suite Control so the password is updated in both the database and Oracle Internet Directory.
To change a schema password using the Oracle Collaboration Suite Control:
Depending on the schema, navigate to the home page for the Applications tier instance or the Infrastructure. Refer to Table 6-2 to determine which home page to use.
On the home page, click Infrastructure.
On the Infrastructure page, click Change Schema Password.
On the Change Schema Password page, select the schema. Enter the new password in the Password and Confirm Password fields. Click OK.
You can change some schema passwords directly in the database using SQL*Plus. To do so, connect to the database as a user with SYSDBA privileges and issue the following command:
SQL> ALTER USER schema identified by new_password;
For example, to change the SCOTT schema password to "abc123":
SQL> ALTER USER SCOTT IDENTIFIED BY abc123;
A few schemas (DCM, B2B, OWF_MGR) require you to manually update the password in the OracleAS Metadata Repository and in Oracle Internet Directory. You can use this procedure to change these passwords.
Start Oracle Directory Manager with the following command:
(UNIX) ORACLE_HOME/bin/oidadmin
(Windows) Start > Programs > Oracle Application Server - OracleHome >
Integrated Management Tools > Oracle Directory Manager
Log in to Oracle Directory Manager as the orcladmin user.
In the System Objects frame, expand Entry Management, expand cn=OracleContext, expand cn=Products, expand cn=IAS, expand cn=IAS Infrastructure Databases, and expand the orclReferenceName for the OracleAS Metadata Repository
Select the OrclResourceName entry for the schema whose password you want to change.
In the Properties tab, update the password in the orclpasswordattribute field.
Click Apply.
To configure the Applications tier and Infrastructure to work with OracleAS Metadata Repository after its character set has been changed:
Modify the character set of all Database Access Descriptors (DADs) accessing the OracleAS Metadata Repository to the new database character set.
Using the Oracle Collaboration Suite Control, navigate to the Applications tier instance home page.
In the System Components section, click HTTP_Server.
On the HTTP_Server home page, click Administration.
On the HTTP_Server Administration page, select PL/SQL Properties. This opens the mod_plsql Services page.
Scroll to the DADs section and click the name of the DAD that you want to configure. This opens the Edit DAD page.
In the NLS Language field, type in a NLS_LANG value whose character set is the same as the new character set for OracleAS Metadata Repository.
Click OK.
Repeat steps e to g for all DADs accessing OracleAS Metadata Repository.
Reconfigure the Oracle Ultra Search index as follows:
Connect to OracleAS Metadata Repository as WKSYS and invoke the following SQL script to reconfigure the default cache character set and index preference:
ORACLE_HOME/ultrasearch/admin/wk0prefcheck.sql
Connect to OracleAS Metadata Repository as the default user (WKTEST) and invoke the following SQL script:
ORACLE_HOME/ultrasearch/admin/wk0idxcheck.sql
The script requests you to enter the instance name (WK_INST). Enter "y" when prompted to go ahead with the change.
This script re-configures the instance (in this case, the default instance). It also truncates the Oracle Text index used by Oracle Ultra Search and you must force a recrawl to rebuild the index.
Repeat step b for all Oracle Ultra Search instances that were created before you changed the database character set. Invoke the script as the instance owner, and then force a recrawl of all data sources, if necessary.
When you install OracleAS Metadata Repository, you can choose the location for its datafiles. The default location is ORACLE_HOME/oradata/SID. After installation, you may want to relocate datafiles to a different directory. For example, you may want to move them to a directory on a file system with more space. Or, you may want to move them to a directory on a different disk for performance reasons. Another thing you may want to do is keep the datafiles in the same directory, but rename them.
If have kept datafiles in an Oracle home from an Oracle Collaboration Suite Release 1 (9.0.3) or Release 2 (9.0.4), you can use this procedure to move the datafiles. The upgrade process described in the Oracle Collaboration Suite Upgrade Guide does not move them from their original location.
This section provides a procedure for renaming or relocating datafiles. You can use this procedure on one or more datafiles, and the datafiles may be in multiple tablespaces.
This procedure applies to:
The datafiles associated with Oracle Collaboration Suite schemas and tablespaces.
The following standard Oracle database datafiles:
drsys01.dbf
system01.dbf
temp01.dbf
users01.dbf
The following example shows how to relocate two datafiles in two different tablespaces, as follows:
Relocate the oca.dbf datafile in the OCATS tablespace from /infra_home/oradata/orcl/oca.dbf to /new_directory/oca.dbf
Relocate the dcm.dbf datafile in the DCM schema from /infra_home/oradata/orcl/dcm.dbf to /new_directory/dcm.dbf
Before you start the procedure:
Make sure you have a complete cold backup of OracleAS Metadata Repository.
Connect to OracleAS Metadata Repository as a user with administrator privileges. You must have the ALTER DATABASE system privilege to relocate datafiles.
Read through the entire procedure before you start.
The procedure is as follows:
Verify the location of your datafiles.
You can verify the location of datafiles in a particular tablespace by querying the data dictionary view DBA_DATA_FILES.
For example, to query the location of datafiles in the OCATS and DCM tablespaces:
SQL> SELECT FILE_NAME, BYTES FROM DBA_DATA_FILES WHERE TABLESPACE_NAME = 'OCATS' OR TABLESPACE_NAME = 'DCM'; FILE_NAME BYTES --------------------------------------------- ------------ /infra_home/oradata/orcl/oca.dbf 78643200 /infra_home/oradata/orcl/dcm.dbf 96993280
Shut down all Applications tier instances that use OracleAS Metadata Repository. (All Oracle Collaboration Suite applications use the OracleAS Metadata Repository.)
Stop the Infrastructure that contains OracleAS Metadata Repository, then start an OracleAS Metadata Repository instance and mount the database without opening it, as follows:
Stop the Oracle Collaboration Suite Control and OPMN-managed processes:
emctl stop iasconsole opmnctl stopall
Leave the OracleAS Metadata Repository listener running.
Stop the OracleAS Metadata Repository instance (make sure the ORACLE_HOME environment variable is set):
sqlplus /nolog SQL> connect SYS as SYSDBA SQL> SHUTDOWN
Start an OracleAS Metadata Repository instance and mount the database without opening it:
SQL> STARTUP MOUNT
Move the datafiles to their new location using the operating system. For example:
(UNIX) mv /infra_home/oradata/orcl/oca.dbf /new_directory/oca.dbf mv /infra_home/oradata/orcl/dcm.dbf /new_directory/dcm.dbf (Windows) rename C:\infra_home\oradata\orcl\oca.dbf D:\new_directory\oca.dbf rename C:\infra_home\oradata\orcl\dcm.dbf D:\new_directory\dcm.dbf
Note:
You can execute an operating system command to copy a file by using the SQL*PlusHOST command.Use ALTER DATABASE to rename the file pointers in the database's control file:
SQL> ALTER DATABASE
RENAME FILE '/infra_home/oradata/orcl/oca.dbf',
'/infra_home/oradata/orcl/dcm.dbf'
TO '/new_directory/oca.dbf',
'/new_directory/dcm.dbf';
The new files must already exist; this statement does not create the files. Also, always provide complete filenames (including their full paths) to properly identify the old and new datafiles. In particular, specify the old datafile name exactly as it appears in the DBA_DATA_FILES view of the data dictionary.
Shut down OracleAS Metadata Repository, then perform a normal startup of the Infrastructure:
Leave the OracleAS Metadata Repository listener running.
Shut down OracleAS Metadata Repository:
SQL> SHUTDOWN
Start OracleAS Metadata Repository:
SQL> STARTUP
Start OPMN-managed processes and the Oracle Collaboration Suite Control:
opmnctl startall emctl start iasconsole
Start the Applications tier instances that use the Infrastructure. (All Oracle Collaboration Suite applications use the Infrastructure.)
Verify the new location of your datafiles.
SQL> SELECT FILE_NAME, BYTES FROM DBA_DATA_FILES WHERE TABLESPACE_NAME = 'OCATS' OR TABLESPACE_NAME = 'DCM'; FILE_NAME BYTES --------------------------------------------- --------------- /new_directory/oca.dbf 78643200 /new_directory/dcm.dbf 96993280
Perform a complete cold backup of OracleAS Metadata Repository. After making any structural changes to a database, always perform an immediate and complete backup.
[As a part of your routine security procedures, you may want to change the passwords used by Oracle Collaboration Suite components to access the application schemas.
Each of the following sections describes how to update the Oracle Collaboration Suite applications when you make a change to an application schema password. Generally, to change a schema password, see "Changing OracleAS Metadata Repository Schema Passwords", and then follow the specific instructions for each affected application.
This section contains the following topics:
Follow these steps to change the Oracle Calendar schema password:
Change the schema password for the Calendar database user.
Once the database schema password has been changed run the following command-line utility from the $ORACLE_HOME/ocal/bin directory:
unioidconf -setschemapassword <dbglobalname> -D <bindDN>
Where <bindDN> is typically 'cn=orcladmin' and <dbglobalname> is the fully-qualified database name <$ORACLE_SID><$DOMAIN_NAME>, such as 'ASDB.ca.oracle.com'.
See Also:
For more information on theunioidconf utility, refer to Chapter 6, "Calendar Server Utilities" in the Oracle Calendar Reference ManualYou can use the Application Server Control for Collaboration Suite to change the Oracle Content Services schema password. The password will be changed in Oracle Internet Directory, as well as:
On the current Applications tier, if you are running repository metrics on this Applications tier
In the Oracle Database, if you select Change in Database
You should only change the schema password from the Applications tier on which repository metrics are being collected. If you are collecting repository metrics on more than one Applications tier, you must change the schema password on all Applications tiers where repository metrics are collected. If you are not collecting any repository metrics, it does not matter which Applications tier you choose to use. See Oracle Content Services Administrator's Guide for more information about repository metrics.
To change the Oracle Content Services schema password:
Connect to the Application Server Control for Collaboration Suite from the Applications tier where you want to change the schema password.
Navigate to the Content Services Home page.
Click Stop Domain.
Click Change Schema Password in the Administration section. You will not be able to access the Change Schema Password page unless all Oracle Content Services processes have been stopped.
Provide the new password and confirm it in the Password and Confirm Password fields.
If the schema password has not yet been changed in the database, you can choose to change the database schema password at this time. To do this, select Change in Database and provide the database SYS password.
Click OK.
Return to the Content Services Home page and click Start Domain.
Follow these steps to change the Oracle Mail schema password (for the ES_MAIL schema):
Stop all Oracle Mail processes on every Applications tier:
ORACLE_HOME/opmn/bin/opmnctl stopproc ias-component=email
Connect to the Oracle Collaboration Suite Database as SYSDBA and change the password for ES_MAIL:
SQL> alter user es_mail identified by <new_password>;
where <new_password> is the clear text password to be changed.
Launch Oracle Directory Manager (oidadmin) and connect to the OracleAS Metadata Repository. Navigate to the following location under Entry Management:
cn=<ocs_db_global_name>,cn=MailStores,cn=um_system,cn=EMailServerContainer,cn=Products,cn=OracleContext
where <ocs_db_global_name> is the global name of the Oracle Collaboration Suite Database <$ORACLE_SID><$DOMAIN_NAME>, such as 'ASDB.ca.oracle.com'.
Change the value of the attribute orclpasswordattribute to the new password, and click Apply.
On each Applications tier on which Oracle Mail is configured, run the following command:
% $ORACLE_HOME/jdk/jre/bin/java -classpath $ORACLE_HOME/jlib/esinstall.jar:$ORACLE_HOME/jlib/esldap.jar:$ORACLE_HOME/lib/mail.jar:$ORACLE_HOME/jlib/esadmin.jar:$ORACLE_HOME/jlib/escommon.jar:$ORACLE_HOME/jlib/repository.jar:$ORACLE_HOME/jlib/emConfigInstall.jar oracle.mail.install.EMConfig $ORACLE_HOME
If you are using Grid Control to manage Oracle Mail, you also need to update Grid Control with the new schema password.
From the Grid Control Console, select the Targets tab.
Select the All Targets tab.
Search for the target type "". Click on the target name in the results page to view the target home page.
Click Monitoring configuration.
Type in the new schema password as the value of Administration Store Password.
Restart the Oracle Mail processes on all Applications tiers:
ORACLE_HOME/opmn/bin/opmnctl startproc ias-component=email
Restart the Oracle Collaboration Suite Control on all tiers:
ORACLE_HOME/bin/emctl stop iasconsole ORACLE_HOME/bin/emctl start iasconsole
Follow these steps to change the Oracle Real-Time Collaboration schema password:
Stop the Oracle Real-Time Collaboration Applications tier:
ORACLE_HOME/opmn/bin/opmnctl stopproc ias-component=RTC
Stop OC4J_imeeting (Oracle Real-Time Collaboration Application for J2EE):
$ORACLE_HOME/opmn/bin/opmnctl stopproc ias-component=OC4J process-type=OC4J_imeeting
Change the database schema password.
For each Applications tier, enter the following command:
$ORACLE_HOME/imeeting/bin/rtcctl
rtcctl> updateDatabaseInfo -dbpassword <newpassword>
Where <newpassword> is the new schema password.
Start the Oracle Real-Time Collaboration Applications tier:
ORACLE_HOME/opmn/bin/opmnctl startproc ias-component=RTC
Start OC4J_imeeting (Oracle Real-Time Collaboration Application for J2EE):
ORACLE_HOME/opmn/bin/opmnctl startproc ias-component=OC4J process-type=OC4J_imeeting
