Blogs

By Mark Gillis

In the first part of this blog I outlined an issue I’d come across with the conferring of Role-based permissions to Groups for certain objects. Here’s one way around it and some further observations on the underlying issue.

Possible workaround

I did say I didn’t entirely like this option but it’s all I have been able to come up with so far.

If you want to enforce the structure of Users being allocated to Groups by your Windows or Unix Admins / Customers, you might have to keep the CREATE option up at the Database Administrator level. Once a View, Proc or whatever is in existence, the subsequent dynamic operations will be validated against the Group credentials and that can be operated by the Users who are members of appropriate Groups. This lets your User population stay fluid, whilst the Groups and Roles can stay relatively, if not entirely, static.

Read the blog in full.

By Damir Wilder

Damir recently found himself in a situation where he needed to expand (quickly and without downtime) the Db2 Transaction Log space in a customer’s live production database, which had been steadily filling up (for several hours) by a very long and intensive transaction. Also contributing to the log space usage were numerous other (smaller) transactions that were executing during the same time and biting off their chunks of the log space.

In his latest blog, Damir shares his solution for transaction log space usage with Db2 v11.5. Read the blog in full. 

By Iqbal Goralwalla

Earlier this year Db2 pureScale deployments were made available as a bring-your-own-license (BYOL) option through the AWS Marketplace with a pre-packaged template and point/click interface. This significantly simplifies the deployment process. It facilitates setting up a pureScale cluster from what used to be weeks or months to less than an hour.

In his new blog, Iqbal Goralwalla shares the deployment improvements made to Db2 pureScale over the last 10 years. Start the journey.

By Gareth Copplestone-Jones

If you attended Gareth Copplestone-Jones' presentation at IDUG EMEA and want to learn more about Db2 Locking, here’s where to start. 

This Db2 for z/OS Locking blog series is mostly targeted at Db2 for z/OS application developers, but is also appropriate for application designers, database administrators, Db2 systems programmers and other Db2 professionals who are concerned with data integrity and application performance.

You might ask, what’s that got to do with locking? It’s all too easy to assume that locking just happens and that you don’t need to worry about it. Nothing could be farther from the truth: if you don’t understand the Db2 locking mechanism and the way it is affected by BIND options, then it is very easy for your application to compromise data integrity, or to deliver poor performance – or both. This series of articles is intended as a practical guide to how and why Db2 locks data that will help you avoid the programming pitfalls that can compromise the holy grail of data integrity. If you’re already a seasoned professional, then I encourage to read on as there might be some useful pieces of information for you.

The objective of this series is to help you understand:

Why locking is important.
The concepts of Db2 for z/OS locking.
How Db2 locking behaviour is affected by BIND/REBIND options.
How to code update applications to avoid data anomalies and guarantee data integrity.
How you can improve performance by taking as few locks as possible.

Continue reading Part 1 of 10 on Db2 for z/OS Locking by Gareth Copplestone-Jones. 

By Mark Gillis 

Mark Gillis has been doing some migration work; porting a Db2 database to a PostgreSQL one. You could say that is going from an Enterprise strength solution to a simpler, but less expensive option, but it’s not a choice Mark is in a position to ignore.

Customers are being presented with a wealth of database options as they migrate to the Cloud, and many of them are embracing the options of simpler and less licence hungry products.

There are many positives to PostgreSQL but there are some pitfalls in attempting such a migration.

Find out more from Mark in Db2 v PostgreSQL

By Mark Gillis

In his new blog, Mark Gillis explores how to modify queries on the fly using Jupyter Notebook, widgets and interactive SQL.  

OK, fair enough, that does sound a bit specialised and will maybe put some people off. Nothing like a good blast of technobabble to send us scurrying to the coffee machine.

What this is getting at is the ability to modify queries on the fly. It’s one of the reasons I’m quite taken with Jupyter Notebooks; the ability to provide some SQL and to run it, take a look at the result set and then tweak the original SQL and re-run it until you get the output you want.

Read the blog, Jupyter Notebooks, Widgets and Interactive SQL in full. 

By James Cockayne

By now I’m sure everyone has heard of the malicious practice known as ransomware attacks, where miscreants break into a corporate network and encrypt data before demanding huge sums of money to provide a method to decrypt that data and make it accessible again.  The attacks tend to be insidious – sometimes the attacker is in the network for months before they gain access to the systems they are interested in, and they are known to target backup servers as well as the primary systems to cause maximum inconvenience to the target organisation. 

Find out what an attack on a DB2 Database would look like. Continue reading James Cockayne's latest blog. 

https://www.triton.co.uk/ransomware-and-the-db2-database-part-1/