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:
Fulfill the Oracle connector requirements.
Additional features of the connector require a valid Starburst Enterprise license, unless otherwise noted.
The connector supports all of the SQL statements listed in the Oracle connector documentation
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.
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 catalogname.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
'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 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. Use the following properties in the catalog properties file to configure it.
oracle.authentication.type=KERBEROS firstname.lastname@example.org kerberos.client.keytab=etc/kerberos/example.keytab kerberos.config=etc/kerberos/krb5.conf
In this configuration the user
email@example.com, as defined in the
principal property, connects to the database. The related Kerberos
service ticket is located 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.