Triton Consulting

Last month we were delighted to be given the opportunity to visit IBM’s research and development centre in Boeblingen, Germany.  Before I get on to what exactly we were doing there I’d like to share a little information about the centre itself as it’s quite a place!  Opened in 1953, Boeblingen is host to a whopping 2000 IT specialists, electrical engineers and physicists working on over 40 projects!  Their focus is on the development of next generation microprocessors, mainframes and supercomputers and enterprise software to control business processes.  In addition, Boeblingen is one of the largest LINUX and SAP integration centres within IBM.  So we were rightly excited about the visit. 

The reason for the trip was to carry out our own research and development work on IBM’s newest technology release – IBM DB2 pureScale.  Ever since hearing the first announcement last year, our team of DB2 experts have been itching to get their hands on the software and see what it can do.  The most exciting thing about this trip was that we were to be the first IBM Business Partners in Europe to get a look at DB2 pureScale in action – what a fantastic opportunity!

So, three of our DB2 experts set off for five days in the labs.  After a warm welcome from the pureScale team in Boeblingen, it was soon down to business.  As an R&D team the brief was to gain practical experience in the installation, operation and use of a DB2 pureScale environment, as well as testing DB2 pureScale for scalability and resilience.

Meet the team

Iqbal Goralwalla – Head of DB2 Midrange Solutions
Specialist DB2 pureScale subject – DB2 Self-Tuning Memory Manager (STMM), Bufferpools and Workload Balancing

James Gill – DB2 for z/OS and data sharing expert
Specialist DB2 pureScale subject – Coupling Facility

Clair Ross – DB2 Midrange expert
Specialist DB2 pureScale subject – Insert Load & Replication

Over the next few weeks the team will be blogging about their specialist subjects and what they have learned during their five days in the labs.

We’re delighted to announce that we are the first IBM Busuiness partners in Europe to work with pureScale!

Arguably IBM’s most important new feature for DB2 LUW, pureScale was anounced in October last year and quickly caught the attention of the industry.  Based on elading System z data sharing technology, DB2 pureScale integrate IBM technologies to keep critical systems available 24/7.

Triton’s team of DB2 experts spent a week at IBM Labs in Boeblingen, Germany on a research and development project.  During their time there Triton’s consultants gained practical experience in the installation, operation and use of a pureScale environment as well as testing DB2 pureScale for scalability and resilence.

“It’s certainly been an interesting week here in Boeblingen and we have really been able to take a deep dive into pureScale.  IN terms of scalability and resilence, pureScale really is second to non in the marketplace” Says Iqbal Goralwalla, Principal Consultant – DB2 Midrange.

Despite a very “interesting” journey back to the UK over the weekend due to cancelled flights the team are eager to continue with the DB2 pureScale research project and plans to produce a series of blogs, podcasts and technical briefings over the next few months so watch this space!

1.      During a recent migration exercise at a customer site the following error was encountered whilst migrating one of the databases:

2009-04-08-14.21.06.625141+060 E61438A838         LEVEL: Error (OS)

PID     : 18892                TID  : 164         PROC : db2sysc 0

INSTANCE: db2inst1             NODE : 000

EDUID   : 164                  EDUNAME: db2pclnr (MQTRACK) 0

FUNCTION: DB2 UDB, oper system services, sqloLioAIOCollect, probe:100

MESSAGE : ZRC=0×870F0024=-2029060060=SQLO_MEM “out of memory”

          DIA8533C The system memory limit was reached.

CALLED  : OS, -, aio_return

OSERR   : ENOMEM (12) “Not enough space”

DATA #1 : File handle, PD_TYPE_SQO_FILE_HDL, 8 bytes

0xFFFFFFFF643FD328 : 0000 0005 0000 0000                        ……..

DATA #2 : unsigned integer, 8 bytes

8192

DATA #3 : signed integer, 8 bytes

6684672

DATA #4 : String, 105 bytes

Search for ossError*Analysis probe point after this log entry for further

self-diagnosis of this problem.

 

2009-04-08-14.21.06.628605+060 I62277A2206        LEVEL: Error (OS)

PID     : 18892                TID  : 164         PROC : db2sysc 0

INSTANCE: db2inst1             NODE : 000

EDUID   : 164                  EDUNAME: db2pclnr (MQTRACK) 0

FUNCTION: DB2 Common, OSSe, ossErrorIOAnalysis, probe:100

CALLED  : OS, -, aio_return

OSERR   : ENOMEM (12) “Not enough space”

DATA #1 : String, 110 bytes

A total of 5 analysis will be performed :

 - User info

 - ulimit info

 - Memory info

 

 Target file handle = 5

DATA #2 : String, 190 bytes

  Real user ID of current process       = 10002

  Effective user ID of current process  = 10002

  Real group ID of current process      = 1116

  Effective group ID of current process = 1116

DATA #3 : String, 353 bytes

Current process limits (unit in bytes except for nofiles) :

  mem     (S/H) = unlimited / unlimited

  core    (S/H) = unlimited / unlimited

  cpu     (S/H) = unlimited / unlimited

  data    (S/H) = unlimited / unlimited

  fsize   (S/H) = unlimited / unlimited

  nofiles (S/H) = 65536 / 65536

  stack   (S/H) = 8388608 / unlimited

  rss     (S/H) = 0 / 0

DATA #4 : String, 119 bytes

System RAM information (in megabytes) :

  Total       = 8064

  Free        = 4572

  Available   = -1

  Addressable = -1

DATA #5 : String, 69 bytes

Swap space information (in megabytes) :

  Total = 8194

  Free  = 8194

DATA #6 : String, 117 bytes

Virtual Memory Information (in megabytes) :

  Total     = 16258

  Reserved  = -1

  Available = -1

  Free      = 12766

CALLSTCK:

  [0] 0xFFFFFFFF781947B4 ossLogSysRC + 0×3A0

  [1] 0xFFFFFFFF78186F60 ossErrorNameMapSystem + 0×1AC0

  [2] 0xFFFFFFFF7C45F250 sqloSystemErrorHandler + 0×860

  [3] 0xFFFFFFFF7C4B5A94 __1cUSQdDLO_LIO_HANDLE_DATARsqloLioAIOCollect6MLpnXSQdDLO_LIO_COLLECT_STATUS_ppnLSQdDLO_IO_REQdD__i_ + 0×6E4

  [4] 0xFFFFFFFF7C4B646C sqloLioCollectNBlocks + 0×51C

  [5] 0xFFFFFFFF7ADD789C __1cWsqlbClnrCollectSomeAIO6FpnMSQdDLB_CLNR_CB_L_v_ + 0×74

  [6] 0xFFFFFFFF7ADD82D4 __1cVsqlbClnrCollectAllAIO6FpnMSQdDLB_CLNR_CB__v_ + 0×74

  [7] 0xFFFFFFFF7ADDAAFC __1cQsqlbClnrFindWork6FpnMSQdDLB_CLNR_CB__i_ + 0×11F4

  [8] 0xFFFFFFFF7ADDBAE8 __1cSsqlbClnrEntryPoint6FpCI_v_ + 0xD0

  [9] 0xFFFFFFFF7C4CE414 sqloEDUEntry + 0×3A4

 

DB2 subsequently went into a panic and the instance crashed. This happened for another database as well. We resolved the error by changing the stack size value in unlimit from 8K to “unlimited”.

For those of you using Linux on the Itanium-64 bit (IA64) platform, note that DB2 9.5 is not available for Linux on IA64. The last supported DB2 version for Linux on IA64 is DB2 9. This is because Linux on IA64 is not a high growth platform for IBM and in fact quite the opposite. Customers appear to be choosing Linux on x86-64 in droves but that is not the case for Linux on IA64 . Moreover, unless demands from the marketplace change, there is no plan for supporting DB2 for Linux on IA64 going forward.

Here are the links which suggest that DB2 9.5 is not available for the Linux on Itanium-64 bit (IA64) platform: 

http://www.ibm.com/developerworks/wikis/display/im/SUSE+Linux+Enterprise+Server+%28SLES%29+10+-+DB2+9.5 

while DB2 9 is supported on Linux on Itanium-64 bit (IA64): 

http://www.ibm.com/developerworks/wikis/display/im/SUSE+Linux+Enterprise+Server+%28SLES%29+10+-+DB2+9 

Iqbal