Skip to main content
To assign privileges to users, administrators can use Data Control Language (DCL) statements. You can write and execute DCL statements like any other SQL statements against the Ocient® System and databases. DCL statements allow you to quickly and easily grant or revoke privileges from users. DCL statements work off two main concepts: Grants and Revokes. Statements that begin with GRANT give the associated privileges to a user or group. Statements that begin with REVOKE remove those privileges from a user or group. A full list of privileges can be found in the Ocient Privileges Reference. Supported DCL SQL statements are:
When you create an object in the system, database, or schema, the Ocient System automatically grants you all valid privileges for that type of object. For example, if you create a table in a database, the system grants you all privileges that apply to the created table. For details, see Table Privileges.For non-SSO users, the system assigns creator privileges to the user. For SSO users, the system follows specific criteria to assign the privileges. To understand the criteria the system uses, see User Access Control and Workload Management with SSO.

Grant Privileges

The GRANT statement grants privileges to a user or group. The privileges that you can grant in the GRANT statement map to the tables and differ per object. The WITH GRANT OPTION keywords specify that the grantee can also grant privileges on that object. To grant privileges, you must have:
  • VIEW privileges for the specified user or group being granted new privileges.
  • SYSAUTH privileges over the system or database object that the specified user or group is being granted privileges on.
Syntax
SQL
When you grant any privilege to a user on a system or database object other than the VIEW privilege, the database implicitly grants the VIEW privilege on the specified object to the user, as well as associated object types (e.g., DROP VIEW ON DATABASE also grants VIEW VIEW ON DATABASE and VIEW ON DATABASE).
Examples Grant Privilege on a Table This example grants privileges for the SELECT SQL statement on a table to a trusted group.
SQL
Grant Privilege on a Database This example grants the SELECT privilege for all tables and views on the database_name database to a trusted group.
SQL
Grant Privilege on the System This example grants the SELECT privilege for all tables and views on all databases in the system to a trusted group.
SQL
Grant Privilege on a Service Class This example grants the USE privilege on a service class to a user. The user can then reference the service class in the USING SERVICE CLASS query clause.
SQL
For examples of granting privileges for individual users, see Grant Role Membership.

Revoke Privileges

The REVOKE statement revokes privileges from a user or group. To revoke privileges, you must have:
  • VIEW privileges for the specified user or group having their privileges revoked.
  • SYSAUTH privileges over the system or database object from which the specified user or group has their privileges revoked.
SQL
When you revoke the VIEW privilege on a system or database object, the database implicitly revokes all privileges on the specified object from the user.If you revoke the VIEW privilege on an associated object type, the system revokes the privileges for that object type. For example, grant the DROP TABLE privilege to the user by using the GRANT DROP TABLE ON DATABASE SQL statement. Due to implicit granting by the system, this action causes the user to have DROP TABLE, VIEW TABLE, and VIEW privileges. If you revoke the VIEW TABLE privilege using the REVOKE VIEW TABLE ON DATABASE SQL statement, then the system revokes the privileges for the associated type. In this case, the user only retains the VIEW privilege on the database.
Examples Revoke Privilege on a Table This example revokes the SELECT privilege on a table from an untrusted group.
SQL
Revoke Privilege on a Database This example revokes the SELECT privilege for all tables and views on the database_name database from an untrusted group.
SQL
Revoke Privilege on the System This example revokes the SELECT privilege for all tables and views on all databases in the system from an untrusted group.
SQL
Revoke Privilege on a Service Class This example revokes the USE privilege on a service class from a user.
SQL
For examples of revoking privileges for individual users, see Revoking Role Membership.

Ocient Privileges Reference

These tables describe the privilege options on each object in Ocient and the allowed privileges.
As of version 23.0, Ocient DCL has replaced the TRUNCATE privilege with the DELETE privilege.Any TRUNCATE privileges, whether manually granted or assigned as part of a user role, should automatically convert to DELETE privileges following a system upgrade to version 23.0 or later.

Ocient System Privileges

Database Privileges

Schema Privileges

Granting privileges using DCL statements promotes an implicit schema to an explicit schema. For details, see Schemas.

Service Class Privileges

Only USE and VIEW are valid privileges for service classes. Attempting to grant other privileges on a service class returns an error.Granting USE does not affect automatic service class routing. The system never automatically selects a service class that is available only through a USE grant (and not through a group assignment). The USE privilege applies exclusively to the explicit USING SERVICE CLASS clause in a query.

View Privileges

Table Privileges

Machine Learning Model Privileges

Data Pipeline Privileges

Data Pipeline Function Privileges

Model Context Protocol Tool Privileges

The CREATE MCP TOOL privilege is a system-level or database-level privilege that grants the ability to create Model Context Protocol (MCP) tools. The user who creates a tool inherits all privileges on the tool. The following privileges apply to an individual MCP tool. System MCP tools are always visible to every user and cannot be dropped. By default, every user can execute system tools. A security administrator with the SYSAUTH privilege can grant or revoke the EXECUTE privilege on system tools.

User Privileges

Group Privileges

System Catalog and Object or View Visibility

The sys.privileges table in the system catalog exposes the privileges in the system. This table displays this information:
  • Timestamp of the grant
  • Grantor
  • Grantee
  • Privilege granted
  • Object type
  • Object id
  • Grantable
You can grant and revoke System Catalog VIEW and SELECT privileges just like ordinary tables. By default, everyone has VIEW and SELECT privileges on all system catalog tables. You can see the objects within the system catalog tables only if you have sufficient privileges on those objects. These objects require a VIEW or SELECT privilege or membership in a group or role to provide visibility. When you execute queries against a system catalog table, you do not see or know the existence of objects to which you do not have access. Views offer a similar functionality because the database does not check privileges to the underlying tables and views after you create a view. You can create a table with sensitive information and restrict visibility by creating a view on top of the table with only certain rows or columns. Someone else with the SELECT privilege to the view can query the view, even without any privileges to the underlying table.

Roles

Similar to groups, users can inherit privileges by being granted one of the predefined roles in Ocient. The names of and privileges assigned to roles in Ocient are predefined by the system. Roles can be applicable to the Ocient System or one of the user-defined databases. The roles in Ocient are as follows: System Roles
  • Security Administrator — Can read, create, and modify all users and groups.
  • System Administrator — Can read, create, and modify system objects such as tables, clusters, databases, etc. Can see and delete any queries system-wide.
  • System Analyst — Read-only access to the entire system. Can see all queries in the system.
Database Roles
  • Database Administrator — Can read, create, and modify database objects such as tables, clusters, databases, etc. This role can also create users for the database. Can see and delete all queries in the database.
  • Database Analyst — Read-only rights to database objects and data within the database. Can see all queries in the database.
  • Public — Every user who has access to the database has the Public role by default. You can grant other privileges to this role. This role allows the creation of a schema using the CREATE SCHEMA SQL statement and allows the viewing of other roles by default.
For specifics on each Ocient role, see Default Role Privileges.

Grant Role Membership

Grants a role to a user or group. Syntax
SQL
Example This example grants user1 the system administrator role.
SQL

Revoke Role Membership

Revokes a role from a user or group. Syntax
SQL
Example This example revokes the system administrator role from user1.
SQL

Default Role Privileges

Security Administrator Privileges

System Administrator Privileges

System Analyst Privileges

Database Administrator Privileges

Database Analyst Privileges

Public Privileges

Query Visibility

The visibility of queries depends on which database you log in to and your assigned privileges. If you have no additional VIEW QUERIES or VIEW REDACTED QUERIES privileges, you can view only queries that you submit yourself. The VIEW QUERIES privilege allows access to queries for all users in these system catalog tables:
  • sys.queries
  • sys.completed_queries
  • sys.plans
  • sys.active_query_scheduler_info
  • sys.all_operator_instances
  • sys.completed_operator_instances
  • sys.op_inst_debug_info
The VIEW REDACTED QUERIES privilege allows access to queries for all users in these system catalog tables, but with a redacted SQL statement for queries from other users:
  • sys.queries
  • sys.completed_queries
For the initial grant of query privileges, the grantor must have the Database Administrator or System Administrator role. Use the WITH GRANT OPTION keywords to allow a user to further grant this privilege to other users and groups.

Login Impacts on Query Visibility

Along with having role privileges, you must also log in to the appropriate database to view queries:
  • If you log in to the SYSTEM database, you can see all queries from all databases.
  • If you log in to a database other than SYSTEM, you can see queries in only that database.
Database Administration Manage Users, Groups, and Roles Object-Type Level Privileges Management
Last modified on September 23, 2026