Oracle Customers can now seamlessly use the Snowflake Data Cloud

David Ruthven
4 min readAug 4, 2021
Snowflake Data Grid

Snowflake’s Data Grid underpinned by our Data Sharing capability is unique in the industry for its ease of use, security, cross cloud, global reach and rapidly growing range of datasets and data providers through our Data Marketplace. To use the Snowflake Data Grid you do need a Snowflake account however that can be a low cost gateway to sharing data.

If you are using Oracle you are in luck

Oracle customers who want to leverage the Snowflake Data Grid can do that seamlessly by leveraging Snowflake partner Gluent’s Present capability. The Gluent Present capability makes any Snowflake table or view directly accessible to an Oracle database without any import or data movement. It is as close as possible in capability to subscribing directly to a shared dataset using Snowflake alone.

Gluent is typically used to shrink your Oracle footprint without compromising performance. The Gluent Present option opens up another valuable use case, seamless data sharing.

How does it Work?

Once Gluent is installed on your Oracle database, you make the tables or views accessible to your corresponding Oracle account on Snowflake.

As a simple example, all Snowflake accounts have access to a data share called SNOWFLAKE_SAMPLE_DATA containing TPC-H and TPC-DS benchmark data. The TPC tables and views are instantly accessible from the SNOWFLAKE_SAMPLE_DATA share, the largest TPC-DS table has 288 billion rows.

Browse SNOWFLAKE_SAMPLE_DATA shared database

To make the TPC-H CUSTOMER table accessible to Oracle via Gluent I issued the following command on my Snowflake account.

// ----------------------------------------------------------------
// Present TPC-H CUSTOMER table
// ----------------------------------------------------------------
create or replace view gluent.sh.tpch_customer as select * from SNOWFLAKE_SAMPLE_DATA.TPCH_SF1.CUSTOMER;

On the Oracle side I ran the Gluent Present command to make this table visible to Oracle.

$ $OFFLOAD_HOME/bin/present -t SH.TPCH_CUSTOMER -x

Now the TPCH_CUSTOMER table is accessible from Oracle and I can query it directly using Oracle SQL or PL/SQL since it appears as an Oracle table.

Describe Snowflake table from Oracle

And then run a query from SQL Developer

The entire query was pushed down and executed on Snowflake since all the data resides on Snowflake.

Query pushed down to Snowflake

What about Publishing data?

Using Gluent Offload I have already offloaded my Oracle Sales History SALES fact table to Snowflake. I can easily share that with other Snowflake accounts. Any updates synchronised from Oracle to Snowflake via Gluent will be immediately visible to any subscribers.

Here is the Oracle Sales History share I created on my Data Exchange.

Now let’s subscribe to it from a different Snowflake account which has access to my Data Exchange.

The shared table with 30 million rows is now instantly accessible from my subscribing Snowflake account.

Now run a Snowflake query

What did we do?

  1. Subscribed to a Snowflake shared dataset and made it instantly accessible to Oracle via Gluent Present.
  2. Queried the shared dataset in Oracle using Oracle SQL via Gluent Transparent Query
  3. Published an Oracle sourced dataset to a Snowflake Data Exchange, synchronised to Snowflake via Gluent Offload.
  4. Subscribed to the dataset in the Data Exchange
  5. Queried Oracle sourced data in Snowflake, maintained as a live share using Gluent Offload

Subscribing to shared data in Snowflake incurs no storage costs, data loading or transformation costs. The only costs are for executing queries or portions of queries pushed down to Snowflake by Gluent. When publishing data the only cost is the cost of storage and the ingest costs for the copy of data synchronised to Snowflake.

Hope that floats your boat.

--

--

David Ruthven

Snowflake Sales Engineer — opinions expressed are solely my own and do not express the views or opinions of my employer.