Hi Anderson,
Check use the SQL below to check if the System user is locked or not (with another user):
select * from sys.INVALID_CONNECT_ATTEMPTS where user_name='SYSTEM'
Then execute the activities if locked mentioned in note 2251556 - SAP HANA SYSTEM user can now be locked for too many failed logon attempts
To unlock the SYSTEM user that was locked after <maximum_invalid_connect_attempts> (default 5 times), run this SQL statement: ALTER USER SYSTEM RESET CONNECT ATTEMPTS
Regards,
Ning
Hello Alex,
for the HANA repository you can check the REST File API.
For XS Advanced scenarios (if you plan to switch to at some time), where you don't use the HANA repository anymore, you can interact with your Git.
Regards,
Florian
We had the same roll (sap.hana.admin.cockpit.sysdb.roles::SysDBAdmin) missing after MDC conversion. I noticed that when I do a clean install with the MDC option you get the role. So there is a bug in the MDC conversion.
To solve the issue I exported the HANA_SYS_ADMIN delivery unit from the clean installed MDC system and imported it in converted MDC system. The role is in the delivery unit. The problem was solved.
Regards,
Floris
Wild guess, but do you have an application connected to HANA? Have you checked the hdbuserstore? try resetting the hdbuserstore:
Hi,
Have you tried logging in via the HANA Studio as another user account, for example SAPABAP1 or SAPJAVA1 as appropriate? Thereafter you can check whether the SYSTEM account is locked.
Regards,
Graham
Hello Florian,
thanks for the fast answer. Yes I think the rest file api is a good choice for my need. I will do a small PoC to see if everything is working in the way I am thinking and I will come back with the conclusion.
Thanks again,
Alex
Dear Ulrich,
Thanks for your detailed response on the profile parameters to be taken care before installing fresh PAS on a new OS.
Regards,
Nisheeth
Hello Bhavik,
These rules are defining the virtual hostname to be used to access the HANA WD for each HANA container (through the HTTP header named "HOST").
It seems that we were at the right track already.
The SiteMinder has to do this as well (set the HTTP header "HOST" to the virtual hostname of the particular HANA container it is forwarding the request to).
In other words, if the SiteMinder received a request that is related to the HANA container MNN (using your last reply for the example), the SiteMinder has to set the HTTP header "HOST" with the value "vlmhst001-mnn.domain.com".
This is how the HANA WD will identify the correct HANA container to handle the request (through the HTTP header named "HOST").
Regards,
Isaías
Does it mean, that is the only way to do it?
Or anything can be changed at HANA side so that we do not have to do this rules? (Asking to see if SiteMinder folks says that it would not be possible)
-Bhavik
Hello Bhavik,
You could change the HANA WD settings as well.
Instead of using the hostname to identify the correct HANA container, the HANA WD could be configured to open multiple ports (one port for each HANA container, instead of one hostname to each HANA container).
Then, SiteMinder would have to be adjusted as well.
But instead of setting the HTTP header HOST, it would have to send the connection to the correct port.
Regards,
Isaías
This is resolved as this turned out to be a issue with the removing un-necessary - files from the backup directory.
Regards,
Abhinav
Hi Team ,
I am trying to recover a SAP HANA database from from production to the test landscape.
My Prd system is having a Master node & stanby node. While that in test only one.
I am trying to do a point in time recovery by copying the log files also.
Why doing the recovery using the Hana studio , I am getting the topology error
regarding mismatch in the services.
Both source & target system are on SP10.
Regards ,
Abhinav
Hello,
Can you please show me the exact error you are seeing.
Hello,
I had the same issue, in the "join 6" and resolved it the following way:
Now, the SPRAS is gone and you can reactivate the view and use it. However, when you will close and reopen the view for edititon, the SPRAS will be back and you'll have to redo the same steps before being able to reactivate.
Strange bug...
Hi
What's the error details in backup.log file ? From your description, it seems there is a mismatch in topology. As your Q doesn't have any standby node, the total number of active services must be different. This error would come if the number of services having persistence in source is not matching with target. You can find that from VOLUMES tab in Studio. If they are more than target, then the extra services need to be created in target before starting recovery. Those can be deleted later in target after successful recovery.
Thanks,
Hi Lucas,
Thanks !!
We will check if the above issue is happening in HANA SPS 11 system and let you know after the test.
Regards,
Jeswanth
Thanks Michael / Chinmaya ,
This is was resolved as I was not setting the option to initialize the log area while doing the system recovery.
Regards ,
Abhhav
Hello All,
We are planning to install Suite on HANA & would like to have some suggestions if there are any restrictions to the below approach -
The blue box in the above image would be our HANA TDI / HANA appliance.
The white box represents a HANA DBMS installation.
The black box represents a HANA Multi-tenant DB.
As per our approach, we would like to use one of our HANA TDI / HANA appliance to run 2 Production Databases in multi-tenant installation, ex. PRD1 & PRD2.
The other HANA TDI / HANA appliance would mainly be used to run 4 Non-Productive Databases in multi-tenant installation, ex. DEV1, DEV2, QAS1 & QAS2.
As we need to configure DR scenario for our PRD Databases, we need to configure System Replication between the 2 HANA TDI / appliance.
As system replication is not possible for individual Multi-tenant DBs, we would need to install another HANA DBMS on Non-Prod TDI which could host the multi-tenant DBs for Production system replication.
Is there are restriction to this approach, mainly due to a combination of MCOS & multi-tenant DB on Non-Prod TDI / appliance?
Thanks & Best Regards,
Tanmeya
Hi,
Normaly if you would create just a calculated column on the bottom level projection(if you have one) as $$name_of_flowgraph_variable$$. Then just on the level above filter data set using the expression conditions.
In other words I would not reccomend process logic of calculated columns on the same node where you created it.
Thanks,
Andrew