BookmarkSubscribeRSS Feed
🔒 This topic is solved and locked. Need further help from the community? Please sign in and ask a new question.
CarlM
Calcite | Level 5

We have always upgraded by creating new zones and installing the new version or maintenance release.  Then we have to run both versions while we migrate and get ready for the switch.  This is a lot of work and takes a lot of resources.  Is there a supported upgrade path, or is a fresh install always required? 

It has become a issue going from SAS94M0 to SAS94M2.  Both of these releases take a lot of disk, CPU, and swap. At some point response time on a production system will be impacted and require more hardware.

Thanks Carl Mathews

University of Arkansas

1 ACCEPTED SOLUTION

Accepted Solutions
Mark_sas
SAS Employee

You can certainly upgrade "in-place" from one maintenance release of SAS to another (e.g., 9.4M0->9.4M2, 9.4M1->9.4M2, etc.).  Of course you're impacting your production environment while doing so, so appropriate care should be taken.  In such a situation, backups are essential as they are the only way to undo an upgrade-in-place.

Many users employ the upgrade-in-place approach on dev/test/staging systems prior to replicating the steps on a production system.  Others use a blue-green approach, where they'll upgrade their blue system in-place and then swap it with their production green system (which is subsequently upgraded in-place).  However these approaches obviously require the duplicate resources you're trying to avoid.


Register today and join us virtually on June 16!
sasglobalforum.com | #SASGF

View now: on-demand content for SAS users

View solution in original post

4 REPLIES 4
Mark_sas
SAS Employee

You can certainly upgrade "in-place" from one maintenance release of SAS to another (e.g., 9.4M0->9.4M2, 9.4M1->9.4M2, etc.).  Of course you're impacting your production environment while doing so, so appropriate care should be taken.  In such a situation, backups are essential as they are the only way to undo an upgrade-in-place.

Many users employ the upgrade-in-place approach on dev/test/staging systems prior to replicating the steps on a production system.  Others use a blue-green approach, where they'll upgrade their blue system in-place and then swap it with their production green system (which is subsequently upgraded in-place).  However these approaches obviously require the duplicate resources you're trying to avoid.


Register today and join us virtually on June 16!
sasglobalforum.com | #SASGF

View now: on-demand content for SAS users

jakarman
Barite | Level 11

When you are on Unix you could think on having the two versions existing on the same machine. The problem with Windows (server/desktop) is the Win-registry. However it still can be done._

The installation itself doesn't cost that much just dasd-space. The middletier is more the think about (more costly). 

It is about peacefull coexistence http://support.sas.com/rnd/migration/utility/upgrade.html when you would need multiple versions for a longer period on the same hardware.
Rrequirement: Separated sashome folders separated configs separated portnumbers. This is more planning and thinking.  

It will avoid having duplicated hardware and avoid the datasynchronisation problems when several versions are needing the same data.

---->-- ja karman --<-----
CarlM
Calcite | Level 5

Thanks for the helpful links -Carl

CarlM
Calcite | Level 5

Mark,

Thanks for the information. -Carl

suga badge.PNGThe SAS Users Group for Administrators (SUGA) is open to all SAS administrators and architects who install, update, manage or maintain a SAS deployment. 

Join SUGA 

CLI in SAS Viya

Learn how to install the SAS Viya CLI and a few commands you may find useful in this video by SAS’ Darrell Barton.

Find more tutorials on the SAS Users YouTube channel.

Discussion stats
  • 4 replies
  • 1463 views
  • 5 likes
  • 3 in conversation