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

Hi ,

We are currently using SAS base 9.1.3 (TS1M3) SP 4. I plan to apply the following three SAS base hot fix bundles ;

E9bd61

E9bd42

E9bd48

In our environment each of the virtual servers e.g Application , Meta , Web app etc are deployed on different physical machines.In light of above i have the following concerns;

1. What are the precautionary steps which need to be taken before installing the hot fixes i.e. do i need to take any back ups (the installation file of the hot fix bundles just states that i turn off all SA services before installation)

2. Do i need to apply the SAS base hotfixes on all four physical servers individually or just the  SAS application server?

3. Any possible risks involved in installing the hot fix bundles and mitigation for the same.


Good Day,

Taskeen Fatima



1 ACCEPTED SOLUTION

Accepted Solutions
Taskeen
Calcite | Level 5

Thank you Jaap for all the suggestions and insights.

I selected just the above three hot fixes since the issue we were facing was being catered for in one of these and the other two were a pre-req for installing the former one. Also, since we have a miration plan in place already (from 9.1.3 to 9.2) thus i didnot want to go for 'install all available fixes' approach and was more surgical and only selected the ones which catered the issue being faced.

I actually went ahaed with the hot-fix installation which went smoothly and resolved the issue. I basically only followed the guidelines/notes which comes with the hot-fix bunlde file.The installation was performed in the following steps:

- took a backup of Metada (the installation guide didnot say that , i took it just to be on the safe side)

- Shut down all sas services, spwaners, user sessions and sas exes from task manager.

- the hot-fix bundles where self extracting executables , executed in form of simple step by step wizards.

- the bundles were executed on all machines which had SAS Base installaed on them (since the hot fixes were for SAS Base, in our case the webapp server is installed on a separate machine which didnot have sas base installed on it and hence no need to run the hot-fixes on that machine)

- Started the services back up and the issue was resloved.

A lilttle about the issue faced: Our production dwh is Teradata; when a PROC SQL was executed , certain column names were assigned wrong aliases while query generation at SAS end (I got to know that the issue was actually with the aliases by  running the PROC SQL in SASBase with adding the following before the LIBNAME:

options Locale=en_US;

option sastrace=',,,d'

sastraceloc=saslog no$stsuffix;

and using PROC SQL_method instead of PROC SQL

)

the above showed the step by step queries as generated by SAS and thrown on TD and the resulting errors.  

View solution in original post

2 REPLIES 2
jakarman
Barite | Level 11


Your question is really hitting some fundamental in change management. When you have grown up in IT and being comfortable with strict procedures, regression tests, user acceptance tests fall back scenario’s etc. , the SAS approach can be really embarrassing.
The only thing you will find is run a program and have luck.

With SAS9.2 and later there is tool SASHFADD that should improve that part of the process.
With 9.3 I have seen the updates are registered in xml files within the installation location. That location is indicated as “Sasroot”.
With 9.1.3 and older releases the fix (and installation) process is even more dependent of the one doing this. The registration of fixes is maintained at the installers key home location (unix), or profile/my-documents (windows).   

The issues:
- Do you want to be able to go back (fall-back)? All backup/restore work to be designed/tested by yourself
- Are all files open the to fix process (ownership).  With Unix that could be “sasinst”. There are some files needed to be owned by “root” (Master Admin account). When hitting those you can have an issue. To my frustration this requirement was not documented (got blocked).
- You are mentioning just 3 fixes and not all previous, newer ones or the possible related ones. In the ancient times a Fix was something additional code very related to a one single module. When you see the unpacking you will find now bigger bundles of collected modules.
It makes more sense now to bring all fixes in to specific moment to be sure not missing dependicies. That is the promise of sashfadd. You are also seeing fixes getting obsolete.
Making a call to TS my experience is the asking for applying all fixes to the last level when there is no easy solution found.

- Just Base updates needed? Not any other in some additional one like SAS/connect?
This one was one I have hit and was not documented.
http://ftp.sas.com/techsup/download/hotfix/e9_sbcs_prod_list.html#ct The updated part E9BD59 has a connection with e9bd…  By that 
- It will be really troublesome when a fix is hitting many part of the multi-tiers.  Some fixes are updating just one part. Others several in them at the same time.
- Having manual updates done?  It is possible an fix-update will eliminate that.
- Solutions are based on BI/DI. When they are present you can get a different requirement
Checking the impact of fixes is part of the game.

Mitigations:
As started when you are used to change-process with Infra-components you can mitigate that with the following stepped approach.
a/ Having an Installation-test machine environment, test it here as much as possible and document what and how it is done.
b/ Can have multiple machine environments
b1/ Having a machine-environment for Developers/testers roll out there and let them use/test the infra changes. Let those developers/testers test and accept your changes
b2/ Having a machine-environment for user-acceptance testing or as production-shadow with open time intervals.  Roll out on these machines and let those people test and accept your change.
c/ Plan your roll-out in production. Real surprises should not happen but for sure take some host stand-by period to be able react fast.           
    

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

Thank you Jaap for all the suggestions and insights.

I selected just the above three hot fixes since the issue we were facing was being catered for in one of these and the other two were a pre-req for installing the former one. Also, since we have a miration plan in place already (from 9.1.3 to 9.2) thus i didnot want to go for 'install all available fixes' approach and was more surgical and only selected the ones which catered the issue being faced.

I actually went ahaed with the hot-fix installation which went smoothly and resolved the issue. I basically only followed the guidelines/notes which comes with the hot-fix bunlde file.The installation was performed in the following steps:

- took a backup of Metada (the installation guide didnot say that , i took it just to be on the safe side)

- Shut down all sas services, spwaners, user sessions and sas exes from task manager.

- the hot-fix bundles where self extracting executables , executed in form of simple step by step wizards.

- the bundles were executed on all machines which had SAS Base installaed on them (since the hot fixes were for SAS Base, in our case the webapp server is installed on a separate machine which didnot have sas base installed on it and hence no need to run the hot-fixes on that machine)

- Started the services back up and the issue was resloved.

A lilttle about the issue faced: Our production dwh is Teradata; when a PROC SQL was executed , certain column names were assigned wrong aliases while query generation at SAS end (I got to know that the issue was actually with the aliases by  running the PROC SQL in SASBase with adding the following before the LIBNAME:

options Locale=en_US;

option sastrace=',,,d'

sastraceloc=saslog no$stsuffix;

and using PROC SQL_method instead of PROC SQL

)

the above showed the step by step queries as generated by SAS and thrown on TD and the resulting errors.  

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
  • 2 replies
  • 1301 views
  • 2 likes
  • 2 in conversation