DMS uses metadata — also called a data dictionary — to power object browsing, sensitive data detection, and fine-grained permission control over databases, tables, fields, data rows, and programmable objects.
Metadata describes your database's structure and includes:
Database names and character sets
Table names, sizes, row counts, character sets, and descriptions
Field types, lengths, precision, nullability, and descriptions
Table indexes and their fields
Programmable object names and types
All metadata is sourced from internal database objects such as information_schema.
Table size and row count values are not exact. Use them as order-of-magnitude estimates only.
How DMS acquires metadata
DMS acquires metadata differently depending on the control mode of the database instance.
| Security Protection | Not Security Managed | |
|---|---|---|
| Acquisition scope | All metadata for the database instance | Database-level information only; all other metadata is loaded in real time after you log in |
| Full acquisition on first access | Yes | Yes |
| Scheduled full acquisition | Daily at 18:00, automatically for all instances under Security Protection within the tenant | Not supported |
| On-demand incremental acquisition | 4 methods — see Trigger incremental acquisition | 3 methods — see Trigger incremental acquisition |
| Other | — | Database information is acquired based on the permissions of the database account when you log in |
Trigger incremental acquisition
To update metadata on demand, use any of the following methods:
Click the refresh button in the SQLConsole.
Click Refresh/Sync Dictionary in the database instance list on the left side of the console home page.
In System Administration > Instance Management, a DBA or administrator can trigger an incremental acquisition. For details, see Sync metadata.
For instances under Security Protection, DDL changes made through DMS automatically trigger an incremental acquisition of the affected table's metadata. This fourth method is not available for instances that are not under Security Protection.
Export metadata
To use metadata outside DMS — for example, in compliance audits — export it via the OpenAPI. See Database and table metadata for the API reference.
OpenAPI export is available only for instances under Security Protection.
List of acquired metadata
The following table shows which metadata DMS acquires for each supported database type. DMS uses each category of metadata for a specific purpose: field types and nullability enable sensitive data detection, indexes support query optimization guidance, and programmable object names enable fine-grained permission control.
| Object | MySQL protocol series① | PostgreSQL protocol series② | SQL Server | Oracle | MongoDB | Redis |
|---|---|---|---|---|---|---|
| Database | Name, Character set | Name | Name | Name | — | Name |
| Table | Name, Description, Character set, Number of rows, Size | Name, Description, Number of rows, Size | Name, Description, Number of rows, Size | Name, Description, Number of rows, Size | — | — |
| Field | Name, Type, Is nullable, Length, Precision, Description | Name, Type, Is nullable, Length, Precision, Description | Name, Type, Is nullable, Length, Precision, Description | Name, Type, Is nullable, Length, Precision, Description | — | — |
| Index | Name, Type, Index fields | Name, Type, Index fields | Name, Type, Index fields | Name, Type, Index fields | Name, Index fields | — |
| Programmable object | Name, Type | Name, Type | Name, Type | — | — | — |
| Schema | — | Name | — | — | — | — |
| Collection | — | — | — | — | Name | — |
| Key | — | — | — | — | — | Name, Type |
①: MySQL, PolarDB for MySQL, PolarDB distributed version, AnalyticDB for MySQL, DLA, ClickHouse, OceanBase MySQL mode, and MariaDB.
②: PostgreSQL, PolarDB for PostgreSQL (Compatible with Oracle), PolarDB for PostgreSQL, AnalyticDB for PostgreSQL, and OceanBase Oracle mode.