Configure source account permissions

A harvesting account must connect to the source and read the catalogs, definitions, and schemas required by the reverse engineering plugin. With insufficient permissions, connection tests can succeed while harvesting fails, returns partial objects, or omits views, procedures, keys, and indexes.

Have a DBA grant access. Prefer a dedicated read-only account with least privilege for the target database and schema. Do not default to application accounts or administrator roles. Replace example accounts, databases, schemas, and passwords. Database, authentication, and plugin versions may require additional catalog access; obtain DBA review first.

Separate metadata access from data access

Purpose	Required capability	Reads business records?
Connection test	Log in to the database or service	No
Reverse engineering	Read catalogs, definitions, schemas, tables, columns, views, routines, constraints, indexes	Normally no
Sampling or profiling	Limited queries on approved tables/views	Yes
Quality validation and other tasks	Read columns/records required by task SQL	Yes

Structure-only projects should not receive unrestricted table reads because sampling is available. Restrict approved sampling by database, schema, table, row count, and account purpose.

Prepare permissions by database

Type	Reverse engineering focus	Additional checks
MySQL	Definitions and references in target databases	Views, routines, sampling
Oracle	Sessions and data dictionary	Cross-schema scope and table reads
DM Database	Dictionary, views, sequences, target objects	Restriction to target schema
SQL Server	Definitions and dependencies	DBA-defined read-only permissions instead of defaulting to db_owner
Hive/Impala	Target databases and objects	Metastore, Kerberos, platform permissions
PostgreSQL/Greenplum	Connect, schema usage, catalogs	Table SELECT for sampling and defaults for new tables
openGauss	Required pg_catalog objects	Catalog scope for the installed plugin
MongoDB	Collections and structure in target database	Sampling authorization and authentication database
Vertica/ClickHouse/Doris	Target schema/database structures	Current plugin requirements and project checklist

This table describes goals, not a substitute for official authorization scripts. A DBA must review production statements and restrict their scope.

Example grants

Commands contain no real credentials. user_name, database_name, schema_name, and password are placeholders.

MySQL

Read structure and data across databases:

GRANT SELECT ON *.* TO 'user_name'@'%';

Limit access to one database:

GRANT SELECT ON database_name.* TO 'user_name'@'%';
GRANT REFERENCES ON database_name.* TO 'user_name'@'%';

For structure only, have the DBA grant access to catalogs actually read by the plugin. Add target table SELECT only for approved sampling.

Oracle

Create a session and read the dictionary:

CREATE USER user_name IDENTIFIED BY "password";
GRANT CREATE SESSION TO user_name;
GRANT SELECT ANY DICTIONARY TO user_name;

Prefer approved object-level grants for limited schemas. Check additional access for cross-schema views, routines, and dependencies.

DM Database

Example metadata and object reads:

CREATE USER user_name IDENTIFIED BY "password";
GRANT SELECT ANY DICTIONARY,
      SELECT ANY MATERIALIZED VIEW,
      SELECT ANY SEQUENCE,
      SELECT ANY VIEW,
      SELECT ANY TABLE TO user_name;

Narrow production grants to target schemas. Have the DBA confirm statements for the installed DM version.

SQL Server

The account needs definitions and dependencies. An adapted database-level example is:

USE database_name;
ALTER ROLE [db_datareader] ADD MEMBER [user_name];
GRANT VIEW DEFINITION TO [user_name];

Some older environments use db_owner for quick verification. Its broad privileges are unsuitable as a production default. Replace it with DBA-approved database, schema, and object permissions after testing.

Hive and Impala

Example database-level read access:

GRANT SELECT ON DATABASE database_name TO USER user_name;

Also verify Metastore, authentication, Kerberos, and platform requirements. Grant mechanisms differ by distribution.

PostgreSQL and Greenplum

Create the account and configure schema access:

CREATE USER user_name;
ALTER USER user_name WITH PASSWORD 'password';
GRANT CONNECT ON DATABASE database_name TO user_name;
GRANT USAGE ON SCHEMA schema_name TO user_name;
GRANT SELECT ON ALL TABLES IN SCHEMA schema_name TO user_name;
ALTER DEFAULT PRIVILEGES IN SCHEMA schema_name
  GRANT SELECT ON TABLES TO user_name;

The plugin also needs version-appropriate pg_catalog access. Restrict sampling to approved schemas/tables. Validate Greenplum against its cluster version after applying the PostgreSQL approach.

openGauss

Example catalog access:

GRANT SELECT ON pg_catalog.pg_namespace TO user_name;
GRANT SELECT ON pg_catalog.pg_class TO user_name;
GRANT SELECT ON pg_catalog.pg_attribute TO user_name;
GRANT SELECT ON pg_catalog.pg_proc TO user_name;
GRANT SELECT ON pg_catalog.pg_constraint TO user_name;
GRANT SELECT ON pg_catalog.pg_inherits TO user_name;
GRANT SELECT ON pg_catalog.pg_index TO user_name;
GRANT SELECT ON pg_catalog.pg_type TO user_name;
GRANT SELECT ON pg_catalog.pg_roles TO user_name;
GRANT SELECT ON pg_catalog.pg_user TO user_name;
GRANT SELECT ON pg_catalog.pg_extension TO user_name;

Add database connection, schema usage, and approved table reads. Test a few objects for any additional plugin-specific catalogs.

MongoDB

Grant a read role for the target database:

db.grantRolesToUser(
  "user_name",
  [{ role: "read", db: "database_name" }]
);

Verify authentication database, target database, and user domain. Restrict collections and sample scope according to policy.

Vertica, ClickHouse, and Doris

Vertica schema example:

GRANT SELECT ON SCHEMA schema_name TO user_name;

ClickHouse read example:

GRANT SELECT ON *.* TO user_name;

Doris single-database example:

CREATE USER 'user_name'@'%' IDENTIFIED BY 'password';
GRANT SELECT_PRIV ON database_name.* TO 'user_name'@'%';

All-database Doris access is only for approved administration scenarios. Verify catalogs, views, and sampling requirements for each installed plugin.

MaxCompute

Configure Endpoint, Access ID, Access Key, and Project Name, with project-side metadata permissions. Provide keys through secure connection configuration or secret management, never manuals, screenshots, or shared documents.

Grant and verify access

1. Confirm the system, database, schema, object types, and sampling needs.
2. Create a dedicated account with appropriate rotation, source-address, and expiration policies.
3. Grant only required login, catalog, and object access.
4. Test the DAM connection. Success proves login, not complete reverse engineering access.
5. Harvest a few known objects and compare counts for tables, columns, views, procedures, functions, keys, and indexes.
6. Add approved sampling reads if needed and test a few records.
7. Expand after verification; record account, scope, plugin version, and verification date.

Troubleshoot incomplete reverse engineering

Symptom	Check first
Connection failure	Network, host, port, authentication, account status, login rights
Connected but no objects	Catalog access, database/schema scope, plugin, default database
Tables/columns only	Definition, routine, and catalog permissions
Some schemas only	Account visibility, filters, allowlists, cross-schema access
Structure works, sampling fails	Table SELECT, row security, query limits
Grants changed but results unchanged	Rerun, account in use, caches/plugin reload

Use task logs to identify the failing object and read operation. Have the DBA grant the minimum missing access and retest a limited scope rather than repeatedly adding global privileges.