Hi Lars, thanks for your input. I apologize if I haven't made my point clear:
Well, "DSOD_MQ" is not some HANA built-in schema.
It's a user defined schema, so how should we know about it?
As a matter of fact, it comes with Hana One. I've made a brand new AWS Hana instance today:
hdbsql HDB=> \ds
List of database schemas
| Schema name | Owner name |
| ----------------- | ----------------- |
| DSOD | DSOD |
| DSOD_MQ | DSOD_MQ |
| DSREPO1PRODUCTION | DSREPO1PRODUCTION |
| DSREPO1SANDBOX | DSREPO1SANDBOX |
| HCI_ADMIN | HCI_ADMIN |
| HCI_SITEADMIN | HCI_SITEADMIN |
| SAP_HANA_EPM_DEMO | _SYS_REPO |
| SAP_XS_LM | _SYS_REPO |
| SYS | SYS |
| SYSTEM | SYSTEM |
...
hdbsql HDB=> \dt dsod_mq.%
List of tables
| Schema | Name |
| ------- | ------------- |
| DSOD_MQ | ACTIVEMQ_ACKS |
| DSOD_MQ | ACTIVEMQ_LOCK |
| DSOD_MQ | ACTIVEMQ_MSGS |
I simply assume this is something completely unrelated to my queries, there are currently no locks in this schema.
Also, why don't you have a look into the table? Or at least into M_RECORD_LOCKS or M_TABLE_LOCKS so that we can find out about the locked records?
I've included the contents of M_OBJECT_LOCKS, I didn't know about M_TABLE_LOCKS, the docs do not mention it, but it contains the same locks anyway. In the new instance there are lots of rows in the M_RECORD_LOCKS, I'll have a look at it if it turns out this really is a locking problem (I'm inclined to believe it is not).
Besides, the lock got acquired by a session that logged on as SYSTEM user, which is really bad security wise and does a great job hiding the actual user.
You might want to check the session context for this session to find which APPLICATIONUSER is behind this session.
There are no actual users of this database, there is only this cron job that calls the stored procedure and a Panopticon server that displays the results. If there had been any actual users, I would have looked at them, sure. I haven't included the session data because there was nothing useful there, '?' for users in particular.
Anyway, the thing is, when I call the stored procedure, it hangs or maybe it is executing something, on the new instance I can see that hdbindexserver is using a lot of CPU time. Nevertheless, when I interrupt the stored procedure call with ^C, call ALTER SYSTEM CANCEL, cancel in HS or kill the client process, it has no impact on the session, locks and on the running hdbindexserver, HS still shows the session as RUNNING, the stored procedure call is still listed in M_PREPARED_STATEMENTS. I always have to restart Hana to get rid of them.
Is there a way to find out what is hdbindexserver doing right now? This stored procedure has worked for some weeks until yesterday and there were no changes in the code which leaves me puzzled why it should be orders of magnitude slower now.
Cheers,
-- Micha