Gunning Technology Solutions, LLC. THE WORLD LEADER IN Db2 LUW CONSULTING!

http://www-01.ibm.com/support/docview.wss?uid=swg1IT00925

I recently ran across the below APAR. We don’t normally run INSPECT for the heck of it be we were investigating some RAID errors and discovered this APAR when the INSPECT reported errors on an MDC table but the table appeared to be intact and updatable, see above link (problem fixed in DB2 9.7 FP10 and above).

Thanks to all my followers that made this happen in a short amount of time.

A recent  SCADA attack………http://www.computerworld.com/article/3039772/security/ukraine-power-cyberattack-russia-itbwcw.html

4 or 5 years ago many organizations were just starting to think about SSDs  but most organizations that I have been in have not fully taken advantage of the huge performance improvements you can get with SSDs for critical OLTP systems. How dows 10x order of magnitude sound?  Well, guess what, industry is already talking about the next replacement for SSDs coming in 4-5 yrs. So SSDs are now mainstream and if your company is not taking advantage of them, check out the below article and get moving! http://tinyurl.com/pntomjj

If you are still on some version of DB2 less than DB2 9.7 FP3 this nice Developer Works article has some good tips on how to identify unused indexes. You can do this using -tcbstats index option and querying syscat.indexes and syscat.tables. The article also has a few neat tips on using DB2 Design Advisor with the package cache option also…Of course if you are on DB2 9.7 FP3 and above you can identify unused indexes by querying syscat.indexes. Even so I always then do a describe detail on the indexes, save the output, and look at tcbstats to verify everything before I drop any. That way you can always recreate them if needed. In this new year of 2016, it is a good time to continue your housekeeping and get rid of unused indexes. It saves resources in terms of space, cpu and reduces utility runtimes!! Get movin’! Here’s the link : http://www.ibm.com/developerworks/data/library/techarticle/dm-0910db2unusedindex/

Just a tad bit crowded….Enjoy!

This is an example of what a properly configured and monitored DB2 LUW HADR implementation can provide. In this example, this two database instance running HADR in superasync mode to one standby server has been up over 370 days without an outage, with reports running against the standby databases in read only mode. Get started with DB2 today and see what you can achieve!

Database Partition 0 — Database FLW — Active — Up 375 days 01:28:32 — Date 2015-11-29-13.06.33.282000

HADR Information:

Role   State               SyncMode   HeartBeatsMissed   LogGapRunAvg (bytes)

Primary RemoteCatchup       SuperAsync 0                 57371

ConnectStatus ConnectTime                           Timeout

Connected     Thu Nov 05 13:30:59 2015 (1446748259) 120

LocalHost                               LocalService

10.221.37.1                             db2h_DB2_1

RemoteHost                               RemoteService     RemoteInstance

10.221.37.2                            db2h_DB2_2         DB2

PrimaryFile PrimaryPg PrimaryLSN

S0405097.LOG 7153       0x000052083D8E94C3

StandByFile StandByPg StandByLSN

S0405097.LOG 7022       0x000052083D8663A2

Database Partition 0 — Database LARG — Active — Up 375 days 01:04:01 — Date 2015-11-29-13.06.34.077000

HADR Information:

Role   State               SyncMode   HeartBeatsMissed   LogGapRunAvg (bytes)

Primary RemoteCatchup       SuperAsync 0                 279

ConnectStatus ConnectTime                           Timeout

Connected     Wed Oct 07 09:33:41 2015 (1444224821) 120

LocalHost                               LocalService

10.221.37.1                             db2h_DB2_3

RemoteHost                              RemoteService     RemoteInstance

10.221.37.2                             db2h_DB2_4         DB2

PrimaryFile PrimaryPg PrimaryLSN

S0015831.LOG 1663       0x00000117A25AF50F

StandByFile StandByPg StandByLSN

S0015831.LOG 1660       0x00000117A25AC092

The final IBM X-Force Threat Intelligence Quarterly is out and it basically indicates that if companies just did the Security 101 basics they would at least detect or if not prevent attacks on their data….So take a look at it and get back to the Security Basics…..https://securityintelligence.com/a-look-back-with-ibm-x-force-lessons-learned-from-security-research-in-2015/

DB2 LUW is supremely positioned and designed to inherently support multi-tenancy, whether or not the original designers intended it to be :). Since a database in DB2 is more like a system in SQL Server and Oracle, meaning databases in DB2 are physically separated in DB2. So you can use multiple databases per instance or more likely multiple database schemas in a DB2 database to implement multi-tenancy. With this design, multi-tenants can be assigned to separate bufferpools and even physical disk by by using multiple storage groups for tablespaces. There is a good paper on DB2 multi-tenancy in the cloud here, http://www.ibm.com/developerworks/data/library/techarticle/dm-1201dbdesigncloud/

and my friend in the IBM Toronto Lab, Enzo Cialini has a nice presentation on this. He presented this last year at the Central PA DB2 Users Group in Harrisburg.  Stay tuned and secure.