User management is not just creating accounts. It is deciding who can connect, what they can see, what they can change, and how much risk the environment can tolerate.
This post is part of the DBApreneur starter series. The goal is to explain the topic in plain language, then give you practical checks or examples you can use in real work.
Start with least privilege
Give users what they need, not what is convenient. Broad grants feel faster during setup, but they become painful during audits and incidents.
Users vs roles
A user is an account. A role is a collection of privileges. Roles make access easier to manage, especially when many users need the same permissions.
SQLPlus example
CREATE USER app_user IDENTIFIED BY "Use-A-Strong-Password";
GRANT CREATE SESSION TO app_user;
GRANT app_read_role TO app_user;
SELECT username, account_status, common
FROM dba_users
ORDER BY username;
Common DBA mistake
Do not use powerful accounts for application connections. Application schemas and runtime users should be separate. The account that owns objects does not always need to be the account the application uses every day.
Practical checklist
- Start with the problem you are trying to solve.
- Confirm the environment and version before applying any command.
- Test in a lab or lower environment first.
- Keep notes of what changed and why.
- Review performance, security, and rollback impact before production.
Final thought
Good engineering is rarely about memorizing commands. It is about understanding the shape of the system, asking better questions, and making changes that are boring in production. That is the kind of DBA work this series is trying to encourage.