All Products
Search
Document Center

Common user manual

Last Updated: Apr 16, 2020

Contents:

  • Compared to traditional data management software solutions, DMS Enterprise has the following features:

    • All users do not need to use a database account and password to log on to databases. Users can access databases once the administrator has registered them with DMS Enterprise on the System Management > User Management page.
  • In addition, users do not need to switch between accounts or URLs to perform operations on different databases.

Logon

  • To use DMS Enterprise, click DMS Consolel.
    • If you have purchased DMS Enterprise, you will be redirected to the DMS Enterprise console.
    • Note: If you are using a RAM user account, you need to log on to Alibaba Cloud before accessing the DMS Enterprise console.
  • Tips
    • If your enterprise has purchased DMS Enterprise, but you do not open the DMS Enterprise console after you logged on to DMS Consolelwith your account, contact the administrator of your enterprise to register your account with DMS Enterprise. Send the ID of your Alibaba Cloud account to the administrator.

Console

  • You can enter the DMS Enterprise console when logging on.

Permission

  • After you log on to the DMS Enterprise console, you need to submit a ticket to apply for the required permissions on the objects that you want to operate. You can operate databases or tables in the DMS Enterprise console only after the ticket is approved. The procedure is as follows:

  • Step 1: Find the target database or table.

    • Method 1: In the left-side navigation pane, choose Task Type > Apply for Permission. Click +Apply for Permission in the upper-right corner and select the permission category that you want to apply for. Then enter a keyword to search for the target database or table.
    • Method 2: In the search box at the top, enter a keyword of the target database or table name to go to the search result page. Find the target database or table and click Apply for Permission in the Actions column.
  • Step 2: Apply for the required permissions on the target database, table, or column, select the validity period, and then submit the ticket. Permissions are granted after the ticket is approved.

  • Tips

    • Permission types
      • You can apply for permissions on the following types of objects: databases, tables, and columns.
        • You can add a percent sign (%) before and after a keyword to find the target database or table by fuzzy match.
        • After you successfully apply for permissions on the target database, you can access non-sensitive and non-confidential fields in all tables, including new tables, of the database by default.
        • After you successfully apply for permissions on the target table, you can only access non-sensitive and non-confidential fields in that table by default, rather than any other tables or new tables. You can still access the target table even if its schema is changed.
        • You need to apply for permissions to access sensitive and confidential fields in the target table even if you have the permissions to access the target database or table.
      • Operations that require permissions include query, export, and change.
        • If you do not have the permission to export or change data in the target database, you cannot submit a data export or change ticket for the database.
    • Permission validity
      • When applying for a permission, you can specify a validity period as required. Upon expiration, the permission is automatically revoked and invalidated. On the homepage, you will be reminded of the permissions that are about to expire within seven days. You can renew your permissions in a timely manner.
      • After you successfully apply for permissions, you can release the permissions that are no longer needed. To release permissions, click Effective Permissions in the Accessible Databases/Tables section on the homepage of the DMS Enterprise console and find the target database or table. You can release some or all permissions as required.
    • To view your submitted tickets, click Submitted Tickets on the homepage of the DMS Enterprise console or click Apply for Permission in the left-side navigation pane.
    • After submitting a ticket, check the ticket status. If the ticket requires an approval, contact the approvers specified on each approval node to advance the approval process. You can perform subsequent operations only after the ticket is approved.

Data query

  • Scenarios

    • You can use the data query function of DMS Enterprise to analyze a small amount of data in real time or verify data of a published application without using the application code.
  • Step 1: Find the target database.

    • After you successfully apply for permissions, you can use any of the following methods to access the target database:
      • Method 1: Enter a keyword of the target database name in the search box at the top to go to the search result page. Find the target database and click Query in the Actions column.
      • Method 2: Click My Permission on the homepage of the DMS Enterprise console. Move the pointer over the target database and click Query.
      • Method 3: In the Recently Used Databases area on the homepage of the DMS Enterprise console, move the pointer over the target database and click Query. This area lists the last five database records on which you have performed a data query operation. If you have not performed a data query yet, no record is available here.
  • Step 2: Write SQL statements to query data in the target database.

    • We recommended that you write the fields according to the field types defined in the table schema. For example, if the id field is of the numeric type, write the field in the format of id=1 instead of id=’1’. If the name field is of the string type, write the field in the format of name=’xxx’ instead of name=xxx.
    • You can use the Druid SQL formatting tool to check the syntax. To use this Druid SQL formatting tool, click here.
  • Tips

    • Data queries in the DMS Enterprise console are performed in real time without storing the queried data in a data cache. However, the following restrictions are imposed to safeguard performance security and business data security:
      • The number of rows returned in a single SQL query is limited, which is 200 by default. The administrator and DBA can adjust the limit on the System Management > Configuration Management page.
      • The number of rows queried per day and the times of queries per day for each user are limited, which are 2,000 and 10,000 by default respectively. The administrator and DBA can adjust the limit for users on the System Management > User Management page.
      • After you successfully apply for permissions on the target database or table, you can access only non-sensitive and non-confidential fields by default. You need to apply for more permissions to access sensitive and confidential fields.

Data export

  • Scenarios

    • Data queries can only be used to query a small amount of data in real time. If you want to obtain all the rows in one query without being limited by the number of rows returned in a single query, you can use the data export function.
  • Step 1: Fill in a ticket to export data. Note that you need to select the correct target database and write correct SQL statements.

    • The SQL script for data export is similar to that for data queries, with the difference being that the number of exported rows is not limited. The system automatically verifies the syntax of the SQL script and the number of rows affected to provide a basis for the approval process.
  • Step 2: Check the approval status. If necessary, contact the approvers specified on each approval node to advance the approval process.

  • Step 3: Export data after the ticket is approved.

  • Tips

    • When filling in a ticket, you can add all stakeholders to the ticket so that they can view the ticket details. Except the administrator and DBA, users irrelevant to the ticket are not allowed to view the ticket details.
    • A ticket is valid for 24 hours after it is approved. You cannot export data or download the exported data after the ticket becomes invalid. Within the validity period, you can export data in different formats and character sets for multiple times, or download the data that has been exported successfully.
    • Depending on the number of rows affected and the sensitivity of data, a ticket needs to go through a different approval process. The administrator and DBA can customize approval processes for database instances.
    • After the ticket is approved, you can trigger the data export and the system will request data from the database. The whole process is streamlined and automated, which is convenient for R&D engineers to complete operations on their own.

Data change

  • Scenarios

    • You can use the data change function of DMS Enterprise to initialize data of a published project or fix temporary bugs without using the application code.
  • Step 1: Fill in a ticket to change data.

    • Note that you need to select the correct target database and write correct SQL scripts for changing and rolling back data.
    • The system automatically verifies the syntax of the SQL scripts and the number of rows affected to provide a basis for the approval process.
    • The rollback script is only used for risk control. If the data change does not meet business expectations, you can use this script to quickly submit a new change ticket for rollback. The system does not automatically run the rollback script in the current ticket.
  • Step 2: Check the approval status. If necessary, contact the approvers specified on each approval node to advance the approval process.

  • Step 3: Change data after the ticket is approved.

  • Tips

    • When filling in a ticket, you can add all stakeholders to the ticket so that they can view the ticket details. Except the administrator and DBA, users irrelevant to the ticket are not allowed to view the ticket details.
    • Depending on the number of rows affected and the sensitivity of data, a ticket needs to go through a different approval process. The administrator and DBA can customize approval processes for database instances.
    • After the ticket is approved, you can trigger the data change and the system will request data from the database. The whole process is streamlined and automated, which is convenient for R&D engineers to complete operations on their own.
    • You can configure the following options when performing a data change:
      • Back up data or not
        • If you choose to back up data, all the affected target data is backed up in the format of an INSERT statement.
      • Enable transactions or not
        • If you choose to enable transactions, the SQL statements that have been run successfully are rolled back in the event of a failure. If you choose not to enable transactions, the SQL statements are automatically committed one by one.
      • Enable immediate execution or specify a scheduled time
        • If you choose to specify a scheduled time, the system automatically performs the data change at the scheduled time without the need for manual intervention.

Database and table synchronization

  • Scenarios

    • Schema synchronization: Check whether the source database and target database have the same schema and what diff script is used to fix inconsistencies between them.
    • Empty database initialization: Build a new test environment or deploy a new business region, and replicate the whole schema of the source database to the target database.
    • Table consistency repair: Use a physical table as a baseline to compare whether all physical tables mapping a logical table have the same schema in the case of database sharding and table partitioning.
  • Step 1: Fill in a ticket to synchronize table data.

    • Select the source database and target database, and specify whether to compare some or all tables between them.
  • Step 2: Submit the ticket. The system automatically compares the two databases and generates a diff script used to fix inconsistencies between them.

  • Tips

    • Empty database initialization can be performed regardless of whether the target database is in a test environment or a production environment. However, the target database must be an empty database without any tables.
    • By default, the diff script generated for fixing inconsistencies can be run directly if the target database is in a test environment. However, the script must be approved before it can be run if the target database is in a production environment. The administrator and DBA can customize security rules for database instances.