Thursday, 13 December 2018

SQL1022C There is not enough memory available to process the command.

So this occurred again: -

2018-12-13- I64925F462           LEVEL: Event
PID     : 1476                 TID : 1488           PROC : db2syscs.exe
INSTANCE: DB2                  NODE : 000
EDUID   : 1488
FUNCTION: DB2 UDB, base sys utilities, DB2StartMain, probe:5792
          SQL1022C  There is not enough memory available to process the

following a similar experience a few years back: -

As with last time, this occurred after I switched a Windows server ( this time Windows 2012 R2 ) from a standalone server to an Active Directory domain controller.

This time around, I think I fixed it more quickly ….

It's al to do with Extended Security …

Even though the actual hostname didn't change, I wonder whether that broke it …

This is relevant: -

Adding extended security after installation (db2extsec command)

If the Db2 database system was installed without extended security enabled, you can enable it by executing the command db2extsec. To execute the db2extsec command you must be a member of the local Administrators group so that you have the authority to modify the ACL of the protected objects.

You can run the db2extsec command multiple times, if necessary, however, if this is done, you cannot disable extended security unless you issue the db2extsec -r command immediately after each execution of db2extsec.

Removing extended security

Do not remove extended security after it has been enabled unless absolutely necessary.

You can remove extended security by running the command db2extsec -r, however, this will only succeed if no other database operations (such as creating a database, creating a new instance, adding table spaces, and so on) have been performed after enabling extended security. The safest way to remove the extended security option is to uninstall the Db2 database system, delete all the relevant Db2 directories (including the database directories) and then reinstall the Db2 database system without extended security enabled.

Note the caution - for me, this is ONLY a demo/test box so it's less of a concern.

This also helped: -

I did check the db2nodes.cfg as that's caused me no end of fun on Unix in the past: -

but both were OK: -

type "C:\ProgramData\IBM\DB2\DB2COPY1\DB2\db2nodes.cfg"

0 WIN2012 WIN2012 0

type "C:\Users\All Users\IBM\DB2\DB2COPY1\DB2\db2nodes.cfg"

0 WIN2012 WIN2012 0

which matched the hostname: -



In the end, I removed Extended Security, and things worked OK even after a reboot: -

db2extsec /r

Obviously I do NOT NOT NOT recommend disabling security - if this happens to you, call IBM Support.

Remember, YMMV and Caveat Emptor

No comments:

Grokking grep

A colleague was tinkering with grep  and, thanks to him, I discovered a bit more about the trusty little utility. I had not really explored ...