Tuesday May 27, 2014

R Package Installation with Oracle R Enterprise

Programming languages give developers the opportunity to write reusable functions and to bundle those functions into logical deployable entities. In R, these are called packages. R has thousands of such packages provided by an almost equally large group of third-party contributors. To allow others to benefit from these packages, users can share packages on the CRAN system for use by the vast R development community worldwide.

R's package system along with the CRAN framework provides a process for authoring, documenting and distributing packages to millions of users. In this post, we'll illustrate the various ways in which such R packages can be installed for use with R and together with Oracle R Enterprise. In the following, the same instructions apply when using either open source R or Oracle R Distribution.

In this post, we cover the following package installation scenarios for:

R command line
Linux shell command line
Use with Oracle R Enterprise
Installation on Exadata or RAC
Installing all packages in a CRAN Task View
Troubleshooting common errors

1. R Package Installation Basics

R package installation basics are outlined in Chapter 6 of the R Installation and Administration Guide. There are two ways to install packages from the command line: from the R command line and from the shell command line. For this first example on Oracle Linux using Oracle R Distribution, we’ll install the arules package as root so that packages will be installed in the default R system-wide location where all users can access it, /usr/lib64/R/library.

Within R, using the
install.packages function always attempts to install the latest version of the requested package available on CRAN:

R> install.packages("arules")

If the arules package depends upon other packages that are not already installed locally, the R installer automatically downloads and installs those required packages. This is a huge benefit that frees users from the task of identifying and resolving those dependencies.

You can also install R from the shell command line. This is useful for some packages when an internet connection is not available or for installing packages not uploaded to CRAN. To install packages this way, first locate the package on
CRAN and then download the package source to your local machine. For example:

$ wget http://cran.r-project.org/src/contrib/arules_1.1-2.tar.gz

Then, install the package using the command R CMD INSTALL:

$ R CMD INSTALL arules_1.1-2.tar.gz

A major difference between installing R packages using the R package installer at the R command line and shell command line is that package dependencies must be resolved manually at the shell command line.
Package dependencies are listed in the Depends section of the package’s CRAN site. If dependencies are not identified and installed prior to the package’s installation, you will see an error similar to:

ERROR: dependency ‘xxx’ is not available for package ‘yyy’

As a best practice and to save time, always refer to the package’s CRAN site to understand the package dependencies prior to attempting an installation.

If you don’t run R as root, you won’t have permission to write packages into the default system-wide location and you will be prompted to create a personal library accessible by your userid. You can accept the personal library path chosen by R, or specify the library location by passing parameters to the
install.packages function. For example, to create an R package repository in your home directory:

R> install.packages("arules", lib="/home/username/Rpackages")


$ R CMD INSTALL arules_1.1-2.tar.gz --library=/home/username/Rpackages

Refer to the
install.packages help file in R or execute R CMD INSTALL --help at
the shell command line for a full list of command line options.

To set the library location and avoid having to specify this at every package install, simply create the R startup environment file .
Renviron in your home area if it does not already exist, and add the following piece of code to it:

R_LIBS_USER = "/home/username/Rpackages"

2. Setting the Repository

Each time you install an R package from the R command line, you are asked which CRAN mirror, or server, R should use. To set the repository and avoid having to specify this during every package installation, create the R startup command file .Rprofile in your home directory and add the following R code to it:

cat("Setting Seattle repository")
r = getOption("repos") 
r["CRAN"] = "http://cran.fhcrc.org/"
options(repos = r)

This code snippet sets the R package repository to the Seattle CRAN mirror at the start of each R session.

3. Installing R Packages for use with Oracle R Enterprise

Embedded R execution with Oracle R Enterprise allows the use of CRAN or other third-party R packages in user-defined R functions executed on the Oracle Database server. The steps for installing and configuring packages for use with Oracle R Enterprise are the same as for open source R. The database-side R engine just needs to know where to find the R packages.

The Oracle R Enterprise installation is performed by user
oracle, which typically does not have write permission to the default site-wide library, /usr/lib64/R/library. On Linux and UNIX platforms, the Oracle R Enterprise Server installation provides the ORE script, which is executed from the operating system shell to install R packages and to start R. The ORE script is a wrapper for the default R script, a shell wrapper for the R executable. It can be used to start R, run batch scripts, and build or install R packages. Unlike the default R script, the ORE script installs packages to a location writable by user oracle and accessible by all ORE users - $ORACLE_HOME/R/library.

To install a package on the database server so that it can be used by any R user and for use in embedded R execution, an Oracle DBA would typically download 
the package source from CRAN using wget. If the package depends on any packages that are not in the R distribution in use, download the sources for those packages, also. 

For a single Oracle Database instance, replace the R script with ORE to install the packages in the same location as the Oracle R Enterprise packages.

$ wget http://cran.r-project.org/src/contrib/arules_1.1-2.tar.gz
$ ORE CMD INSTALL arules_1.1-2.tar.gz

Behind the scenes, the ORE script performs the equivalent of setting R_LIBS_USER to the value of
$ORACLE_HOME/R/library, and all R packages installed with the ORE script are installed to this location. For installing a package on multiple database servers, such as those in an Oracle Real Application Clusters (Oracle RAC) or a multinode Oracle Exadata Database Machine environment, use the ORE script in conjunction with the Exadata Distributed Command Line Interface (DCLI) utility.

$ dcli -g nodes -l oracle ORE CMD INSTALL arules_1.1-1.tar.gz

The DCLI -g flag designates a file containing a list of nodes to install on, and the -l flag specifies the user id to use when executing the commands. For more information on using DCLI with Oracle R Enterprise, see Chapter 5 in the Oracle R Enterprise Installation Guide.

If you are using an Oracle R Enterprise client, install the package the same as any R package, bearing in mind that you must install the same version of the package on both the client and server machines to avoid incompatibilities.

4. CRAN Task Views

CRAN also maintains a set of Task Views that identify packages associated with a particular task or methodology. Task Views are helpful in guiding users through the huge set of available R packages. They are actively maintained by volunteers who include detailed annotations for routines and packages. If you find one of the task views is a perfect match, you can install every package in that view using the ctv package - an R package for automating package installation.

To use the ctv package to install a task view, first, install and load the ctv package.

R> install.packages("ctv")

R> library(ctv)

Then query the names of the available task views and install the view you choose.

R> available.views()
R> install.views("TimeSeries")

5. Using and Managing R packages

To use a package, start up R and load packages one at a time with the library command.

Load the
arules package in your R session.

R> library(arules)

Verify the version of
arules installed.

R> packageVersion("arules")

[1] '1.1.2'

Verify the version of
arules installed on the database server using embedded R execution.

R> ore.doEval(function() packageVersion("arules"))

View the help file for the apropos function in the

R> ?apropos

Over time, your package repository will contain more and more packages, especially if you are using the system-wide repository where others are adding additional packages. It’s good to know the entire set of R packages accessible in your environment. To list all available packages in your local R session, use the
installed.packages command:

R> myLocalPackages <- row.names(installed.packages())

R> myLocalPackages

To access the list of available packages on the ORE database server from the ORE client, use the following embedded R syntax:

R> myServerPackages <-
ore.doEval(function() row.names(installed.packages())
R> myServerPackages

6. Troubleshooting Common Problems

Installing Older Versions of R packages

If you immediately upgrade to the latest version of R, you will have no problem installing the most recent versions of R packages. However, if your version of R is older, some of the more recent package releases will not work and
install.packages will generate a message such as:

Warning message:
In install.packages("arules")
: package ‘arules’ is not available

This is when you have to go to the
Old sources link on the CRAN page for the arules
package and determine which version is compatible with your version of R.

Begin by determining what version of R you are using:

$ R --version

Oracle Distribution of R version 3.0.1 (--) -- "Good Sport"
Copyright (C) The R Foundation for Statistical Computing
Platform: x86_64-unknown-linux-gnu (64-bit)

Given that R-3.0.1 was
released May 16, 2013, any version of the arules package released after this date may work. Scanning the arules archive, we might try installing version 0.1.1-1, released in January of 2014:

$ wget http://cran.r-project.org/src/contrib/Archive/arules/arules_1.1-1.tar.gz
$ R CMD INSTALL arules_1.1-1.tar.gz

For use with ORE:

$ ORE CMD INSTALL arules_1.1-1.tar.gz

The "package not available" error can also be thrown if the package you’re trying to install lives elsewhere, either another R package site, or it’s been removed from CRAN. A quick Google search usually leads to more information on the package’s location and status.

Oracle R Enterprise is not in the R library path

On Linux hosts, after installing the ORE server components, starting R, and attempting to load the ORE packages, you may receive the error:

R> library(ORE)
Error in library(ORE) : there is no package called ‘ORE’

If you know the ORE packages have been installed and you receive this error, this is the result of not starting R with the ORE script. To resolve this problem, exit R and restart using the ORE script. After restarting R and running the command to load the ORE packages, you should not receive any errors.

R> library(ORE)

On Windows servers, the solution is to make the location of the ORE packages visible to R by adding them to the R library paths. To accomplish this, exit R, then add the following lines to the .Rprofile file. On Windows, the .Rprofile file is located in
R\etc directory C:\Program Files\R\R-<version>\etcAdd the following lines:

.libPaths("<path to $ORACLE_HOME>/R/library")

The above line will tell R to include the R directory in the Oracle home as part of its search path. When you start R, the path above will be included, and future R package installations will also be saved to $ORACLE_HOME/R/library. This path should be writable by the user oracle, or the userid for the DBA tasked with installing R packages.

Binary package compiled with different version of R

By default, R will install pre-compiled versions of packages if they are found. If the version of R under which the package was compiled does not match your installed version of R you will get an error message:

Warning message: package ‘xxx’ was built under R version 3.0.0

The solution is to download the package source and build it for your version of R.

$ wget
$ R CMD INSTALL arules_1.1-1.tar.gz

For use with ORE:

$ ORE CMD INSTALL arules_1.1-1.tar.gz

Unable to execute files in /tmp directory

By default, R uses the /tmp directory to install packages. On security conscious machines, the /tmp directory is often marked as "noexec" in the /etc/fstab file. This means that no file under /tmp can ever be executed, and users who attempt to install R package will receive an error:

ERROR: 'configure' exists but is not executable -- see the 'R Installation and Administration Manual’

The solution is to set the TMP and TMPDIR environment variables to a location which R will use as the compilation directory. For example:

$ mkdir <some path>/tmp
$ export TMPDIR= <some path>/tmp
$ export TMP= <some path>/tmp

This error typically appears on Linux client machines and not database servers, as Oracle Database writes to the value of the 
TMP environment variable for several tasks, including holding temporary files during database installation.

7. Creating your own R package

Creating your own package and submitting to CRAN is for advanced users, but it is not difficult. The procedure to follow, along with details of R's package system, is detailed in the
Writing R Extensions manual.

Sunday Dec 29, 2013

FAQ: Oracle R Enterprise and External Procedures

Oracle R Enterprise uses external procedures in Oracle Database to support embedded R execution. An external procedure, or extproc, is a procedure stored in a shared library that is called to perform special-purpose processing.  When ORE invokes an external procedure, Oracle Database starts an extproc agent and passes instructions to the agent for executing the procedure. The agent loads an ORE shared library or DLL, runs the external procedure in the database, and passes back the values returned by the external procedure to ORE.

With Oracle 11g, this all happens behind the scenes because the default configuration for extproc works out of the box. Occasionally, users experience problems with external procedures on their system or wish to modify configuration parameters. In this post, we've compiled the most commonly asked questions regarding external procedures with ORE.

1. How do I configure extproc for use with Oracle R Enterprise?

When you use the default configuration for external procedures, the extproc agent is spawned directly by Oracle Database and no listener is involved as it was for previous RDBMS versions. The parameters for external procedures may be configured by modifying the extproc.ora file located in the $ORACLE_HOME/hs/admin directory. For example, you may want to restrict extproc to certain libraries or specify environment variables for the extproc agent. Refer to the configuration parameters detailed in the Oracle Database Net Services Administrator's Guide for details.

2. When I try to use embedded R execution in Oracle R Enterprise, I receive the error: ORA-28575: unable to open RPC connection to external procedure agent.

In general, this error indicates that extproc did not succeed.  To start, this simple program will verify if extproc is working in Oracle Database independently of Oracle R Enterprise.

a. Create a C file test.c with the following:

  #include <stdio.h>
  #include <sys/types.h>
  #include <unistd.h>
  #include <stdlib.h>
  int negative(char* db, int n)
        return -1*n;

b. Create a shared library test.so by running:

  $ gcc -shared -fPIC -o test.so test.c

Copy the resulting shared library, test.so to $ORACLE_HOME/bin.

c. Grant dba privileges to scott

  $sqplus / as sysdba
  SQL> grant dba to scott;

d. Create an external procedure library test:

  $sqlplus scott/tiger

e.  Create function negative_it to run in the external procedure:

       LIBRARY test
       NAME "negative"

f.  If extproc is working properly, the following value will be returned from the function:

  SQL> select negative_it('dummy', 1234) from dual;

If extproc is working correctly outside of Oracle R Enterprise, the above error may be caused by any of the following:

  • networking layer issues
  • incorrect listener configuration (if the default configuration is not being used)
  • the Oracle R Enterprise user has not been granted RQADMIN role (required for running embedded R)

Users are advised to refer to My Oracle Support for assistance with networking issues.  For listener configuration issues, consult "Configuring Oracle Net Services for External Procedures" in the Oracle Database Net Services Administrator's Guide for the required parameters. Refer to the Oracle R Installation and Administration Guide for information on roles and grants for ORE users.

3. How can I restrict external procedure calls to use Oracle R Enterprise only?

By default, extproc supports any external procedure call.  To maximize security, you may want to allow only external procedure calls for Oracle R Enterprise. To do this, edit the EXTPROC_DLLS environment variable in $ORACLE_HOME/hs/admin/extproc.ora.

The following statement on a Linux or UNIX system sets EXTPROC_DLLS to execute only external procedures for Oracle R Enterprise:


On Windows, the equivalent statement is:


To allow extproc to service any external procedure, set EXTPROC_DLLS=ANY or simply leave it blank (the default). 

5. I've configured Oracle Wallet for use with Oracle R Enterprise, but when I attempt to connect to Oracle Database my session hangs.

This may be caused by specifying SQLNET.WALLET_OVERRIDE=TRUE in the sqlnet.ora configuration file.  This file is located in: $ORACLE_HOME/network/admin/sqlnet.ora:

       (SOURCE = (METHOD = FILE)
       (METHOD_DATA =
       (DIRECTORY = /u01/app/oracle/product/wallet)))

For Oracle Wallet clients wanting to override Operating System credentials for database authentication, SQLNET.WALLET_OVERRIDE can be set to TRUE. The default value for SQLNET.WALLET_OVERRIDE is FALSE, allowing standard use of authentication credentials.

Because setting SQLNET.WALLET_OVERRIDE=TRUE overrides Operating System authentication, the database does not recognize the user attempting to execute the external procedure and extproc fails, causing the hanging behavior. This can be solved by creating a userid and password when creating a password store for the Oracle Wallet client.

Note: The advice in this post applies only if the default Oracle server configuration for extproc is in use.  If the Oracle listener is configured for extproc, the listener settings will override the default configuration. See the Oracle Database Net Services Reference Guide for details.

Thursday Oct 17, 2013

ORE graphics using Remote Desktop Protocol

Oracle R Enterprise graphics are returned as raster, or bitmap graphics. Raster images consist of tiny squares of color information referred to as pixels that form points of color to create a complete image. Plots that contain raster images render quickly in R and create small, high-quality exported image files in a wide variety of formats.

However, it is a known issue that the rendering of raster images can be problematic when creating graphics using a Remote Desktop connection. Raster images do not display in the windows device using Remote Desktop under the default settings. This happens because Remote Desktop restricts the number of colors when connecting to a Windows machine to 16 bits per pixel, and interpolating raster graphics requires many colors, at least 32 bits per pixel..

For example, this simple embedded R image plot will be returned in a raster-based format using a standalone Windows machine:

 R> library(ORE)
 R> ore.connect(user="rquser", sid="orcl", host="localhost", password="rquser", all=TRUE)
 R> ore.doEval(function() image(volcano, col=terrain.colors(30)))

Here, we first load the ORE packages and connect to the database instance using database login credentials. The ore.doEval function executes the R code within the database embedded R engine and returns the image back to the client R session.

Over a Remote Desktop connection under the default settings, this graph will appear blank due to the restricted number of colors. Users who encounter this issue have two options to display ORE graphics over Remote Desktop: either raise Remote Desktop's Color Depth or direct the plot output to an alternate device.

Option #1: Raise Remote Desktop Color Depth setting

In a Remote Desktop session, all environment variables, including display variables determining Color Depth, are determined by the RCP-Tcp connection settings. For example, users can reduce the Color Depth when connecting over a slow connection. The different settings are 15 bits, 16 bits, 24 bits, or 32 bits per pixel. To raise the Remote Desktop color depth:

On the Windows server, launch Remote Desktop Session Host Configuration from the Accessories menu.
Under Connections, right click on RDP-Tcp and select Properties.
On the Client Settings tab either uncheck LimitMaximum Color Depth or set it to 32 bits per pixel.

Click Apply, then OK, log out of the remote session and reconnect.

After reconnecting, the Color Depth on the Display tab will be set to 32 bits per pixel.  Raster graphics will now display as expected. For ORE users, the increased color depth results in slightly reduced performance during plot creation, but the graph will be created instead of displaying an empty plot.

Option #2: Direct plot output to alternate device

Plotting to a non-windows device is a good option if it's not possible to increase Remote Desktop Color Depth, or if performance is degraded when creating the graph. Several device drivers are available for off-screen graphics in R, such as postscript, pdf, and png. On-screen devices include windows, X11 and Cairo.

Here we output to the Cairo device to render an on-screen raster graphic.  The grid.raster function in the grid package is analogous to other grid graphical primitives - it draws a raster image within the current plot's grid.

 R> options(device = "CairoWin") # use Cairo device for plotting during the session
 R> library(Cairo) # load Cairo, grid and png libraries
 R> library(grid)
 R> library(png)
 R> res <- ore.doEval(function()image(volcano,col=terrain.colors(30))) # create embedded R plot
 R> img <- ore.pull(res, graphics = TRUE)$img[[1]] # extract image
 R> grid.raster(as.raster(readPNG(img)), interpolate = FALSE) # generate raster graph
 R> dev.off() # turn off first device


By default, the
interpolate argument to grid.raster is TRUE, which means that what is actually drawn by R is a linear interpolation of the pixels in the original image. Setting interpolate to FALSE uses a sample from the pixels in the original image.

A list of graphics devices available in R can be found in the Devices help file from the grDevices package:

R> help(Devices)

Monday Jul 08, 2013

Accessing Data from Multiple Schemas using Oracle R Enterprise

The most common Oracle R Enterprise configuration is to connect directly to a database schema that contains tables you wish to analyze. However, users may occasionally need to access tables that exist in other schemas. Oracle R Enterprise allows several options when accessing tables from another schema is desired. Database tables and views are currently supported, and these form the basis for our recommendations.

Named Schema Access

If you have SELECT TABLE or SELECT ANY TABLE privilege on tables in another schema, you can access these tables after connecting to the database with your own schema credentials. The function ore.sync synchronizes database table and view metadata with the R client environment. For example, by setting schema to “user2”, user1 will see all of user2's tables on which user1 has been granted access:

R> library(ORE)
R> ore.connect(user="user1", sid="sid", host="hostname", password="password")
R> ore.sync(schema = "user2", table="myTable")
R> ore.attach(schema = "user2")
R> ore.ls()
[1] "myTable" 

Here, we combine the schema and table arguments to look at a specific table, but this can be omitted to access all tables available in schema "user2" at once:

R> ore.sync(schema = "user2")
R> ore.ls()
  [1] "myTable" "anotherTable"

Accessing a materialized table typically offers the best query performance for operations such as joins, however in 
other cases, such as calculating simple summaries, the performance advantage may be negligible.

Create Views in Local Schema

Another option is to map views in your own schema to the tables or views in the another schema. You can restrict users to the view instead of the underlying table, thereby enhancing security, and also include in the view only those columns needed. For example, if a user exports the contents of a carefully defined view, they will see only the table columns selected by the view - no unselected columns, unique identifiers or table keys. Views also simplify the user experience by exposing only those database tables the user can or should access. The only catch when using views is that you must update those views if the underlying tables or views change.

Provided you've been granted CREATE VIEW privilege and SELECT TABLE access, use the ore.exec function to execute the SQL statement that will create the view from the R client

R> library(ORE)
R> ore.connect(user="user1", sid="sid", host="hostname", password="password")
R> ore.exec("create view myView as select * from user2.myTable")
R> ore.sync(table = "myView")
  [1] "myView" 

The code above assumes you already have privileges to access the table or view. If you do not, log in as sysdba or to the schema of interest in invoke:

SQL> grant select on MYTABLE to user1;

Oracle Wallet

Password credentials for connecting to databases can be stored in a client-side Oracle Wallet, a container used to encrypt authentication credentials. The contents of the wallet are not readable, eliminating the need to expose schema credentials when connecting to the database.  Security risks are reduced because such passwords are not exposed in clear text. Oracle R Enterprise 1.3 and later is integrated with Oracle Wallet, providing a secure way for R scripts to avoid storing passwords in the script. For detailed information about creating wallets, see Oracle Database Advanced Security Administrator's GuideSteps for using Oracle Wallet with Oracle R Enterprise are provided in the Oracle R Enterprise Installation and Administration Guide.

If you have a creative technique for accessing data across schemas or other platforms, please recommend it in the blog comments, along with any opinions you have on these approaches.

Friday May 24, 2013

HOWTO: X11 Forwarding for Oracle R Enterprise

Oracle R Enterprise enables users to generate R graphs at the database server and return them in a variety of ways: an XML representation using base 64 encoding of the PNG images, in a table with a BLOB column containing the PNG images, and interactively returning the actual image to the R user at the client. This last case allows users to generate images at the database server machine and have the actual PNG image display at the user’s client R engine.

To take advantage of this capability, users may need to ensure their X11 is properly configured. This blog highlights a solution to a common problem involving X11. W
hen using a graphically based function in Oracle R Enterprise, if you’ve encountered errors such as:

Error in X11(paste("png::", filename, sep = ""), width, height, pointsize,
unable to start device PNG
then read on. The issue is likely that your database server is not configured to run graphics programs locally. 

The X Window system, or X11, allows you to forward a program display from a remote system to a local computer.  X11 is the native windowing interface on Linux However, X11 is not the default for all Unix Operating Systems, and  additional configuration steps may be required to display graphical programs if your server is running Unix. Follow the instructions below to configure your server to forward graphics the display to your local client machine.

X11 forwarding from a Linux client

There are two options presented here. The first uses SSH and the second uses telnet.

Option 1: Usually, when you want to connect to your Unix server from a remote Linux client, you use SSH (Secure Shell). Before logging in to your Unix server, confirm that /etc/ssh/sshd_config contains the following X11 tunneling options:

X11forwarding yes

X11DisplayOffset 10
X11UseLocalhost yes

SSH allows you to make a secure terminal connection to your Unix server from your Linux client using this syntax:

ssh -Y <userid@unixserver>

The –Y option to ssh treats the Unix server as trusted , -X treats it as untrusted. Check with your server or network admin about which flag to use. This command also sets the remote DISPLAY to localhost:10.0.

Option 2: Connecting to the server via telnet

If you choose to connect to the server using telnet, keep in mind that unlike SSH, telnet does not offer the security measures that protect users against anyone with malicious intent. Using telnet, an X11 server can be manually set at a Linux client that is capable of graphical display.
To confirm the graphical capability, verify that a terminal appears after entering at the Linux prompt:


You also need to know the display environment variable setting on X11 server, the Linux client:


The DISPLAY environment variable stores the displaynumber and screennumber that the X11 server uses to display. These addresses are in the form:


A typical example would be:


Next, enable the Unix server to display on the Linux client:

xhost + <unixserver >

and telnet into the Unix server and set its DISPLAY to the X11 server – the Linux client.

export DISPLAY= X11server:displaynumber.screennumber

After following the steps for either option, you should now be able to launch a remote graphical application locally.  As a quick check, launch your remote Unix server's clock on your client desktop through the SSH connection using X11 forwarding:

1. Type xclock at the Unix server command prompt and hit enter.
2  Your remote server’s X11 GUI clock should appear on your client desktop.

3. If the xclock tests succeeds, launch the ORE client to verify the same DISPLAY setting is used by embedded R:

R> ore.connect(user="<username>",sid="<sid>",host="<hostname>",password="<password>", all=TRUE)
R> ore.is.connected()

> ore.eval(function() Sys.getenv("DISPLAY"), ore.graphics=FALSE)

If the last returned value matches the DISPLAY setting, you will be able to display images at the client machine.
X11 forwarding from a Windows client

To connect to your remote Unix server from Windows and use its graphical interface, you need two pieces of software: an SSH program to establish the remote connection and an X Server to handle the local display. For the SSH program we'll use PuTTY. For the server, we'll use Xming.

PuTTY is a free SSH client that allows you to connect to a remote Linux computer and use the command line. PuTTY can also be used to forward secure data over SSH to other programs - this is called tunneling.

When you connect to your remote Linux computer, you will need to set several connection settings to make everything work correctly. PuTTY lets you save these settings in a session so you can reuse them the next time you connect. To create a session that allows PuTTY to forward your Linux computer's X11 graphical interface over SSH:

1. Open PuTTY on your Windows desktop. Putty will open and display the Session panel. In the Host Name field, type the hostname or IP address of your Unix server.

2. In the field underneath the Saved Sessions label, type a name for your saved session.

3. Under the Connection category, expand SSH and choose X11. Click the Enable X11
Forwarding checkbox.

4. Go back to the Session category and click Save to save your session connection settings.

 Now we're ready to set up the X server using Xming, which is a free X Window server for the Windows desktop. With Xming, you can display graphical applications from your remote Linux computer on your Windows desktop. Xming provides a simple utility called Xlaunch that allows you to configure Xming easily, and also save your configuration for future use. To run Xming, open XLaunch and select the configuration outlined here:

1. Open XLaunch from the program menu. Select Multiple Windows and click Next. This tells Xming to open
each remote Linux application in a new window.

2. Select Start No Client and click Next. This tells Xming to launch and wait for commands from
another program (like PuTTY).

3. Make sure that Clipboard is selected and click Next. This tells Xming to enable your remote
Linux applications to share a unified clipboard.

4. Click the Finish button to launch Xming.

Now that Xming is running, you can open your PuTTY session and launch a graphical application. As a quick check, launch your remote Unix server’s clock on your Windows desktop through the SSH connection using X11 forwarding:

1. Open PuTTY.
2. Double-click on the saved session you created earlier. PuTTY will create an SSH connection to your remote Unix server.
3. Login to your Unix server.
4. Type xclock at the command prompt and hit enter.
5. Your remote server’s GUI clock should appear on your client desktop.

6. If the xclock test succeeds, If the xclock tests succeeds, launch the ORE client to verify the same DISPLAY setting is used by embedded R:

R> ore.connect(user="<username>",sid="<sid>",host="<hostname>",password="<password>", all=TRUE)
R> ore.is.connected()

> ore.eval(function() Sys.getenv("DISPLAY"), ore.graphics=FALSE)

If the last returned value matches the DISPLAY setting, you will be able to display images at the client machine.  Here's an example that creates a panel plot using the R dataset mtcars:

ore.doEval(function() {
  xyplot(mpg ~ hp | factor(cyl),
         type=c("p", "r"),
         main="Fuel economy vs. Performance with Number of Cylinders",
         xlab="Performance (horse power)",
         ylab="Fuel economy (miles per gallon)",


The place for best practices, tips, and tricks for applying Oracle R Enterprise, Oracle R Distribution, ROracle, and Oracle R Advanced Analytics for Hadoop in both traditional and Big Data environments.


« July 2016