0485-0488

Previous Table of Contents Next

Page 485

CHAPTER 21

Managing Users

IN THIS CHAPTER

  • User Needs Analysis 486
  • User Authentication Methods 491
  • User Configuration Setup 492
  • Resource Management 494
  • User Database Accounts 502
  • Special Account Considerations 505
  • Maintaining User Data 506

Page 486

In The Rime of the Ancient Mariner, the mariner uses the phrase "Water, water, everywhere" to describe his plight. If this phrase were changed to "users, users everywhere with no one to think" it might describe the plight of many DBAs throughout the world. With that analogy in mind, see whether you can correctly answer the following multiple-choice question:

Users are

a. Demanding
b. Unreasonable
c. In need of constant attention
d. The reason for the DBA's existence
e. All of the above

The correct answer is e. Yes, users are demanding (most of the time), unreasonable (sometimes), and in need of constant attention (at least sometimes). Try to keep these attributes in perspective, though. Users generally are nontechnical entities who do not understand such exotic things as tables, tablespaces, blocks, and buffers. When users are having problems, they react in the manner to which they are most accustomed: They call an expert. When the sink is backed up, call the plumber; when the car is backfiring, call the mechanic ; and when the database is not responding properly or an issue is unclear, call the database administrator.

Like it or not, the title DBA makes one an expert (at least in the eyes of the user community). In fact, at some sites, DBAs mystically possess the ability to diagnose applications, perform system administration, and solve network problems (which usually is untrue, but it's often the perception).

Many times, the last thing a DBA needs is an interruption from a user. ("I have a fragmented SYSTEM tablespace, two production tables at MAXEXTENTS, a full production tablespace, and a backup that didn't run properly. What do you mean you want your password reset?") But these people are the reason the DBA can cash a monthly paycheck. As Peter Parker (the boy who would be Spiderman) remarks in an early comic, "With great power comes great responsibility." If anyone could be a DBA, then everyone would be a DBA.

User Needs Analysis

Administering users is more complex than just having the SYS or SYSTEM password (or a similar DBA-privileged account) and creating an account. You face issues surrounding what system privileges to grant (such as CREATE TABLE or CREATE VIEW), which privileges to assign to which database objects, and ”in systems that provide application-level security, such as Oracle*Financials ”to which application modules a user should be granted access. Most important of all these issues is a better understanding of the needs of the user community you are supporting. Before moving on to the semantics of user creation and setup, this section briefly describes how to analyze and meet the needs of users.

Page 487

To better serve users, you need to understand what users want. In short, they usually want the moon ("I need access to the Corporate General Ledger system.") when they sometimes need only a telescope ("I need a copy of the report with the end-of-month sales totals."). Users often are willing to spend great time, energy, and effort telling you exactly what they need. But beware this path , grasshopper! More often than not, the user has only a limited scope on what is occurring in the overall system; you should rely on methods other than user requests to determine needs. Don't ignore user requests , but consider them in the context of what the users are trying to accomplish.

TIP
What a user wants is not always what he or she needs to accomplish his or her job.

Although the job of the database administrator is basically, as the name implies, administrative, you often will be involved in the overall design process. Often, the role is of a consulting type, in which you evaluate data modeling in relationships or work with applications administrators to set up security roles and database access. Although a more detailed discussion of database security is presented in Chapter 24, "Database Security," this section offers a brief discussion of the procedure of evaluating needs for user roles. Then you proceed to the syntactical elements of user management.

As a DBA, you might pose the following questions when creating a role and/or granting user access:

  • What does the user want?
  • What does the user need to accomplish the job?
  • Is someone currently set up with the same configuration requested by the user?
  • What is the minimum level of access the user requires to do the job?
  • What is the maximum level of access the user should reasonably have?
  • What constraints (technical or political) exist when setting up the user?

Suppose that a staff accountant approaches you, claiming that she requires access to the sales database. The corporation is a conglomerate of several different companies, each running its own databases. The accountant wants access to a database instance that does not contain any of her company's data. However, she claims that the information is for a corporate-level project on which she is working. Certainly, as the DBA, you have the proper level of privileges (the power) to add the user ”but should you do this (the responsibility part of the equation)?

Page 488

What Does the User Want?

As mentioned earlier, users generally tell you exactly what they need; take this request with a grain of salt. These perceptions are important because they do help shape and affect what the end and overall result will be. However, you should complete a full and overall analysis (generally in cooperation with other technical and nontechnical personnel) of the situation before logging on to the database and complying .

You should pay attention to what users say (or at least give the illusion of paying attention) for a couple reasons. First of all, you might learn something. Often, DBAs can become embroiled in the daily concerns of tuning the shared pool or making certain that the SORT_AREA_SIZE is set properly. Users work in their applications all day long and often can add valuable insight that DBAs might not have considered on their own. In addition, listening is important ”if for no other reason, to make users feel valuable and to enhance future working relationships. It is important to stress that any organization is a team, and as the DBA, you are not the dictator. Users and DBAs are both employees and should be team mates of the same corporate machine.

What Does the User Need to Accomplish the Job?

This question is often trickier than "What does the user want?" (or at least trickier to answer properly). At this level, you usually need to consult with an applications administrator, manager, or someone who understands the application level of the system. At a few sites, DBAs also serve as the applications administrators.

TIP
Setting up a well-planned system of checks and approvals that takes place before you see a user ID request saves you unnecessary confusion and considerable amounts of time.

A user may need access to a database to run reports , view data, modify existing data, create new database rows, or just view a copy of a report (as in the earlier example). Try to identify what the user is shooting for and what means are required to accomplish that goal. Also, consider whether options are available to accomplish the task without granting access. This is not to suggest that you conduct a Spanish Inquisition every time a user needs access. However, every single Oracle license costs your organization a hefty sum of cash that no one should fault you for trying to save. A final factor to consider is whether the user's access needs are ongoing. If a user just needs a copy of September's General Ledger, this can be done (under most circumstances) by another user (or even you) and passed on. If the same user is going to need the report every month, though, you probably shouldn't withhold this access.

Previous Table of Contents Next


Oracle Unleashed
Oracle Development Unleashed (3rd Edition)
ISBN: 0672315750
EAN: 2147483647
Year: 1997
Pages: 391

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net