An administrator may lock a database account and confirm that a new direct sign-in fails. That is one useful observation, but an access-revocation requirement can cover more than that single path.
For OceanBase and other enterprise database candidates, buyers should define the intended scope of revocation. Direct login, application identities, delegated access, and execution responsibilities need to be identified in the actual design. An account-status label alone does not explain what every participating path can still do.
Define whose access should change and what must continue
Begin with the business instruction. Is the organization removing a person’s access, retiring an application identity, suspending a service, or changing responsibility for a database object?
Those situations can require different treatment. Removing a former operator’s ability to sign in does not necessarily mean an approved business process should stop running. Conversely, leaving a process operational should not silently preserve an access path the organization intended to remove.
Identify the affected identities and their roles before choosing a procedure. The requirement should explain both prohibited access and approved continuing operation so the team can assess the result.
Read the exact scope of the locking feature
The MySQL 8.4 account-locking guide says direct connection attempts to a locked account fail. It also explains that account locking does not prevent specified proxy-user access or execution of stored programs and views that name the account as their definer.
Those documented distinctions matter to an access plan. They should not be generalized to every OceanBase mode, client, database product, or identity system.
Use the selected product’s evidence to establish all relevant paths. Agree the expected treatment of established sessions separately and validate the chosen procedure; the direct-login example should not be treated as evidence for an unexamined session or delegation path.
Map the paths before declaring revocation complete
A compact record can help security and application owners agree what the operation must accomplish.
| Access question | Requirement to establish | Evidence to request |
|---|---|---|
| Direct login | Which identity must no longer connect? | Rejected intended sign-in path |
| Application use | Which services use or represent that identity? | Identified service dependencies |
| Delegation or proxy | Which alternative identity paths are relevant? | Product-specific behavior and accepted scope |
| Object execution | Which approved processes must continue or change owner? | Documented execution responsibilities |
| Existing sessions | What outcome does the organization require? | Separate supported procedure and validation |
This is an original evaluation aid. It is not an account-locking command sequence or an instruction to interrupt a production service.
Compare OceanBase’s actual identity arrangement with alternatives
OceanBase’s trust page describes access-related security capabilities. A buyer should request the documentation and operating plan for the particular product, mode, and identity arrangement under consideration.
MySQL provides the scoped feature example above. Google Cloud Spanner’s security guidance provides another service-specific access context, which should be evaluated within its own identity architecture.
The comparison should use the same revocation objective rather than assume that identically named controls operate identically. Missing documentation remains a question to resolve, not proof that a candidate lacks an appropriate access-management route.
Test a removed operator and an approved continuing process
Consider a hypothetical service where a departing operator previously administered certain database objects. The security owner wants the operator’s access removed while an approved application process continues under an accepted responsibility arrangement.
The demonstration should identify how the operator previously connected and which relevant alternatives exist. Show the intended rejected paths through a controlled, approved exercise rather than checking only an account-status field.
Then demonstrate the application behavior that is supposed to continue. If ownership or execution arrangements must change, record that work and its acceptance evidence instead of assuming that a login change alone completes the task.
Include established sessions in the agreed scope discussion where relevant. The requirement should define their intended outcome and the team should provide product-specific evidence for achieving it. Do not infer that result from a different access-path test.
These are proposed exercises. No accounts, sessions, privileges, ownership, or application connections were changed for this article.
Keep a record of the approved continuing process and its owner. If it later uses another identity or delegation arrangement, that change should prompt a review of the revocation procedure rather than inherit an earlier completion claim automatically.
Preserve the revocation scope with the operating procedure
Keep the affected identities, relevant paths, continuing responsibilities, and accepted outcome together. Review the procedure when identity integration, delegation, or application ownership changes.
OceanBase can meet an enterprise need when its supported controls and the customer’s implementation satisfy that defined scope. Alternatives should face the same objective through their own documented mechanisms.
The useful conclusion is that intended access has been removed while approved responsibilities remain understandable. An account lock can contribute to that outcome; the complete plan needs to explain which paths it covers and how the rest are handled.
This article is based on documented sources and editorial analysis. Proposed evaluation examples are not independently measured benchmark results.