In my last article I wrote about how to leverage the database client libraries now bundled with SAS Viya for easily connecting to third-party databases. For SAS administrators, this eliminates the traditional overhead of client setup and configuration. Continuing with the Oracle example used in my last post, this article walks through the process of connecting to an Oracle database from a SAS Compute session (i.e. SAS Studio) using a centralised TNSNAMES file for alias-based resolution.
Setup
Before configuring anything in SAS, confirm the SAS Compute Server pod can reach Oracle at the network level. This isolates any connection failures as a SAS configuration issue rather than a networking issue.
Log in to SAS Studio, and then find the running SAS Compute server pod:
kubectl get pods | grep sas-compute
Exec into it:
kubectl exec -it sas-compute-server-8dfcccec-1b1d-4a8a-a225-91a1965d9c9d-52 -- bash
Test TCP connectivity on port 1521 (Oracle):
bash -c "echo > /dev/tcp/server.demo.sas.com/1521" && echo "Port open" || echo "Port closed"
If it succeeds, Oracle is reachable from the pod and you can configure SAS to make the connection.
A good test at this point is to verify the Path-based connection method outlined in my earlier post (it uses the bundled drivers/libraries without TNS aliases).
For TNSNAMES-based connections, the Oracle client needs to find your tnsnames.ora file. The location is controlled by the TNS_ADMIN environment variable, which SAS will also use. TNS_ADMIN must be an absolute path starting with /. It must point to the directory containing tnsnames.ora (not a parent directory).
Other environment variables like ORACLE_HOME and LD_LIBRARY_PATH will by default point to the bundled client path - we can leave these at their defaults, or we can add a new Oracle client and use that by changing these variables. In my test, SAS is using the bundled client and the 'custom' TNSNAMES file.
My sample TNSNAMES file (below) was saved to my NFS server - we'll mount this location into the SAS Compute server pod.
AJMAL =
(DESCRIPTION =
(ADDRESS_LIST =
(ADDRESS = (PROTOCOL = TCP)(HOST = server.demo.sas.com) (PORT = 1521))
)
(CONNECT_DATA =
(SERVER = DEDICATED)
(SERVICE_NAME = orcl)
)
)
We need to configure the path to this file as the value for the container-level TNS_ADMIN environment variable so that SAS inherits it correctly.
The sas-access.properties file controls environment variables for SAS/ACCESS engines. Update it with an absolute TNS_ADMIN path only. Change any other Oracle variables if needed; I left mine at their defaults so SAS uses its bundled client:
TNS_ADMIN=/access-clients/oracle/instantclient_21_10/network/admin
Ensure that the rest of your SAS/ACCESS to Oracle setup is configured correctly and that files like data-mounts-job.yml have been defined correctly and referenced in kustomization.yaml (to ensure that the TNSNAMES file is mounted in the SAS compute pod).
# General example for adding mounts to SAS containers with a
# PatchTransformer
apiVersion: builtin
kind: PatchTransformer
metadata:
name: data-mounts-job
patch: |-
## NFS path example - kubernetes will mount these for you
- op: add
path: /template/spec/containers/0/volumeMounts/-
value:
name: db-client-access
mountPath: "/access-clients"
- op: add
path: /template/spec/volumes/-
value:
name: db-client-access
nfs:
path: /opt/access-clients
server: host.k3d.internal
Next, build & apply/deploy using your chosen deployment method.
When it completes, we can test the connection using the alias from the SAS Compute pod before configuring SAS using sqlplus (note that sqlplus is not included in the bundled Oracle client):
LD_LIBRARY_PATH=/access-clients/oracle/instantclient_21_10 \ TNS_ADMIN=/access-clients/oracle/instantclient_21_10/network/admin \ /access-clients/oracle/instantclient_21_10/sqlplus <username>/<password>@AJMAL
Expected output:
SQL*Plus: Release 21.0.0.0.0 - Production on Mon Mar 23 04:52:18 2026
Version 21.10.0.0.0
Copyright (c) 1982, 2022, Oracle. All rights reserved.
Connected to:
Oracle Database 19c Enterprise Edition Release 19.0.0.0.0 - Production
Version 19.3.0.0.0
SQL>
Any issues with the setup should show up as errors here, so it is a good test to ensure things are working before proceeding.
If it works, test the LIBNAME with the TNS alias in SAS Studio. We can add some PUT statements to show the values of relevant environment variables:
%put NOTE: TNS_ADMIN = %sysget(TNS_ADMIN);
%put NOTE: ORACLE_HOME = %sysget(ORACLE_HOME);
%put NOTE: LD_LIBRARY_PATH = %sysget(LD_LIBRARY_PATH);
libname SASORA oracle user="<username>" password="<password>" path="AJMAL";
proc datasets lib=SASORA; quit;
Expected output:
...
79
80 %put NOTE: TNS_ADMIN = %sysget(TNS_ADMIN);
NOTE: TNS_ADMIN = /access-clients/oracle/instantclient_21_10/network/admin
81 %put NOTE: ORACLE_HOME = %sysget(ORACLE_HOME);
NOTE: ORACLE_HOME = /opt/sas/viya/home/lib64/accessclients/oracle/19.22/client64/lib
82 %put NOTE: LD_LIBRARY_PATH = %sysget(LD_LIBRARY_PATH);
NOTE: LD_LIBRARY_PATH =
/opt/sas/viya/home/lib64:/usr/lib/jvm/java-17-openjdk-17.0.14.0.7-3.el8.x86_64/lib/server:/opt/sas/viya/home/SASFoundation/sasexe:/u
sr/lib/jvm/java-17-openjdk-17.0.14.0.7-3.el8.x86_64/lib:/opt/sas/viya/home/lib64/accessclients/lib:/opt/sas/viya/home/lib64/accesscl
ients/teradata/20.00/lib64:/opt/sas/viya/home/lib64/accessclients/oracle/19.22/client64/lib:/opt/sas/viya/home/lib64/accessclients/v
ertica/lib64:/opt/sas/viya/home/lib64/accessclients/impala/lib:/opt/sas/viya/home/postgresql16/lib64:/opt/sas/viya/home/commonfiles/
home_1744895542/SASFoundation/sasexe:/opt/sas/viya/home/SASFoundation/utilities/bin
83
84
85 libname SASORA oracle user="STUDENT"
86 password=XXXXXXXXXX path="AJMAL";
NOTE: Libref SASORA was successfully assigned as follows:
Engine: ORACLE
Physical Name: AJMAL
87
88 proc datasets lib=SASORA;
Directory
Libref SASORA
Engine ORACLE
Physical Name AJMAL
Schema/User STUDENT
Client version: 19.22.0.0.0
Server version: 19.0.0.0.0
...
Conclusion
SAS Viya's bundled Oracle client libraries remove the most time-consuming part of Oracle connectivity setup. The client is already installed, already configured in LD_LIBRARY_PATH, and already version-matched to SAS Viya. As a SAS administrator, your only responsibilities are making tnsnames.ora available to SAS Compute server (and CAS if necessary) by mounting it, and ensuring the TNS_ADMIN variable points to the directory containing it at the SAS Compute/CAS server's startup.
The direct PATH method provides an immediate connectivity test without any TNS configuration. Once that succeeds, this method adds alias-based resolution so that centralised, pre-configured TNSNAMES files containing connection definitions can be conveniently utilised by SAS Viya.
My thanks to Nicolas Robert for his helpful guidance with this post.
Find more articles from SAS Global Enablement and Learning here.
