This blog contains experience gained over the years of implementing (and de-implementing) large scale IT applications/software.

SAP ASE Job Server Error

Whilst administering a SAP ASE based SAP system, I came across an issue in the ASE Job server error log “JSTASK.log”:

00:140737306879744:140737340581728:2016/02/24 16:50:00.87 worker  ct_connect() failed.
00:140737306879744:140737340581728:2016/02/24 16:50:00.87 worker  jsj__RunSQLJob: jsd_MakeConnection() failed for user sapsa to server SID
00:140737306879744:140737340581728:2016/02/24 16:50:00.87 worker  jsj__RunSQLJob() failed for xid 66430
00:140737317369600:140737340581728:2016/02/24 16:55:00.87 worker  Client message: ct_connect(): protocol specific layer: external error: The attempt to connect to the server failed.

The issue was caused by a change of the sapsa user password whereby the SAP recommended method of using the hostctrl process, wasn’t followed.
The recommended method updates the sapsa user, the secure storage file plus also the external login for the Job Server.
This is mentioned at the very end of SAP note 1706410 (although it is suggested that the process in this note is no longer followed to change the passwords).
To fix the issue, follow finals steps in the SAP note 1706410:

isql -X -Usapsa -S<SID> -w999

use master
go
sp_helpexternlogin
go

Server                 Login                Externlogin
———————- ——————– ————
SYB_JSTASK             sapsa                sapsa

Drop the SYB_JSTASK entry:

exec sp_dropexternlogin SYB_JSTASK, sapsa
go

Re-create it with the new password:

exec sp_addexternlogin SYB_JSTASK, sapsa, sapsa, ‘<new sapsa password>’
go

This should fix the issue.

SAP ASE Backup Server Error Writing to Archive

When running SAP Business Suite on the SAP ASE database platform, I was trying to dump and load from one database to another database.
A backup server error was seen on the target database and in the backup server log file (<SID>_BS.log) during the LOAD statement execution:

Backup Server: 4.145.2.22: [3] Error for database/archive device while working on stripe device ‘/<file1>’. Error writing to archive device /<file1>. Attempted to write 65536 bytes, 32768 bytes were written.

This specific issue turned out to be caused by my target DB not having exactly the same size for the data or log devices.

I even found in some cases that the log device needed to be a tiny little bit bigger (we’re talking about 1MB bigger) than the source database.

Drop a SAP DB2 10.1 Database & Remove Instance

In case you have installed an IBM DB2 database instance using the SAP Software Provisioning Manager, and you would now like to remove this database and the DB2 software installation (SAP DB instance), then here’s a quick method:

As db2<sid>:

db2<sid> # db2stop
db2<sid> # db2 drop database
Then as root:

# cd /db2/db2<sid>/db2_software/instance
# ./db2idrop db2<sid>

# cd /db2/db2<sid>/db2_software/install
# ./db2_deinstall -a

Finally, remove DB related directories (if necessary):

# rm -rf /db2/<SID>/db2dump/*
# rm -rf /db2/<SID>/log_dir/*
# rm -rf /db2/<SID>/*archlogs/*

IBM DB2 10.1 Statistics Replication

Scenario: You would like to test a new index in an IBM DB2 10.1 database.  Unfortunately your development system doesn’t have anywhere near the same number of records in the database table on which you are creating the new index.

Like many other RDBMSs, DB2 uses table and column statistics to influence the optimiser’s decision as to which access path to choose at execution time.
By replicating only the statistics, it’s possible to fool the optimiser into thinking the table has more records present, than it really does.  This means that it’s likely to choose a different access path.

When performance tuning a database, it’s useful to use this method of fooling the optimiser, because you can emulate a larger table in a small development system with little actual data.

The process in DB2 is like this:
– Generate (or export) the statistics for a table in a production database system (PRD) schema DBA.
– Modify the export file.
– Upload the contents of the export file into a development database system (DEV) schema DBB.
– Test.

Step 1 – Export the statistics for a table in production.

Connect into the production database (DBA), then use the db2look command to create an export file containing the UPDATE commands for adjusting the statistics:

db2prd> db2 connect to PRD

db2prd> db2look -d PRD -e -c -m -r -t DBA.TABLE1 -o table1_STATS.sql

The output will be written to the table1_STATS.sql file in the current directory.

Step 2 – Modify the export file.
You should edit the output file to remove all lines before the line “– Mimic table TABLE1”, failure to do this could mean dropping the TABLE1 table in development.

You must also edit the file and replace all instances of schema “DBA” with “DBB” to ensure that the correct development database schema is found.
The modified file will look like:

— Mimic table TABLE1

UPDATE SYSSTAT.TABLES
SET CARD=2341434,
NPAGES=14636,
FPAGES=14645,
OVERFLOW=9473,
ACTIVE_BLOCKS=0
WHERE TABNAME = ‘TABLE1’ AND TABSCHEMA = ‘DBB’;

UPDATE SYSSTAT.COLUMNS
SET COLCARD=1,
NUMNULLS=0,

Step 3 – Upload the statistics into the development database.

db2dev> db2 connect to DEV
db2dev> db2 -tf ikpf_STATS.sql

DB20000I The SQL command completed successfully.

DB20000I The SQL command completed successfully.

SQL0100W No row was found for FETCH, UPDATE or DELETE; or the result of a query is an empty table. SQLSTATE=02000

SQL0100W No row was found for FETCH, UPDATE or DELETE; or the result of a query is an empty table. SQLSTATE=02000

You’re now ready to test.

To reset (re-gather) the statistics on the development database table, you simply need to re-collect statistics using the RUNSTATS command: “db2 RUNSTATS ON TABLE TABLE1 WITH DISTRIBUTION AND INDEXES ALL”.

HANA DB Re-initialisation Without Reinstall

Scenario:  You have a small test system or PoC system and you want to revert or recreate the HANA DB like you’ve just opened the box and installed it from new, but without the hassle of the reinstall.

This is completely possible using the hdbnsutil command line program.
With HANA shutdown, connect to the HANA server via SSH as the <sid>adm Linux user, then run the hdbnsutil command line program as follows:

hana01:/usr/sap/H10/HDB10/exe> hdbnsutil -initTopology

checking for inactive nameserver …
nameserver hana01:31001 not responding.
creating persistence …
run as transaction master writing initial topology…
writing initial license: status check = 2
done

As you will see, it recreates the persistence layer (database) and also re-creates the license.
You will need to reinstall your HANA system license after the re-initialisation process is complete.
On a slow system, the process took approximately 2 minutes.

Due to the size of my system, I am unable to tell you if this process destroys any specific configuration.  From what I can tell, the existing global.ini, nameserver.ini and indexserver.ini are kept.

You should also note that the SYSTEM user password is reset to its default value of “master”.
Plus, if you have enabled encryption, the reinitialised data volumes will be re-encrypted unless you de-check the checkbox on the Data Volume Encryption tab inside the Security tab, prior to reinitialisation.