AutoSys Workload Automation

Installing an new prod instance on Linux and we experience a failure during the installation input after providing the Primary Event server details.  The database check returns this error:

The tablespace name cannot be found in the Oracle database. Either
specify another tablespace name or click Back to the Primary Event
Server Properties panel, and then select Create the Tablespaces,
Database Users, and Roles to continue.
[ OK ]  [ Abort installation ] 

We have already run the waae_oracle.sql to create tablespace, users, roles.  Confirmed myself and with the DBA that the AEDB_DATA and AEDB_INDEX exist.  DBA compared good instance in Dev and saw no differences.  I verified connections from our app server to the Oracle DB using both aedbadmin and autosys DB user accounts.

We are following the same steps as we've done in building previous instances in Dev and QA.  We've not encountered this failure before.  The only recent impact to installs was the recent glibc update which I have accounted for using the existing KB (WAAE, WCC and Common Components installation failu - CA Knowledge )

There is no data in the installer log showing the failure.  Are there any debug options to use during the install?  Any suggestions would be appreciated.

Why SP5?!

They are on SP7

And SP6 CUM1 had all the fixes for 5

Steve C.

Nothing in this message is intended to constitute an electronic signature unless a specific statement to the contrary is included in this message.

Confidentiality Note: This message is intended only for the person or entity to which it is addressed. It may contain confidential and/or privileged material. Any review, transmission, dissemination or other use, or taking of any action in reliance upon this message by persons or entities other than the intended recipient is prohibited and may be unlawful. If you received this message in error, please contact the sender and delete it from your computer.

We are already running SP5 in Production & QA.  This is a migration to another data center so it was decided due to time not to change the version.  We have Dev already in and tested.  Need to expedite the prod move and app team testing by spinning up a new prod env.  Enough changes outside of Autosys that need to be accounted for that an upgrade isn't an option now - unless last resort.

Understood. if you have already created the tablespace then you need to skip that part in the install.

In certain situations, it is best to stay with what works and what is supported as in the old adage "if it ain't broke don't fix it".

Recently at a Client's, the upgrade was done to take Autosys 11.3 to 11.3.6.SP6 CUM1 and now every two weeks the scheduler either crashes or runs without processing the job schedule. So it is back to the old way of a weekly recycle [and outage, every outage is a deemed penalty] till CA comes up with a fix.

SP7 has so many good and new features - great!

The Agent Management feature is cool - but please take a look at Lisa D's post on another thread, it details the way this feature should have been released.

Another worthy thread is  Webmaster Jim's requests for the configuration items to be located in the Autosys configuration file vs. hidden in other profile settings.

I was hoping that CA would have got to basics like the above two and a 64-bit architecture first and then to the baubles. As for incorporating the SQL injection vulnerability fix in SP7 - kinda late for that as that vulnerability has been around for a long time.

But I digress and my apologies for hijacking this thread with my rant.

CA, please do not take offense, I mean for the better - many years back given the choice between BMC/TWS/AE, I threw in my lot with AE and got a start under the able tutelage of Steve C.... AE rules!

Best,

Chris  <CJ>

Chris,

make sure the upgrade and the reconcile worked. is it the as_server or the event_demon? 

CUM1 had our fix for the memory leak .. so I cannot believe you are crashing.. in my SBX I am completely thrashing SP6CUM1 and no issues.. we had issue with the upgrade from SP1->SP6 so obviously 11.3 to SP6 may have missed something.. are you running chase? look for too many rows error in as_server log. 

if you see oddments like that i can guarantee the upgrade didn't go all the way... open a ticket and Get Polanko/Venkat involved..

and always SPEAK Up if you think a direction is incorrect .. right is might.. 

Open that ticket Brother! 

Steve C.

I have not selected create the tablespaces, database users, and roles during installation.  I deselect that option.  I have always selected the second option to create/refresh the database objects.  Our DBA runs the waae_oracle.sql in advance.

I then enter the DB user/password information & name of the existing tablespace (AEDB_DATA).  It then generates the error mentioned in my original post.  Usually it proceeds right to the next setup screen without error.

Make sure he got the tablespace and index space correct. that he has the correct ID.

that you have tnsnames in place properly and check for bad characters. (we got hit with that)

Thats what i have at the top of my head. otherwise open a ticket. and explain upgrade isnt an option. 

;-)

Steve C.

Thanks Steve.  I checked the space set initially and it is correct (same as what we used previously).  The tnsnames file should be correct as I can validate a good connection using SQLPlus as both aedbadmin and autosys using tns info (user/password@TNSNAME).

I did open a case Monday but support is slow. Asking for info I provided initially, etc..  I've "raised a concern" and called our Acct rep to try and get traction.  Was hoping someone in the community ran into this before.

I get the same error when attempting the install from what will be our secondary app/Shadow Scheduler server as well.  If support helps find a fix i will post an update here.

understand sqlplus and the installer do things MUCH differently. so sqlplus in this case is not a good gauge.

same tnsnames file? check that first either a cat -vet on it or make sure its not all on one line.

The issue will most likely be with that or the schema you are connecting to itself. 

good luck

Steve C.

Steve - My SQLPlus test is using same TNS file.  I figured the installer is doing something "different".  Always seems to be the case...

File looks good in cat -vet.  No odd characters or spaces. Format is good.

Will request the DBA review again. 

Thanks for your input.

you are most welcome. 

Checked if the following grant is available for autosys/aedbadmin/ujoadmin(role)?

grant select on dba_tablespaces

Regards,

Chandru

'ujoadmin' is a role in the AEDB and needs to have the following permissions granted (if they do not exist):

GRANT ANALYZE ANY TO ujoadmin;

GRANT SELECT ON DBA_TABLESPACES TO ujoadmin;

Also, 'aedbadmin' needs the following permissions granted (if they do not exist):

GRANT ujoadmin TO aedbadmin;

Faouzia

please take a look at the following tecdocs

https://comm.support.ca.com/kb/cauajme10029-communication-attempt-with-ca-waae-application-server-failed/kb000031311

https://comm.support.ca.com/kb/ora01950-no-privileges-on-tablespace-aedbdata-during-upgrade-from-113x-to-1136-of-workload-automation-autosys-ae/kb000036920

Faouzia

Faouzia,

The DBA has verified the ujoadmin role and grants exist.  Our DBAs run the waae_oracle.sql prior to our installation.  We do not create the tablespaces, etc during installation.

The other articles don't really apply as one is for DB creation during the install and the other is an upgrade. Our installs are new and not an upgrade.

We are not seeing any ORA errors as the installation logs don't generate any useful information.  The install errors after entering the existing tablespace (AEDB_DATA) when inputting the information for our Primary Event server.  It's doing some background DB check but this is failing.  Though we can test and see the tablespaces using SQLPlus from our app server.

I have a case open and still working with CA Support.

Hi Eugene

We had some troubles in the past during Autosys installation with Oracle ASM.

See this url published on our site:

https://support.ca.com/us/download-center/problem-detail.html?docid=622859&productcd=ATSYS&problemnbr=4282 

In this post there is also a way to workaround the problem.

Regards

Jean Paul

Wanted to loop back after working with CA.  For some reason our install would not work when selecting the Oracle Managed Files (OMF) option.  Even though our DBAs confirmed this new DB environment was just like our previous ones. Also all DB users, roles, etc were as we had used previously.

Found out that at each point in the setup when entering information regarding DB it does a check (sqlplus) in the background to validate that info. I had thought that only the "tests" done during an install actually did any check.  Had presumed that no other checks were done until after selecting Install after the final review settings step.  CA was able to get a developer to confirm the hidden steps.  Also one problem is that these checks are not generating any log info which would have been helpful.

In the end I still do not know for sure why OMF fails when that is what our Oracle DBs are using.  In any case the installs did complete when leaving that setting at the default.  Haven't seen any issues with jobs or DB access.