Oracle SQL Plus The Definitive Guide- P37 pps

< previous page page_327 next page > Page 327 Privileges You Will Need To perform administrative tasks, you need to have been granted one of the following two roles: SYSOPER SYSDBA Exactly what you can do depends on which of the two roles has been granted to you. The SYSOPER role was created for computer operators, who, in the absence of a database administrator, may need to perform such tasks as starting, stopping, and backing up the database. A user with the SYSOPER role is limited to the following commands: STARTUP SHUTDOWN ALTER DATABASE OPEN ALTER DATABASE MOUNT ALTER DATBASE BACKUP ARCHIVE LOG RECOVER The SYSDBA role, on the other hand, is intended for database administrators. There are no restrictions on what a user with SYSDBA can do. These roles are granted at the database level, just like any other role, unless you are using operating-system authentication. In that case, the operating system roles OSOPER and OSDBA correspond to SYSOPER and SYSDBA, respectively. The Oracle Password File When you connect to a database instance, Oracle needs a way to authenticate you as a valid user. Normally Oracle does this by looking at the DBA_USERS table to see if the password you have supplied matches the one stored in the database. This works fine when the database is up and running, but what if it's not? Most users do not connect to a database when it's closed. After all, what would be the point? Database administrators, however, need to be able to start and stop the database, as well as perform other administrative tasks. That means they need to be able to connect and be authenticated, even when the database is closed. The dilemma is that usernames and passwords are stored in the database and cannot be accessed when it's closed. To resolve this dilemma of needing to authenticate database administrators when the database is closed, Oracle resorts to the method of storing their usernames and passwords in a file. This file is referred to as the password file, and is encrypted for < previous page page_327 next page > < previous page page_328 next page > Page 328 obvious reasons. Any users who have been granted the SYSDBA or SYSOPER privileges have their passwords stored in this file as well as within the database. The INTERNAL password is also stored in the password file. See the section below titled Connecting as INTERNAL. Whenever you connect using one of the keywords SYSDBA, SYSOPER, or INTERNAL, Oracle validates your password using the password file, not the database. You can read more about this file, including how to create and manage it, in Chapter 1 of the Oracle8 Administrator's Guide. Connecting in an Administrative Role To perform an administrative task, such as starting the database, you must connect to Oracle in your capacity as a database administrator. You do this by using the CONNECT command with the AS keyword to tell Oracle what role you intend to play. For example, if your username were RAYMOND, you would issue a command such as the following to connect in your role as an operator: CONNECT raymond/my_secret AS SYSOPER; This use of the AS keyword can be confusing to people, especially when they are first introduced to the subject. What exactly does it mean to connect as something? Many people take it to mean that you are really connecting as another user, but that's not quite the case. Take a look at the following command, and assume that you are the user named RAYMOND: CONNECT raymond/good_man; In this case, you are connecting to Oracle as yourself. This is easy enough to understand. You are attached to your own schema and see all of your own objects. If you are a database administrator, you may even have a number of system privileges that let you perform many administrative tasks without connecting as SYSOPER or SYSDBA. When you connect AS a role, AS SYSOPER, for example, you are connected to Oracle and associated with the SYS schema. Why couldn't you just connect as user SYS in the first place? Because then every DBA would need to know the password for SYS. Sharing passwords is not a good security practice. Also, Oracle needs to be able to determine whether you should have SYSOPER privileges or SYSDBA privileges. Your username is key to making that determination. < previous page page_328 next page > < previous page page_329 next page > Page 329 The bottom line is this. When you connect to Oracle AS something, think of it as connecting to Oracle in your special capacity as a database administrator, or as an operator. You are connecting to perform some administrative task outside the scope of what you typically do. Connecting as SYSOPER or SYSDBA In order to connect to Oracle in one of the administrative roles, you must run SQL*Plus and connect to the database using a special form of the CONNECT command, as shown in the following example: C:\>SQLPLUS /NOLOG SQL*Plus: Release 8.1.3.0.0 - Beta on Tue Oct 20 18:46:21 1998 (c) Copyright 1998 Oracle Corporation. All rights reserved. SQL> CONNECT raymond/good_man AS SYSDBA Connected. The /NOLOG option is used on the SQL*Plus command line so that SQL*Plus doesn't attempt to connect you as a normal user before you have a chance to connect as an operator or administrator. This is particularly necessary if the database is shut down and starting it is the reason you are connecting in the first place. As you can also see from the example, a special form of the CONNECT command is used. The syntax for it looks like this: CONNECT [logon[@service]] AS role; where: logon If you are using operating-system authentication, this should simply be a forward slash (/) character. Otherwise, this should be your username and password, in the normal username/password notation. service Is a SQL*Net or NET8 service name, and should match an entry in your TNSNAMES file. role The role must be either SYSDBA or SYSOPER, depending on which you have. When you connect like this, Oracle authenticates you using the Oracle password file. That way you can be authenticated as a privileged user even when the database is not open, which is important if you need to start the database. < previous page page_329 next page > < previous page page_330 next page > Page 330 If you are running on a Windows system, you may want to create a special shortcut to SQL*Plus that has /NOLOG as a command option. The Target field of the shortcut would look like this: C:\ORAWIN95\BIN\SQLPLUSW.EXE /NOLOG The exact path and executable name may vary depending on the specific versions of Windows and Oracle you are running. This will give you an icon to use when you need to start SQL*Plus without automatically connecting to the database. Once you've done that, you can use the CONNECT command as described earlier to connect as SYSDBA or SYSOPER. Connecting as INTERNAL Another option for performing database administration tasks is to connect using the INTERNAL keyword. This option exists mainly for backwards compatibility with previous versions of Oracle, and normally shouldn't be used. However, it can be helpful, and sometimes necessary. It is possible to have a database where no user has SYSDBA or SYSOPER. It is always possible to connect as INTERNAL. Here is the command to use: CONNECT INTERNAL [/password] In some cases, you may not need to supply a password when connecting internally. Not all DBAs configure their systems to require an internal password. With an operating system such as Unix, the DBA, or the Oracle user, may have operating-system privileges that allow him to connect internally. If you do need to supply a password, it is authenticated against the one stored in your database's password file. Starting and Stopping a Database. Two SQL*Plus commands, STARTUP and SHUTDOWN, allow you to start and stop an Oracle instance. STARTUP, of course, is the command used to start an instance and open a database. In order to use it, you need to understand the various transitional states a database goes through on the way from being closed to open. These are described next, in The States of a Database. The SHUTDOWN command is used to close a database and stop an instance. There are four ways to stop an instance. First, there is the normal shutdown, which closes a database cleanly and has the least disturbing effect on any current users. Three other options allow you to terminate user connections and shut down an instance more quickly. < previous page page_330 next page > < previous page page_331 next page > Page 331 The States of a Database There are four states an Oracle database may be in on the continuum between being fully shut down and fully operational. Usually, you want the database to be at one extreme or the other, either fully closed or fully open. However, certain administrative tasks, renaming a datafile, for example, require that the database be in one of the intermediate states. To understand the four states, you need to know the difference between an Oracle instance and an Oracle database. These terms are often used interchangeably, but each has a precise definition. Oracle uses the term instance to refer to a set of background processes and their shared memory structures. These background processes are the ones that write data to the database, maintain the redo logs, archive the redo logs, and so on. These processes all share an area of memory referred to as the System Global Area, or SGA for short. The instance only exists when these processes are in memory, are running, and the System Global Area has been allocated. Think of a program like Microsoft Word. When you first open it, you see the default document. Close that default document, and you pretty much have a blank window. Word is still running. You still have a menu bar and a window, but no files are open and you can't do any word processing. Word in this state is analogous to an Oracle instance. Oracle uses the term database to refer to the actual data being acted on by the instance. A database is stored in a collection of operating-system files on a host computer. To open a database, you first have to have an instance running. This makes sense if you think about it. Refer back to the Microsoft Word analogy. To open a document, you must start Word first. Now, just as Windows lets you double-click a document's icon to both start Word and open the document in what looks like one step, so Oracle has a way to start an instance and open a database with one command, the STARTUP command. When you issue the STARTUP command, Oracle will start an instance, associate it with a database, open the database, and allow users to connect. This process is illustrated in Figure 10-1. As you can see from Figure 10-1, there are four possible states to be aware of. The first state is when the instance is stopped and the database is closed. None of the background processes are running, no memory is allocated for a System Global Area, and all the database files are closed. The database is fully shut down. The next state may be referred to as the NOMOUNT state. When you issue the STARTUP command, Oracle first starts all the background processes and allocates memory for the SGA. It's possible to stop the process at this point. Why would < previous page page_331 next page > < previous page page_332 next page > Page 332 Figure 10-1. Starting and opening an Oracle database you do this? One reason would be to create a new database. In the NOMOUNT state, the processes are all running, but no database files have been associated with the instance. This is like Word when all document files have been closed. It's the perfect time to create something new. After the NOMOUNT state has been passed, the next point you reach is the MOUNT state. This is the point where you have told the instance what database you want to work with. The control files for the instance, and only the control files, will be open. The database datafiles remain closed. Renaming a datafile is an example of a task you could perform now. If you've moved one of the tablespace files or log files, you can use the ALTER DATABASE RENAME DATAFILE command to have Oracle write the file's new location to the database control files. The final state to be reached is the OPEN state. All the datafiles associated with the database will now be open, and users will be allowed to connect. It's important to understand this process. Next you will see how to control it using the STARTUP command. Starting a Database The STARTUP command is used to start an Oracle instance and open a database. Before issuing STARTUP, you must first decide whether you want the database to be fully open or not. If you don't want the database to be fully open, you must decide whether you want it to be mounted or not. Table 10-1 will help you decide, and shows you the basic command to reach each state. Table 10-1. STARTUP Commands for Each State Command Result Why? STARTUP Instance started, database files open, users can connect To make the database fully operational (table continued on next page) < previous page page_332 next page > < previous page page_333 next page > Page 333 Table 10-1. STARTUP Commands for Each State (continued) Command Result Why? STARTUP MOUNT Instance started, database control files open, database data files closed, users cannot connect To perform maintenance tasks such as renaming a data file STARTUP NOMOUNT Instance started, no database files open, users cannot connect To create a new database Depending on your environment, there may be other options you need to use with this command in order for your database to start successfully. One commonly used parameter is PFILE, which points to the initialization file for the database being started. The following example shows the STARTUP command being used with PFILE to do a normal startup of a database: SQL> CONNECT INTERNAL/plumtree@plum Connected to an idle instance. SQL> STARTUP PFILE=k:\instances\plum\initplum.ora ORACLE instance started. Total System Global Area 63475916 bytes Fixed Size 35760 bytes Variable Size 37192988 bytes Database Buffers 26214400 bytes Redo Buffers 32768 bytes Database mounted. Database opened. This instance is started, the database is opened, and users may connect. In order to perform certain administrative tasks, you may need to only start the instance, or only mount the database. You do that with the NOMOUNT and MOUNT keywords, respectively. The following example starts an instance and mounts a database, but does not open it: SQL> STARTUP MOUNT PFILE=k:\instances\plum\initplum.ora ORACLE instance started. Total System Global Area 63475916 bytes Fixed Size 35760 bytes Variable Size 37192988 bytes Database Buffers 26214400 bytes Redo Buffers 32768 bytes Database mounted. By using the NOMOUNT keyword instead of the MOUNT keyword, you could start the instance without associating a database. This is what you would need to do if you were planning to issue the CREATE DATABASE statement. Sometimes you want to restrict access to a database after it is opened, so that only the DBA can connect. You can accomplish this with the RESTRICT keyword, as shown in the following example. In restricted mode, only users with the < previous page page_333 next page > < previous page page_334 next page > Page 334 RESTRICTED SESSION system privilege (usually just the database administrators) are allowed to connect. SQL> STARTUP RESTRICT PFILE=k:\instances\plum\initplum.ora OPEN ORACLE instance started. Total System Global Area 5355764 bytes Fixed Size 63732 bytes Variable Size 5013504 bytes Database Buffers 204800 bytes Redo Buffers 73728 bytes Database mounted. Database opened. When opening a database in restricted mode, you need to use the OPEN keyword. Otherwise, the database is just mounted, but not opened. There are other options that may be used with the STARTUP command. These are described fully in Appendix A, SQL*Plus Command Reference. Stopping a Database The SHUTDOWN command is used to stop an Oracle instance. If you are not running with the parallel server option, shutting down an instance also closes the database. If you are using multiple instances to access a database, the database files will be closed only after all instances have been shut down. There are four ways to stop an instance. One way is to do a normal shutdown, which waits for all active users to disconnect before stopping the instance. Alternatively, you can use the TRANSACTIONAL, IMMEDIATE, or ABORT keywords to stop things more abruptly. Which keyword you should use depends on how quickly you need to stop the instance, and what effect you want that to have on the current users. SHUTDOWN NORMAL A normal shutdown is generally considered the most prudent approach to stopping an instance and closing a database. It certainly is the least disruptive to any currently connected users. The command to issue is simply: SHUTDOWN When you issue this command, Oracle performs the following steps: < previous page page_334 next page > < previous page page_335 next page > Page 335 1. New user connections are disallowed. 2. Oracle waits for all users to disconnect. 3. The database files are closed. 4. The instance is stopped. Step 2, waiting for the users to disconnect, may take a long time. In a normal shutdown, Oracle will not forcefully disconnect any active users, so the amount of time it takes to shut down the database depends largely on how quickly your users exit their applications. If all you want to do is quickly shut down and restart the database, the wait for active users to disconnect can be frustrating. On the one hand, you will have users who can't connect because the database is being shut down, yet on the other hand, you won't be able to finish the shutdown because there are active users still connected. In such a situation, you may have to take more drastic steps, such as doing a SHUTDOWN IMMEDIATE. Here is an example showing a normal SHUTDOWN: SQL> CONNECT INTERNAL/plumtree@plum Connected. SQL> SHUTDOWN Database closed. Database dismounted. ORACLE instance shut down. A normal shutdown results in the database activity being brought to an orderly halt. Recent changes contained in memory are flushed to files, the files are closed, memory structures are deallocated, and the instances's processes are stopped. At this point, the database files are all consistent with each other, and a cold backup could be taken. Other shutdown options, such as TRANSACTIONAL and IMMEDIATE, allow you perform a shutdown more quickly and still leave the database files in a consistent state. Shutdown Transactional A new feature of Oracle8i is the ability to perform a transactional shutdown. Unlike a normal shutdown, a transactional shutdown results in all users being forcibly disconnected. However, before being disconnected, users are allowed to complete their current transaction. Here is the syntax to use: SHUTDOWN TRANSACTIONAL < previous page page_335 next page > < previous page page_336 next page > Page 336 When you issue the SHUTDOWN TRANSACTIONAL command, Oracle stops all new connections and begins waiting for each user to commit. As each user commits his current transaction, that user is disconnected. When no more users remain, the database is closed and the instance is stopped. SHUTDOWN IMMEDIATE An immediate shutdown is very similar to a transactional shutdown, except that each user is disconnected when her current SQL statement completes, regardless of whether her transaction is complete or not. The command to use for an immediate shutdown is: SHUTDOWN IMMEDIATE In spite of its name, an immediate shutdown may not be very immediate. As users are kicked off, any open transactions must be rolled back. For short transactions, the rollback process is fairly quick, but in the case of a long transaction that affects a lot of a data, the rollback may take a noticeably long time. During this time, your session will appear stuck, because SHUTDOWN IMMEDIATE does not provide any feedback until the rollback process is complete. SHUTDOWN ABORT When you absolutely have to have the database down now, use the ABORT option. Aborting an instance is pretty much like kicking out the plug on your computer. All background processes are abruptly stopped. Files are not closed, at least not by Oracle, and open transactions are not rolled back. Instead, the rollback occurs when you restart the instance and Oracle performs crash recovery. The command to abort an instance is: SHUTDOWN ABORT Usually, you should only abort an instance when some critical event is imminent. Maybe an earthquake is occurring, and you expect to lose power any moment. Another reason to abort an instance is to remove any leftover background processes remaining after the instance has crashed. It's possible to get into a situation where STARTUP commands fail with errors saying that the instance is running, and where SHUTDOWN commands fail with errors saying that the instance is not running. In such a case, SHUTDOWN ABORT will usually set things right again. Since processes are stopped immediately when you abort an instance, rollback of open transactions cannot occur in response to a SHUTDOWN ABORT. Instead, this work is deferred until the next time you start the instance. At that time, Oracle will detect the previous crash, and will initiate a process called crash recovery. During the crash recovery process, Oracle will roll forward through the redo logs to catch up on any updates that were lost, and will then roll back any transactions < previous page page_336 next page > . use the OPEN keyword. Otherwise, the database is just mounted, but not opened. There are other options that may be used with the STARTUP command. These are described fully in Appendix A, SQL* Plus. Corporation. All rights reserved. SQL& gt; CONNECT raymond/good_man AS SYSDBA Connected. The /NOLOG option is used on the SQL* Plus command line so that SQL* Plus doesn't attempt to connect. file. role The role must be either SYSDBA or SYSOPER, depending on which you have. When you connect like this, Oracle authenticates you using the Oracle password file. That way you can be authenticated