DB2 Export error - SQL10018N The disk is full

While trying to run this export command

db2 "export to /filepath/schema.tablename.ixf of ixf messages v.msgs select * from wcsproln.catentryattr”

I got this error "SQL10018N  The disk is full.  Processing was ended.”

df -g showed that /proddump had 19 GB free space.

Looked into the db2diag log and found this:

2016-05-17-18.51.46.775102-240 E48658514A815      LEVEL: Error (OS)

PID     : 48627918             TID  : 1           PROC : db2bp

INSTANCE: db2inst1             NODE : 000

APPID   : *LOCAL.db2inst1.160517215412

EDUID   : 1

FUNCTION: DB2 UDB, oper system services, sqlowrite, probe:60

MESSAGE : ZRC=0x850F000C=-2062614516=SQLO_DISK "Disk full."

          DIA8312C Disk was full.

CALLED  : OS, -, write

OSERR   : EFBIG (27) "A file cannot be larger than the value set by ulimit."

DATA #1 : File handle, PD_TYPE_SQO_FILE_HDL, 8 bytes

0x0FFFFFFFFFFFE170 : 0000 0004 0000 0080                        ........

DATA #2 : unsigned integer, 8 bytes

34

DATA #3 : signed integer, 8 bytes

-1

DATA #4 : String, 105 bytes

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

self-diagnosis of this problem.

I did some research on this error message "A file cannot be larger than the value set by ulimit.” and found that file size limit set may be too low.

Command “ulimit -a” showed the limits set:

time(seconds)        unlimited

file(blocks)         2097151

data(kbytes)         131072

stack(kbytes)        32768

memory(kbytes)       32768

coredump(blocks)     2097151

nofiles(descriptors) 2000

threads(per process) unlimited

processes(per user)  unlimited

There are two ways to change these values:

1. Edit the limits file under /etc/security/limits (takes effect after reboot) 
2. Use the chuser command to change individual user settings (logout and login required)

Used the chuser command to change the fsize value:

chuser fsize=5000000 db2inst1

Logged off and logged back in and tried the export command. Voila !! It worked.

DB2 LUW - Connection refused. ERRORCODE=-4499, SQLSTATE=08001

Application developer says that he is not able to connect to the database, he's getting a message similar to this:
"Error opening socket to server /nnn.nnn.nnn.nnn on port 50,000 with message: Connection refused. ERRORCODE=-4499, SQLSTATE=08001"

How do you resolve it?

• Get the TCP/IP service name: 

• Issue this command: db2 get dbm cfg|grep -i svce
• The output will be something like this:
• TCP/IP Service name                          (SVCENAME) = svce_db2inst1
 
• Verify the port number:

• Issue this command: cat /etc/services|grep -i svce_db2inst1
• The output will be something like this: svce_db2inst1   50000/tcp
 
• Make sure the port is listening:

• Issue this command: netstat -Aan|grep -i 50000
• If you do not see any output, it means the port is not listening and that's a problem

• If the port is not listening, check the db2set parameter:

• Issue this command:  db2set
• If you don't see a DB2COMM parameter, then it needs to be set for applications to communicate with DB2
• Update the DB2COMM parameter with this command: db2set db2comm=TCPIP
• Stop and restart the DB2 instance: db2stop and db2start 

• After restarting DB2, check if the port is listening by issuing the command "netstat -Aan|grep -i 50000". If the port is listening, you'll see the output similar to this:

• f1000e00057aebb8 tcp4       0      0  *.50000               *.*                   LISTEN
• f1000e00054ddbb8 tcp4       0      0  nnn.nnn.nnn.nnn.50000   nnn.nnn.nnn.mmm 33xxx   ESTABLISHED
• f1000e000b3653b8 tcp4       0      0  nnn.nnn.nnn.nnn.50000   nnn.nnn.nnn.mmm 33yyy   ESTABLISHED

HTH !!

DB2 LUW - List of tables involved in a referential integrity chain

How do you find all the tables that are connected through referential integrity?

For example, let's assume that I've a table called TABA. This is a parent of TABB and TABB is a parent of TABC and TABC is a parent of TABD and so on. How do I find the all these related tables?

Method 1 - Query SYSCAT.REFERENCES:

db2 "select substr(TABNAME,1,30) as PARENT, substr(CONSTNAME,1,20) as CONSTRAINT, substr(REFTABNAME,1,30) as CHILD, substr(FK_COLNAMES,1,40) as REF_COL from syscat.references where tabname='TABA'"

This will give the child tables of TABA. Run the above query again for the child tables. Continue doing this until the last child table in the chain.

Method 2 - Through db2expl:

Run db2expl on "delete from tabschema.tabname" and parse the output.

db2expln -d lwscomdb -g -q "delete from SCHEMA.TABA" -t | grep -i "Delete:  Table Name"

This will do a db2 explain on the query to delete and then parse the output to get all the table names involved in the referential integrity chain.

My personal preference is Method 2.

Which method do you prefer and why? If you use a different method, please post it as well.