Starburst Oracle connector#
The Starburst Oracle connector is an extended version of the Oracle connector, the initial configuration and usage is identical.
The following improvements are included:
The connector supports all of the SQL statements listed in the Oracle connector documentation
ALTER TABLE EXECUTE#
The Starburst enhanced connector supports the following commands for use with ALTER TABLE EXECUTE:
collect_statistics command is used with
Managed statistics to collect statistics for a table
and its columns.
The following statement collects statistics for the
and all of its columns:
ALTER TABLE example_table EXECUTE collect_statistics;
Collecting statistics for all columns in a table may be unnecessarily
performance-intensive, especially for wide tables. To only collect statistics
for a subset of columns, you can include the
columns parameter with an
array of column names. For example:
ALTER TABLE example_table EXECUTE collect_statistics(columns => ARRAY['customer','line_item']);
The connector includes a number of performance improvements, detailed in the following sections.
The connector is able to read data from Oracle using multiple parallel connections for tables partitioned as described in the Oracle partitioning documentation.
Determines the parallelism method. Possible values are:
Maximum number of parallel connections for a table scan
This feature is available for free, and does not require a valid license.
The statistics are collected by Oracle and retrieved by the connector.
To collect statistics for a table, add the following statement to your Oracle database:
EXECUTE DBMS_STATS.GATHER_TABLE_STATS('USER_NAME', 'TABLE_NAME');
See Oracle’s documentation for additional options and instructions on invoking a procedure when you’re not using SQL*Plus.
Cost-based join pushdown#
The connector supports cost-based Join pushdown to make intelligent decisions about whether to push down a join operation to the data source.
When cost-based join pushdown is enabled, the connector only pushes down join operations if the available Table statistics suggest that doing so improves performance. Note that if no table statistics are available, join operation pushdown does not occur to avoid a potential decrease in query performance.
The following table describes catalog configuration properties for join pushdown:
Strategy used to evaluate whether join operations are pushed down. Set to
Dynamic filtering is enabled by default. It causes the connector to wait for dynamic filtering to complete before starting a JDBC query.
You can disable dynamic filtering by setting the
property in your catalog configuration file to
By default, table scans on the connector are delayed up to 20 seconds until dynamic filters are collected from the build side of joins. Using a large timeout can potentially result in more detailed dynamic filters. However, it can also increase latency for some queries.
You can configure the
dynamic-filtering.wait-timeout property in your
catalog properties file:
You can use the
dynamic_filtering_wait_timeout catalog session property in a specific session:
SET SESSION example.dynamic_filtering_wait_timeout = 1s;
The maximum size of dynamic filter predicate, that is pushed down to the
connector during table scan for a column, is configured using the
domain-compaction-threshold property in the catalog
You can use the
SET SESSION domain_compaction_threshold = 10;
domain-compaction-threshold is set to
When the dynamic predicate for a column exceeds this threshold, it is compacted
into a single range predicate.
For example, if the dynamic filter collected for a date column
dt on the
fact table selects more than 32 days, the filtering condition is simplified from
dt IN ('2020-01-10', '2020-01-12',..., '2020-05-30') to
dt BETWEEN '2020-01-10' AND '2020-05-30'. Using a large threshold can result in increased
table scan overhead due to a large
IN list getting pushed down to the data
Metrics about dynamic filtering are reported in a JMX table for each catalog:
Metrics include information about the total number of dynamic filters, the number of completed dynamic filters, the number of available dynamic filters and the time spent waiting for dynamic filters.
Starburst Cached Views#
The connectors supports table scan redirection to improve performance and reduce load on the data source.
The connector supports Managed statistics allowing SEP to collect and store table and column statistics that can then be used for performance optimizations in query planning.
Statistics must be collected manually using the built-in
command, see collect_statistics for details and
The connector includes a number of security-related features, detailed in the following sections.
Oracle connector supports user impersonation. In the Oracle connector, user impersonation creates proxy user accounts and authorizes users to connect through them in Oracle database.
Enable user impersonation in the catalog file:
For more information, go to docs.oracle.com.
The connector supports Kerberos authentication using either a keytab or credential cache.
To configure Kerberos authentication with a keytab, add the following catalog configuration properties to the catalog properties file:
oracle.authentication.type=KERBEROS email@example.com kerberos.client.keytab=etc/kerberos/example.keytab kerberos.config=etc/kerberos/krb5.conf
To configure Kerberos authentication with a credential cache, add the following catalog configuration properties to the catalog properties file:
oracle.authentication.type=KERBEROS firstname.lastname@example.org kerberos.client.credential-cache.location=etc/kerberos/example.cache kerberos.config=etc/kerberos/krb5.conf
In these configurations the user
email@example.com, as defined in the
principal property, connects to the database. The related Kerberos service
ticket is located in the
etc/kerberos/example.keytab file, or cache
credentials in the
Kerberos credential pass-through#
You can configure the Starburst Oracle connector to pass through Kerberos credentials, received by SEP, to the Oracle database. To configure Kerberos and SEP, see Kerberos credential pass-through.
After you configure Kerberos and SEP, edit the properties file to enable the connector to pass the credentials from the server to the database.
Confirm the correct Kerberos client configuration properties in the catalog properties file. For example:
oracle.authentication.type=KERBEROS_PASS_THROUGH http.authentication.krb5.config=/etc/krb5.conf http-server.authentication.krb5.service-name=exampleServiceName http-server.authentication.krb5.keytab=/path/to/Keytab/File
Now any database accessed using SEP is subject to the Kerberos defined data access restrictions and permissions.
Password credential pass-through#
The connector supports password credential pass-through. To enable it, edit the catalog properties file to include the authentication type:
For more information about configurations and limitations, see Password credential pass-through.