SAP
SAP HANA database explorer: A practical guide for SAP HANA Cloud
Learn how to connect to SAP HANA Cloud with SAP HANA database explorer, run SQL, inspect objects, manage users, review traces, and create audit policies.
On this page
- What SAP HANA database explorer does
- How to open an SAP HANA Cloud database
- Using the SQL console
- Managing users and database objects
- Creating audit policies with SQL
- Examining traces and diagnostic information
- Performance and scaling considerations
- A reliable administration workflow
- Common connection and query problems
SAP HANA database explorer is the primary browser-based workspace for querying and examining an SAP HANA Cloud database. It provides a SQL console, catalog browsing, database monitoring views, and access to diagnostic information from one administration tool.
For SAP HANA Cloud, administrators typically open the service in SAP HANA Cloud Central and then use SAP HANA database explorer for database-level work. This separation helps distinguish instance lifecycle tasks from SQL, schema, security, and diagnostic operations.
What SAP HANA database explorer does
SAP HANA database explorer connects to SAP HANA Cloud databases and presents their objects in a navigable catalog. Depending on the assigned privileges, an administrator can inspect schemas, tables, views, procedures, users, roles, and other database objects.
The SQL console is the main workspace for executing SQL statements. It supports query development, administrative commands, data inspection, and result analysis. Access is controlled by the database user and the privileges associated with that user, so the explorer does not bypass SAP HANA Cloud authorization.
How to open an SAP HANA Cloud database
Begin with SAP HANA Cloud Central to locate the relevant instance and database. Confirm that the instance is running, collect the connection information, and use the available database explorer option to open or register the database connection.
A successful connection normally requires the host, port, authentication method, and appropriate network access. Depending on the landscape, access may also depend on allowed IP ranges, a private connectivity arrangement, or an approved identity provider configuration.
After connecting, verify the database name and user context before running administrative SQL. This simple check reduces the risk of inspecting or changing the wrong database in a landscape with multiple instances.
Using the SQL console
The SQL console is useful for both read-only investigation and controlled administration. Queries can inspect system views, examine object definitions, review session information, and validate configuration results. Administrative statements should be tested carefully and executed only with the privileges required for the task.
For repeatable work, keep SQL statements in version-controlled files or an approved operational knowledge base. Record the purpose, affected objects, execution time, and result for changes that affect security, performance, or availability.
A typical diagnostic query might examine active sessions or object metadata through the relevant SAP HANA system views. The exact view and required privilege depend on the diagnostic question and the SAP HANA Cloud version.
Managing users and database objects
User and role administration can be performed with SQL statements in the database explorer when the connected account has the necessary privileges. Use roles to grant only the capabilities required by a person, service, or application, and separate development access from production administration.
Object work may include creating schemas, reviewing tables, checking dependencies, and examining procedures or views. Changes should follow the organization’s deployment process rather than being applied manually when a managed delivery pipeline is available.
For a broader overview of database authorization, see SAP HANA Cloud user management. The article is especially relevant when a database explorer connection succeeds but a particular catalog object or SQL operation remains unavailable.
Creating audit policies with SQL
SAP HANA Cloud audit policies are created and changed with SQL statements in the SQL console. They are not created through a generic security configuration form. A valid policy statement specifies one audit status, an action list, and a level.
For example:
CREATE AUDIT POLICY connect_audit
AUDITING ALL CONNECT
LEVEL INFO;
The available status is ALL, SUCCESSFUL, or UNSUCCESSFUL; exactly one is used in each statement. An action list such as CONNECT follows the status, and the statement ends with an audit level. Existing policies can be changed with ALTER AUDIT POLICY when the connected user has the required authorization.
For implementation considerations and operational context, see SAP HANA Cloud auditing. Review policy scope, retention expectations, and the volume of generated audit data before enabling broad coverage.
Examining traces and diagnostic information
Trace information helps investigate errors, performance symptoms, and component behavior. Use the diagnostic capabilities available through SAP HANA database explorer and the service’s supported monitoring interfaces, then correlate timestamps with application logs and database activity.
The SAP HANA trace files guide provides useful background for interpreting trace-related investigations. Access to diagnostic information depends on privileges and the diagnostic features available for the SAP HANA Cloud service.
When collecting diagnostic material, capture the affected operation, timestamp, user or application context, and relevant correlation identifier. Avoid exposing credentials, personal data, or other sensitive values in shared troubleshooting records.
Performance and scaling considerations
SAP HANA database explorer helps investigate workload behavior, but it does not replace capacity planning. Review memory use, expensive statements, concurrency, and workload timing before changing the service configuration.
SAP HANA Cloud scaling explains how instance capacity and service plan choices relate to scaling decisions. SAP HANA Cloud is sized by instance, service plan, and capacity; it does not use editions as a sizing category.
An SAP HANA Cloud elastic compute node is intended for read-intensive workloads and accepts no writes. It can support suitable read scaling patterns, but it is not a method for increasing write throughput. Validate application behavior and workload suitability before using one.
A reliable administration workflow
A practical workflow starts in SAP HANA Cloud Central, continues in SAP HANA database explorer, and ends with documented validation. First identify the correct instance and database. Next connect with an appropriately privileged account, inspect the current state, make the smallest required change, and verify the result with a query or supported monitoring view.
For production changes, include an approval record, rollback consideration, and a post-change observation period. Keep operational evidence close to the change record so another administrator can reproduce the investigation without relying on an undocumented session.
Common connection and query problems
A connection failure may result from an inactive instance, incorrect connection details, network restrictions, expired credentials, or an authentication configuration issue. Check the instance state in SAP HANA Cloud Central before troubleshooting database credentials.
If the connection works but an object is missing, distinguish between an incorrect schema context and insufficient privileges. If a query runs slowly, inspect the statement, filters, joins, data volume, and concurrent workload rather than assuming the explorer itself is the cause.
When a change produces an unexpected result, review the SQL history or operational record, check the affected object, and compare the current state with the intended configuration. Small, evidence-based checks are safer than repeating a statement without understanding its outcome.