Note that the user SKING still can create objects in the USERS tablespace, but he must
explicitly specify USERS in any create table and create index commands.
Dropping Users
Dropping users is very straightforward and is accomplished with the drop user command. The
only parameters are the username to be dropped and the cascade option; any objects owned by
the user must be explicitly dropped or moved to another schema if the cascade option is not used.
In the following example, the user QUEENB is dropped, and if there are any objects owned by
QUEENB, they are automatically dropped as well:
SQL> drop user queenb cascade;
User dropped.
If any other schema objects, such as views or packages, rely on objects dropped when the
user is dropped, the other schema objects are marked INVALID and must be recoded to use other
objects and then recompiled. In addition, any object privileges that were granted by the first user
to a second user via the with grant option clause are automatically revoked from the second user
if the first user is dropped.
Becoming Another User
To debug an application, a DBA sometimes needs to connect as another user to simulate the
problem. Without knowing the actual plain-text password of the user, the DBA can retrieve
the encrypted password from the database, change the password for the user, connect with the
changed password, and then change back the password using an undocumented clause of the alter
user command.
Pages:
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491