WhereScape Versions

WhereScape RED has a four part version number normally shown as xx.xx.xx.xx. An example of this may be 8.3.1.0. The first number represents the major release. The second number represents the metadata repository version. The third and fourth numbers relate to application specific releases.
From the example above, we see that the current version is version 8 of WhereScape RED. We are on version 8.3 of the metadata repository.

Metadata Changes

A change from a 8.2.. release to a 8.3.. release would indicate a change in the metadata tables. All metadata changes are non-destructive. They simply add new columns or new meta tables. In this way they can be applied without harming an existing metadata repository. The impact of a metadata change is that the associated applications (namely the RED executable, the Scheduler, security module, etc.) needs to be at the same metadata version. Therefore, an 8.2.1.0 version of RED may not successfully run against a version 8.3 metadata repository.

Application changes

The final two numbers in the version represent application releases. Applications are deemed to be all of the executable images supplied with WhereScape RED as well as the UNIX scheduler scripts and the stored procedures. Application changes reflect enhancements and bug fixes. A change in the first number indicates a major enhancement in one of the application components.

Upgrading RED

Notes

  • Ensure that you have made a backup your metadata before performing the upgrade.
  • Ensure you also upgrade the WhereScape RED scheduler. The old scheduler must be stopped prior to the upgrade and a new scheduler must be setup after RED is installed.

Upgrading WhereScape RED consists of the following steps:

  1. Allow any active jobs to complete. Halting active jobs will allow running tasks to complete with no new tasks starting. Aborting active jobs will kill any running tasks and stop running jobs.
  2. Stop all schedulers. Windows schedulers can be stopped with WhereScape's Setup Administrator. To stop a UNIX or Linux scheduler, kill the active scheduler process and comment their crontab entries (to stop the scheduler re-starting itself).
  3. Close any WhereScape programs that are running on your machine.
  4. Back up your metadata.
  5. Install the new version of RED on your machine.
  6. In RED Setup Administrator, select the Validate Metadata Repository option. This function may re-compile existing or create new metadata procedures; metadata tables may be altered, or new tables created.
  7. When performing an upgrade of RED:
    • Click  OK  when prompted to validate metadata tables.
    • Click  Yes  when prompted to re-create metadata views.
    • Click  Yes  when prompted to re-compile metadata procedures.

      Warning

      If the above steps are not all completed during an upgrade, the metadata may be left in an inconsistent state.

  8. For Oracle metadata updates, see the note below on  recompiling Oracle invalid procedures  during a RED upgrade.
  9. Back up your metadata again (just in case).
  10. If using a UNIX or Linux scheduler and this is a major application enhancement, then rename the wsl/bin directory to say wsl/bin_versionxxxxxx. Create a new bin directory and ftp over the files under the UNIX directory (see the main install instructions). Change the protections on the files (chmod 750 *.sh).
  11. Restart all schedulers. Windows schedulers can be restarted with WhereScape's Setup Administrator. For any UNIX or Linux schedulers, uncomment any commented out crontab entries— this is enough to restart the schedulers.
  12. Restart any halted or aborted jobs.

    Notes

      1. There are different versions of the scripts for each database and for UNIX versus Linux. You should also be looking in the sub directory with the highest version number . When using a UNIX/Linux scheduler for Oracle, it is recommended that users copy the new meta_backup_680.sh file to use Datapump's expdb/impd instead the deprecated exp/imp tools.
        This version uses the data pump export executables expdp/impdp. It assumes that the scheduler and the Oracle database reside on the same server.
      2. Metadata tables do not change between minor releases, but metadata procedure often and usually do change.
      3. RED will not let you sign into an old repository version using a newer version of RED.
      4. RED will let you sign into a new repository version using an older version of RED but it will warn you that this may potentially cause issues.
      5. It is very important when using the Windows scheduler to have the installed RED version on the scheduler server EXACTLY matching the stored procedures.
      6. Side by side installations are possible (two versions in two directories on the same machine), but be careful with schedulers. If you install the new version of RED in a new directory, you must remove and reinstall all Windows schedulers in order for the scheduler(s) to use the new version of RED.
      7. As a general rule, the UNIX and Linux scheduler scripts, metadata tables/procedures and RED front end should all be in sync.
      8. If the scripts for the UNIX or Linux scheduler have changed, you should replace files in your old and new shell scripts in the WhereScape Program Files directory and see if any have changed.

    Oracle Invalid Procedures

    When validating an Oracle Metadata Repository, select the  Recompile any invalid procedures  check box to have any invalid user procedures recompiled during a metadata validate.

    Checking the Unix Connection

    Note

    This section applies to Oracle data warehouses only.

1. To check the UNIX connection, click the  Computer Setup  tab and then click  Check Unix Connection.


WhereScape RED can allow the user to browse a Unix file system and utilize the drag and drop functionality to setup the loading of files from a Unix file system. It can also perform interactive file loads. To facilitate this and to obviate the need to port code to every Unix environment the Telnet protocol is used for the Unix connectivity.
This step is not necessary for the successful running of a Unix based data warehouse environment. As mentioned above it is provided to simplify the process of setting up the loading of Unix files. This step is totally unnecessary for a Windows based data warehouse environment.
If you want to use these Unix drag and drop assistants, then consult the  WhereScapeRED User Guide  for an explanation of Unix connections and perform the following tasks:

1. Identify a Unix user that allows direct logon to a Unix shell prompt without passing through a menu system.

2. Ensure that the Unix user has the Oracle 'sqlldr' program in the path after a normal logon. If not, then interactive loads will not be possible. Scheduled loads should still function correctly.

3. Complete the dialog box presented, specifying the Unix user and password identified in step (1).

4. Click  OK  to proceed. A timeout of 20 seconds is enabled, so that if connection is not achieved within that time the process will terminate. The Telnet window will be displayed to assist in debugging any problems. It will be closed on completion or timeout.

5. Review the results and attempt to address any problems. A file called 'WslTelnet.log' is created in the installation directory containing the full dialog of the connection attempt. The message 'Telnet connection worked. All OK' will be displayed if the connection worked. If successful record the parameters used as these will need to be defined when setting up a Connection within WhereScape RED itself. If a connection cannot be achieved, then remove all reference to a username and password from the file mentioned above and mail it to support@wherescape.com.

Testing an ODBC Source

1. To test an ODBC source, click the  Computer Setup  tab and then click  Test ODBC Source.

2. Select the  ODBC connection  from the drop-down list and enter the  User Name  and  Password.

    • Click  OK.

3. If the logon using the ODBC connection was successful, the following message is displayed.

  • No labels