Create a secure JDBC connection so Looker can query Oracle schemas and serve analytics.
Moving reporting logic from ad-hoc SQL to governed Looker models centralizes metrics, removes spreadsheet chaos, and offloads heavy queries from transactional Oracle systems.
Looker Cloud ships the Oracle JDBC thin driver (v19); self-hosted Looker admins must copy ojdbc8.jar
into /looker/driver/
and restart Looker.
Click New Connection and pick Oracle as the dialect.
jdbc:oracle:thin:@//HOSTNAME:PORT/SERVICE_NAME
Use a least-privilege Oracle user with read access to your analytics schema.
Optional: oracle.jdbc.timezoneAsRegion=false
avoids timestamp drift.
Click Test; Looker validates network, auth, and basic SQL (SELECT 1 FROM DUAL).
Create a new view file per table, then a model referencing the Oracle connection.Example below uses e-commerce tables.
Run small deterministic queries—e.g., count records—to confirm latency and permissions.
SELECT
only.materialized views
for heavy joins.Modern JDBC strings require SERVICE_NAME; using :SID
fails with ORA-12505.
Oracle’s firewall must allow Looker’s IPs or private VPC peering; otherwise tests time out.
Yes—Looker supports 11g → 19c; verify the JDBC driver matches DB version.
Looker’s Linked Models let you query across connections in Explore, but performance depends on the slower source.
Keep LookML dialect-agnostic—avoid Oracle-only functions—so you can swap the connection and PDTs will rebuild.
.
Not mandatory but strongly recommended. Provide ?oracle.net.ssl_server_dn_match=true
in the JDBC string and upload the wallet to Looker.
Looker streams results; millions of rows are fine, but use aggregate explores or PDTs for better UX.