DB2 – How to pscp from the command line

PSCP  is a command line secure file copy program. It’s part of the PuTTY suite of files, which also includes  PuTTY – a Telnet and SSH client.

Within the PuTTY suite is another program called : Plink – which is a command line interface to the PuTTY backend. The great thing about Plink is it can be used as part of a script for management of DB2 servers.  For example,  a script to log on securely to a server – run a series of commands. One of the limitation of Plink is you can’t download files. At this point PSCP is called in to play

An example of a command line of PSCP in a Powershell script on Windows. In this example, the   username, password and servername are passed to the command line. PSCP logs on to the server and downloads the files onto the local server. In this case , we’re downloading all files with a prefix “db2diag”  on the folder “\servername\tmp\”   onto the local server path “E:\DB2\logs”.  Contact me for any assistance

 

$un = “myName”
$pw = “myPW”
$servername = “myServerName”

E:\scripts\DB2\modules\pscp.exe -l $un -pw $pw -p $un@$($servername):/tmp/db2diag* E:\DB2\logs\  

 Related Posts

Plink and DB2

db2diag.log file delete on Linux and DB2

How to fix DIA8052C the Event Monitor has reached its file capacity

Question: This DB2 error message appears in the DB2Diag.LOG file

 ZRC=0x800D002B=-2146631637=SQLM_RC_EVFULL "monitor full of data"

          DIA8052C The Event Monitor "" has reached its file capacity. Delete

          the files in the target directory "" or move them to another

          directory.

 

How can I fix it?

Answer:   There’s probably a limit on the event monitor size. To check the current size – connect to the database and issue the statement:

 

SELECT  * FROM SYSCAT.EVENTMONITORS

Find the event monitor name under the EVMONNAME  column.

DROP EVENT MONITOR <monitor_name>

SQLUV_IO_ERROR 25 IO error encountered

Question :

In the db2diag.log file – I’m getting the the error message

Vendor RC=0x00000019=25 -- see DB2 API Guide for meaning.

2012-04-25-06.30.42.834149+060 I1209204241E814     LEVEL: Error
PID     : 13535                TID  : 47410969569600PROC : db2sysc 0
INSTANCE: myInst              NODE : 000
EDUID   : 17727                EDUNAME: db2logmgr (myDB) 0
FUNCTION: DB2 UDB, data protection services, sqlpWriteToVendorDevice, probe:2700
MESSAGE : ZRC=0x86100025=-2045771739=SQLP_MEDIA_VENDOR_DEV_ERR
          "A vendor device reported a media error."
DATA #1 : Vendor RC, PD_DB2_TYPE_VENDOR_RC, 4 bytes
Vendor RC=0x00000019=25 -- see DB2 API Guide for meaning.
DATA #2 : Hexdump, 48 bytes
0x00002B1ED2603150 : 9B00 0000 3133 3338 2031 3535 0000 0000    ....1338 155....
0x00002B1ED2603160 : 0000 0000 0000 0000 0000 0000 0000 0000    ................

 

How can I troubleshoot the  SQLUV_IO_ERROR  25   IO error encountered  error message?

Answer:

Read the post Troubleshooting DB2 Return Codes, failed to archive log and SQLUV_INIT_FAILED   for DB2 return code interpretation

The definitions for all DB2 to Vendor API return codes are found under the instance home directory <sqllib>/include/ in the sqluvend.h header file.
The DB2 error code returns :
#define SQLUV_IO_ERROR         25  /* I/O error encountered */
The Vendor Code is returned using the return code 155
0155 T: DSM_RC_COMPRESS_GREW Compressed Data Grew
Explanation

 

The size of the file after compression is greater than the size of the file before compressed.

System action

Even though the size of the file increased, the file is compressed.

The error message  related to  TSM  trying to compress an object that has already been compressed.  Setting the local option file to  COMPRESSALWAYS  is YES overrides this error.

 

DB2 – Managing Diagnostic Logs

Minor problems stack up , eventually causing the DB2 server to crash.  Monitoring DB2 and responding to messages in the DB2 diagnostic log files is a critical part of the DB2 DBA job role.

DB2 DBAs review the logs after a crash – searching for  clues in root cause analysis. This is OK , but proactive monitoring can save downtime.

You need a system, an effective method to extract the important information from the DB2 diagnostic logs. These approaches will give you some ideas.

My preferred method is to execute a  script daily, extract severe and critical messages using db2diag ( see examples below) , mail these messages and archive the  diaglog.

The amount and type of information is determined by the DIAGLEVEL

1) Shell script to parse dbdiag files . I’ve even seen examples of Powershell  and Shell

2)    PDLOGMSGS_LAST24HOURS administrative view 

 

 

SELECT timestamp,instancename ,MSGSEVERITY FROM SYSIBMADM.PDLOGMSGS_LAST24HOURS WHERE MSGSEVERITY = ‘E’

 

 

3)     PD_GET_LOG_MSGS table function 

Similar to PDLOGMSGS_LAST24HOURS , but allows returning data older than 24 hrs 

     SELECT TIMESTAMP, APPL_ID, DBPARTITIONNUM, MSG 
   FROM TABLE ( PD_GET_LOG_MSGS( CURRENT_TIMESTAMP - 7 DAYS)) AS T 
   WHERE INSTANCENAME = 'MYINST'  
   ORDER BY TIMESTAMP ASC
   
 

 

2)    db2diag utility

Some examples

db2diag -A    –> Archive the diaglog
db2diag –g db=MYDB -> Filter by db name
db2diag -time  –> To retrieve records for a particular time
db2diag -time 2012-02-02 -l severe,error,critical –> To retrieve records for a particular time & filter only server,error,critical
db2diag -l severe –> To return only severe messages
db2diag –merge db2diag.1.log  db2diag.2.log  -level  severe    Merge 2 dlog files filtering on severe