Db2, where are you? Big Blue is oddly reluctant to discuss recent enhancements to its flagship database It's the time of year when one might wonder what happened to that avuncular family figure whose existence was so reliably dull they passed into history almost forgotten - a little like Db2, IBM's flagship relational database that has faded from users' collective memory. Big Blue's system of choice for its mainframes and big …
The world is changing. I was an Oracle DBA for almost 20 years but then I moved sideways to other areas as I knew that wouldn't keep my career going for another 25 years. I used my coding skills and generic understanding of admin and DB skills to learn more products across so many disperate services these days. I no longer learn anything to any great depth, sad but true, now I learn enough to support a project, set it up, document and move on.
The days of the specific skilled worker are drawing to a close, only the Jack-of-all-trades will survive now. With this change to more "low depth", generic IT skills and workers comes the need to keep changing products every few years as old legacy tech is mothballed or put out to pasture.
DB2, like SQL Server, Oracle and their ilk are being replaced or at the very least simply locked in legacy silos to die a slow death. Why pay all that money for the software and skilling up your staff when they will walk out or the product will be used to bare minimum over the 4-5 years of it's lifetime? Learn enough about MySQL/PostgreSQL cloud offerings to store data. Badly written SQL? Why bother tuning it, just crank up the number of CPUs on the config page for the instance, why bother tuning anything, it'll only be around for 4-5 years max then it'll be replaced by the next project. Just keep paying the cloud providers for more horsepower, more tech, more space.
And you've knocked the nail on the head there. I'm in the same position. My background is heavily MSSQL.
I've also reached the point of knowing enough to get the job done in other stuff, and it infuriates me when people take the attitude of 'it's running slow, lets ramp up the VM to the next level up' rather than optimising what we have.
Then again why should I care, the bill isn't out of my salary. So I advise, whereupon it's ignored because they don't want to spend the time. No amount of capacity planning will fix that mindset
Relational data stores, compute infrastructure, servers - these are things that are provisioned and priced like utilities now.
Whereas before you needed a full-time DBA just to set things up and keep the lights on, now you can pay a monthly fee to have that provided with relatively well understood SLA's.
There's still a need for skilled workers - but they need to be able to join three or four utility systems together into one product. That's not a jack of all trades, its just a different specialization.
> these are things that are provisioned and priced like utilities now.
Ironically, IBM recognised very early on this was where the internet would be heading (with a bit of pushing from IBM of course); it was Gerstner's pet project (at a time when Microsoft was still trying to work out if this world wide web thing would be important or not).
But, as per usual, IBM cannot do joined up thinking
There are actually three independent implementations of Db2: the mainframe version, the AS/400/i-Series OS service, and the Linux/Windows port. Each of these is a separate source repository, and they are not bug compatible (AFAIK).
IBM has licensed a version of PL/SQL (Oracle's ADA-like language for procedural SQL) from Enterprise DB. I don't know if this has been implemented on all of the Db2 platforms. Oddly, Microsoft has not arranged for PL/SQL support, instead adhering to Transact-SQL. This suggests that Db2 is a better choice for porting away from Oracle.
https://www.enterprisedb.com/news/enterprisedb-and-ibmr-collaborate-integrate-technology-new-version-db
Still, SQLite and Postgres offer enough features that $15-25k for a core-based proprietary DB license demands justification for return on investment, and cloud services will make this judgement stark.
"Badly written SQL? Why bother tuning it, just crank up the number of CPUs on the config page for the instance"
If you say a statement like that it makes me confident you were never a DBA, yet alone an ORACLE DBA for any period of time.
Ever heard of latch contention? Shit I remember dealing with that back in 2004, and again at another company in 2007ish. I remember one conference call in particular during an outage with latch contention. Our VP of engineering asked us, and I'll never forget because it was just such a strange request. He said
"Guys, is there anything I can buy that would make this problem go away?"
I wasn't the DBA (I have never been a DBA though I have managed database servers) or even responsible for back end systems(storage etc), I managed the app layers. The answer was a resounding no. You could buy the fastest computer in the world and it wouldn't solve this issue. You have to fix the app. We had the largest single OLTP database in the world at that company at over 50TB in size(by 2006), Oracle said the next largest was Amazon at ~8TB. The 50TB size was due to poor app design(storing raw XML in the database). Probably one of the only companies in the world when they deployed data warehousing the data warehouse was a fraction of the size of OLTP.
I had an argument with my manager at the 2nd company where we had latch contention. I knew the problem from past experience. I didn't know the CAUSE. Everyone blamed Oracle(except me and the outsourced DBAs). The problem was most quickly "fixed" by doing an Oracle restart. But then within a week it would come back. CPU would go to 100%, query rate would fall to the floor. Oracle Enterprise manager clearly showed latch contention happening.
After about 6 weeks of this the devs finally figured out the cause - a problem in the app. Which they fixed and the latch contention stopped.
I haven't used Oracle DB seriously since 2008, I don't include running vCenter DB on Oracle(it was either that or MSSQL and I wanted a DB running on Linux) for several years as that was a tiny DB with a very low workload. Given the low workload and user count it was super cheap per user licensing for Oracle SE subscription.
I know all of that and I'll never admit to being a DBA. I can generally manage Oracle and MySQL services/backups etc, but getting into the guts of tuning and queries etc is not me.
another common saying among DBAs I have worked with goes along the lines of - you can double your performance by doubling your CPU speed(emphasis on speed not number of cores)/memory, but you can increase performance by 10X+ by fixing your query(ies).
I believe Oracle EE with an addon does provide parallel execution(for a single query), most other DBs do not. Otherwise of course a single query is limited to a single CPU core, and CPU core performance doesn't increase very quickly. You can add more cores but that won't help individual queries just the ability in some cases to run more queries. Our big Oracle servers back in 2004-2005ish literally spent more than 60% of their time waiting on I/O on average. CPU user time was quite small. We literally had vendors like Hitachi come in and tell us nobody else in the world is doing what we were doing with our DBs. They would spec out hardware and said in theory it should be fine but we haven't tested things in this way (in the end it was fine as in didn't break at least until they tried NFS on NetApp and the NetApps shit themselves immediately until they changed to fibrechannel). I wasn't responsible for back end storage or Oracle systems though I did write a ton of stuff to monitor them which everyone relied on even years after I left..
I remember MySQL query cache contention being an issue too. One of our DBAs at my current company almost got fired when we moved out of cloud into our data center and he was adamant he didn't want MySQL query cache on(most MySQL folks hate it for good reason I suppose). The app required it(again, bad app). Performance was in the shitter for hours. He said no. Everyone else said yes. He relented and turned it on app performance skyrocketed and things were ok again. We did have query cache contention at times but it was super rare for it to be a critical issue. Then they built a new app stack that didn't rely on query cache as a performance boost and we have had query cache disabled for many years now.
Was thinking about this more during my workout. Wanted to add another great way to kill Oracle performance is not using bind variables. In fact the latch contention at the 2nd company was the result of a combination of their new ruby on rails app not supporting bind variables and them using a hackish workaround in the DB driver to "force" bind variables on everything, and at one point they introduced new queries which from what I recall caused the query plan to change and things just exploded at that point due to improperly using bind variables(I didn't figure out the cause it was explained to me by the devs who wrote the app after they figured it out). The original app stack they had was based on java and did properly use bind variables, then they bolted a ruby app on and wanted to use the same DB backend (different schema but same instance).
The cause of latch contention at the first company if I remember right was massive use of SELECT FOR UPDATE queries. Triggering major contention in some of the indices. I believe I was told that storage performance was not a factor as the rows in question were in buffer cache already so getting faster storage wouldn't help, getting faster cpus wouldn't help well maybe it would get you a few more seconds or minutes before the issue showed up, but realistically there wasn't a CPU on the planet that could of solved that problem.
Latch contention, there's a phrase that I've not heard for some time. Mainly because it's an indicator of someone with history. Thinking about it, I can't recollect anyone under the age of 40 ever talking about it in the last 10 years.
I know I have, and like you, it's there in front of their faces - and they don't (want?) to understand it
My previous role, we were importing a database in its entireity EVERY NIGHT from Infomix to another backend, and then processing all that data every night INCLUDING the historical.
Did they want to address it, and realise that it could be delta'd relatively easily? No,,,,,, throw hardware at it. It didn't improve it. Throw more memory at it.... nope. Cached everything in memory, doesn't help contention obviously.
I tuned oit literally to death within the constraints meantioned above, got it down from 24hrs processing to about 9. I could have got it to 2, maybe less but management didn't want to dothe job properly.
Now, it's back to 24 hours+, because in the intervening 18 months, the data volume has gone up significantly and it cannot be tuned any more than it has been without delta processing.
Unsurprisingly I quit, because if I can't do my job because of upper management stupidity, I'll go somewhere I can.....
Ah the dreaded Latch and Lock Contention… Just resolved an issue at a Mainframe DB2 shop. On a routine basis there was slow down of critical business transactions during business hours. The slow downs were having serious business impacts.
I was able to determine that the root cause was that every transaction in the shop called a subroutine that inserted/updated rows in three DB2 tables. So every transaction was waiting for it’s turn to modify rows in the tables. Ironically it turned out that the whole purpose of the tables was to track daily, weekly and monthly transaction volumes for leadership teams.
I was able to convince the app team to temporarily change the subroutine to just return to the caller having done no work. They were shocked that all the slow downs and performance problems miraculously disappeared. At first they thought it was just a coincidence, now the temporary solution has become a permanent solution.
The kicker- the shop is on IBM zCloud. For two years the IBM DBAs assigned to the account recommendation was to continually increase MIPS (processing power). Of course that made good business sense to IBM as that increased revenue, however, that path did not resolve the problem.
And there will continue to be failed projects and "emergencies" that qualified developers are required to come in to rescue after they've been botched by people making such asinine statements.
Sure I use PostgreSQL for most of my workloads, but that is because I know very well the deployment will only be for a few hundred users in the worst case. But if I were doing real enterprise development again, there is no way it could handle the workload.
There is and will always be a place for special-purpose proprietary technolgy, whether it finds its roots in open source or not.
I mean, seriously - two little databases and you think they can handle all the world's needs so you need not learn anything else? MySQL isn't even a real database that can properly handle DATE and TIME columns, for crying out loud!
Funnily enough, I've always though of mySql in the same terms as Sqlite, which is a bit unfair.
when I've come across it in production (also in its Maria 'flavour') , it's usually been in lightweight tracking/as a cache layer implementations, rather than the use cases I find Oracle/MSSQL in.
Where I've found a bigger more enterprise use, it's because someone thought it would be a cool thing to do OR they were too tight to pay for a proper class platform.
YMMV
"Badly written SQL? Why bother tuning it, just crank up the number of CPUs on the config page for the instance, "
There are two kinds of databases in the world. The ones that don't get used much (around 90%), and those that are frantic hubs of activity keep people in business (10%). What you use for the 90% doesn't really matter. You can be breathtakingly incompetent and get away with it. But if your application is in the 10% and your idea of 'tuning' is to crank it up to 11 then sooner or later you will get your backside handed to you, or possibly even the contents of your desk in a bin liner.
There are a bunch of scenarios (especially in OLTP, where I work) where scale is a fundamentally nasty problem that can't be solved by throwing hardware at it. It turns out that adding multiple cores makes things worse, and multiple servers much worse, unless you re-design the DB and/or application to think in those terms...
As for support: I can understand people being reluctant to put themselves in the clutches of Oracle or IBM for support. Been there. Done that. But if you're going to *insist* on open source and wise enough to realise you need multiple vendors that will compete against each other, Postgres is pretty much the only open source DB that has more than 1 vendor providing credible, enterprise level support. The 90:10 rule also applies here. If you are in the 10%, and want to do it yourself, you need a professional support organisation with at least 3 technically competent people who understand database internals and can compile and patch the product at will, 24/7/365.25. That's >US$500K a year, which would pay for a lot of outside support...
GODS YES.
One of our line of business apps (which uses a MS SQL database back end) was giving absolutely terrible performance doing some reports which incorporated some user provided specification (date ranges, etc.) and the vendor's recommendation was to increase the number of CPUs and memory on the server to take up the entire VMware host the machine was running on. (it was already ludacrisly overspecced for a VM)
We hired a consultant to come in and look at it, and after a couple days he told us that the root of the problem was sown to some problems with the indexes (some missing, some were not being updated properly) and some really, really poorly written queries*. We actually had too many CPUS allocated to that VM for what the server was doing, and the amount of memory was more than sufficient, provided we fix the indexing issues.
The vendor's done a tremendous amount of work on their app since (they hired a proper DBA to fix some of the more... organic design issues with that database!), but I'm still going to give them static for it; there's still a lot of "I will do this from the script and not think" along with "I'm going to latch on to this specific issue as being at fault and that is my hill to die on, especially after it's been proven otherwise" going on there.
* Think things like SELECT * from * and using WHERE clauses to filter out what you want from the firehose of data from the 600+ GB database...
At the company i was at back in 2005ish time frame we had over 1TB in indices alone (Oracle on HPUX on Itanium). As mentioned in another post I was the expert in ops on the app end of things I didn't deal much directly with the DB or back end storage at the time.
Oh and they couldn't reclaim any space. There was a big initiative to delete old data from the DB to reclaim space and adjust the high watermark I think in Oracle to have it re-use the space. That re-usage of space caused massive outages, and the only time that I've seen a vendor fly out on site. Oracle flew 2 people on site the next day to deal with the issues. The basic suggestion was in our use case we cannot use that particular feature, nobody else in the world was doing what we were doing and they could not support it. So no space reclaiming, at least not with that method.
After I left the team really wanted to get off of HPUX and onto Linux. I don't know the full story I'm sure Linux was easier to use(all app layers used it already). But I do recall one funny bit, a couple years after they switched their super huge OLTP to Oracle on Linux(at about a time when Oracle was pushing "Unbreakable Linux" I think) and apparently had several outages as a result, their largest customer on their new contract required them to migrate the DB back to "big iron" of some kind(any kind), get off of Linux for Oracle. The customer was happy to pay the bill to do that, but they had to get off of Linux it couldn't handle that DB properly. I don't know what they migrated to at that point.
I learned a ton at that company(and had fun too), really launched my career(I tell people I got 10 years of experience compressed into less than 3, and I don't believe that is an exaggeration) but wow did I burn out hard core too took 3+ years to recover. I thought I was invincible, until I realized I was not.
Version 10g introduced a new in-place shrink, enabled by "alter table x enable row migration;" followed by "alter table x shrink space;".
If you were using a prior version, then the method to defragment/consolidate a table was only by the 8i "alter table x move tablespace y;" which does unpleasant things to indexes. It would be well-worth an upgrade to 10g just to get the in-place shrink functionality rather than rely on the 8i method.
And as far as sticking with Itanium, that's because migrating to a new platform means exp/imp (maybe with data pump). I have also done this from HP-UX to x86, and it is also not pleasant. I think that Exadata is the biggest iron available, and it runs on Oracle Linux.
>>changing products every few years as old legacy tech is mothballed
Yes, I've mostly just learned/used what was in fashion at the time and then moved on.
the list useless knowledge I have accumulated keeps growing, Unidata, Universe, OpenEdge, MS SQL, etc... (maybe that last one will remain useful for a while longer)?
I do enjoy deep diving into the guts of things but there just isn't a lot of time I can devote to exploration, experimentation.
As an opposing/devil's advocate - you must remember the hell of a customer asking you which very expensive machine to buy based on some vague "transactions" and then a vague "number per second with some order of magnitude high/low random numbers".
Now you can ignore all that - customer can burn as much money as they like to get the performance that they want and you still have the option of re-writing the odd asinine query - but now you get to produce some gargantuan opex saving for your 30 minutes of work.
I really liked Informix back in the day. Got off to a bumpy start thanks to a solution for each node in our cluster having its own Informix server accessing an RFS network drive (this was a derivative of AT&T SVR3.0; no NFS for us, though in this example that would've still been a bad idea) which worked about as well as you'd expect. But I came to appreciate it once it was sensibly implemented and actually liked stuff such as ESQL/C.
It's quite sad looking back and seeing that, Sybase, RDB and others variously eclipsed and bought out as all roads led to Oracle and their comedy pricing policies. DB2 (or Db2, whatevs) is pretty much at that point unless IBM gets a clue. But it's probably made the clue person redundant because they were too old and expensive.
Wow. Someone other than me that remembers AT&Ts RFS! This was an add-on on top of SVR3, and required System V STREAMS to work. I set it up with AT&T R&D UNIX during my time at AT&T.
It had many advantages over NFS, such as full UNIX file system semantics, but had a flaw in that it needed an "Advertising Server", if I remember the terminology correctly, to track the available network services and their state.
At the time I was using it (mid 1980s), I think that this server was a single point-of-failure for the networked filesystem, and recovery of the state after an outage of the AS took quite some time. The recommendation was that you made it a powerful server. I only had a 3B2/400 available!
But it enabled some magic things like named pipes and device files between different machines in the networked filespace.
If you're starting a new project, I can see no world in which I would choose DB2, Oracle, MSSQL over PostgreSQL. If it wasn't for PostgreSQL, then there's no way you'd choose DB2, Oracle or MSSQL over MySQL.
PostgreSQL and MySQL are open source and have enterprise grade 24/7 support available from multiple vendors. Who would voluntarily shackle themselves to a single, closed source platform for the foundational component of the stack which may be the most difficult to migrate to an alternative?
Moving Db2 to the cloud will protect it and give customers one less reason to migrate off of it, so that's a smart move. If IBM wanted Db2 to compete for new business, they'd have to open source it. Otherwise no one in their right mind would consider it for new development.
"If you're starting a new project, I can see no world in which I would choose DB2, Oracle, MSSQL over PostgreSQL."
Where I work we use all of DB2, Oracle, MSSQL, PostgreSQL, and more. I am not an expert in any of them but have used DB2 and Oracle more than the others. It's all about the details. If you think PostgreSQL is universally "as good as" DB2 (for example, and because this article is about DB2) for every application, that says something about the details of your applications. But someone else's application might find DB2 a better fit, here is where the experts must weigh in during requirements phase. In that case it helps to have experts (including DB2 experts) in house, otherwise you have to listen to promises from sales.
"Who would voluntarily shackle themselves to a single, closed source platform for the foundational component of the stack which may be the most difficult to migrate to an alternative?"
I don't understand the "shackle" part. First, choosing DB2 for a project doesn't mean you can't choose PostgreSQL for another project, or vice versa obviously. Second, if you already have DB2 in house, it's pretty easy to use it for a new application, same with PostgreSQL, etc. Third, ease of migration is not a consideration because migrating any production system is considered impossibly hard, no matter the underlying technology. If you choose PostgreSQL, you are just as stuck with it as you would be if you had chosen DB2.
If you choose PostgreSQL and you want support, you have a couple of options - Percona, EnterpriseDB to name two of the bigger ones. You can have them give compete with each other for your business. If you don't like the support you're getting, you can switch.
If you use DB2 and you don't like the support or terms IBM is giving you, you can think about the life choices that got you to that place, but not much else.
Company I'm with used to use Percona MySQL support, maybe until 2014/2015 or so. They were pretty good. Used their percona MySQL distribution as well. Didn't have to call support often at all. Then one year they increased their prices probably by 700%+ and we dropped them immediately(didn't replace them with anyone else externally anyway). I could see adjusting our budget for a 200% increase in cost but the company wasn't willing to accept that much larger increase especially since we didn't engage them often.
What I found sort of interesting in the article is it started out touting Db2 in clouds and stuff, then goes on to focus more on Db2 growth on mainframes. Just gave me the feeling that perhaps the biggest reason one would choose Db2 at this point is if they planned or thought they would need to use mainframes. Only other reason is if you already have a history of Db2 in house(most likely on IBM hardware perhaps AIX or something non mainframe) it makes sense to work with that knowledge.
Otherwise, as others have said IBM has a big hill to climb(I'm guessing they won't even try at this point) to convince folks why they should use Db2 over something else(mainly Oracle I suppose as MSSQL is generally Windows-only(I am aware of the Linux port of MSSQL)). I've only worked at smaller orgs but have only been personally exposed to Oracle, MSSQL, MySQL, and a tiny bit of postgres (that is the one I am least familiar with, and thus least comfortable using) over the past 20 years. I have been told that IBM has a much stronger presence on the east coast of the US than west where I am at, so that could be a big factor as well, I am not sure.
I suspect it's more likely that IBM goes out and acquires someone like EnterpriseDB(assuming they aren't owned by some super big company already I don't know), similarly how Oracle acquired MySQL. Then tout that combination with Red Hat. Leave Db2 for legacy and push Postgres going forward.
I think you're right - PostgreSQL is a much easier sell for new stuff than Db2. I could totally see IBM buying EDB - Keep existing Db2 customers happy, and make sure that if those existing customers are tempted to stray from Db2 to open platforms, you can upgrade their support level to include PostgreSQL support and retain them.
While I agree with you in general, there are still areas where the choice is a bit restricted. There still is new development on the AS/400 (or iSeries or whatever name IBM is giving it this month) and those machines come with their version of DB2 (DB2/400) well integrated within the OS.
This post has been deleted by its author
If any of the sales droids out there think I ever chose a database engine based on advertising, kindly let me clear up that delusion for you: ABSOLUTELY NOT!
That said, I still avoided DB/2 for years because it didn't support self-referential and recursive structures in the way I needed. It is great for a lot of relational workloads, but not hierarchical data, which is a big factor in my applications development for several decades now.
Perhaps that has changed over the years, but I've no particular reason to investigate whether it has or not - PostgreSQL quite handily serves me needs, and those of the projects I'm working on for clients.
The biggest DB2 problems are a paucity of information and tools when developing, a query optimiser that regularly disappears up its own wazoo in production and tanks the performance, and having to wait for the DBAs or consultants to come in and wave their dead chicken over it to rescue everything.
DB2 courses don't concentrate on writing performant SQL which won't make DB2 barf because it will barf, they concentrate on flying in afterwards and picking up the pieces.
DB2 and its ecosystem is a closed shop and that's why developers can't be bothered with it. Migrating to cloud won't change that.
OS/2 being the poster child of how to take a fantastic product, and kill it through your own inability.
I coded in C++ for OS/2, and it was a joy to use compared to Windows. WE all know it was the Betamax of OS's
I often think to myself, where/what would OS/2 be now if it had come out on top. Undoubtedly a lot better/further ahead than Windows
My first encounter with DB/2 was also with DB/2 for OS/2 - Application was written in C, with embedded SQL that was run through a pre-processor prior to compilation, using Microsoft C 6.0, for OS/2 (...1.3x).
Query Manager/2 could have been better - a bit feature poor - then again, that was about 20 years ago, but the you had the likes of Access (2.x)? providing richer front-end features at the time - QM being a bit behind the curve there.
I still have the IBM Redbook that I used to learn about application development with DB/2 for OS/2
DB2 WUL used to be the tool that would do 90% of what Oracle would but didn't need a whole team of DBAs constantly fettling it. Through the 2000’s those were my choices (Oracle RAC if NFRs required, DB2 if they didn't) until sometime about a decade ago, MS SQL took over as good enough for real volume and even easier to set up and manage. These days for relational on Windows it's MS SQL, on Linux PostGRES and on z DB2, I would never advise anyone to go Oracle unless trapped there already. Anything requiring Continuous Availability goes public cloud.
Hey, you are going to earworm, let's do it all the way!
DB DB2, Where are you?
We got a lot of work to do now.
DB DB2 Where are you?
We need some data from you now.
Come on DB2, I see you
Pretending you got blocking
But you're not fooling me, 'cause I can see
The way you thrash the storage
You know we got a business to run
So, DB2 be ready for your act
Don't hold back
And, DB2, if you come through
You're gonna have yourself a another disk pack
That's a fact
DB DB2, here are you
You're ready and you're willing
If we can count on you, DB2
I know we'll get that vacation.
with support from Ember Crooks playing the part of Velma?
https://en.wikipedia.org/wiki/Velma_Dinkley
"She is seen as the "brains" of the group."
The article says: "IBM isn't doing the best job of marketing Db2, in general, both on Linux-Unix-Windows and System Z." Please name for me any PRODUCT that IBM does a good marketing. All of IBM's products are nearly invisible to the public. A customer has only the inconsistent pitch of a briefer in a center, or across his desk by a salesperson to understand what IBM is "behind," or "plans," or even -has-. Occasionally a TV ad or two during a sporting event--and even that ad is never a 'product' ad, but some wispy strategy ad like "Cloud," or "AI." Honest to god, the last time I remember a real IBM product promotion was the one-time "OS/2 Fiesta Bowl" in the US. I think IBM's product promotion is pathetic. It's like they believe touting their products is somehow 'unclean...'
It does seem to me that the IBM route to market is reliant on people saying 'get some IBM consultants in', and said 'consultants' then shoehorn in IBM products.
I suspect because the wider market will simply look at said products, shrug collective shoulders, and say 'nah, I can do all that with these open source battle hardened, trusted products'
Their best move is to offer it as a kick ass dbaas across the major cloud platforms such as AWS, Azure and Google Cloud.
The problem with legacy software vendors is that they’re always too worried about short term cannibalization to do what’s best for the long term health of their products and move them onto competitive platforms. Microsoft is the only one that finally got over that with their current CEO and has seen their stock climb over 15X. If only IBM could see the light. They aren’t the most important platform anymore and simply need to be everywhere. Just make all your closed source products “cloud first” and charge for the saas
And there’s so much more they can do then just be Amazon Aurora for their customers. Think snowflake, databricks, and that’s all just scratching the surface
I write enterprise software that reads and writes data from/to z/OS Db2, and our customers (and there are many) run billions of records in and out of it, every day.
I get the impression that it is a big deal for those who want a truly industrial strength database, running on the industry's most reliable hardware.
I worked at IBM for almost 2 decades. All of that time in DB2. I also worked in DB2 development at the IBM Toronto Lab. More than 20 years ago I went to our sales people and asked why they didn't give away DB2 for free at universities. Apparently there was a program for that but nobody knew about it. Universities paid lots of money for Oracle databases and tought RDBMS on Oracle.
IBM made so many mistakes and bad decisions. I never understood why the leadership was so weak and ignorant. I left IBM in 2013. This was my farewell email I sent to DB2 All Hands (about 10,000 IBMers around the globe):
After working at IBM for 16 years, I've been in different areas, although always with DB2: support, pre-sales, post-sales, consulting, services, and development. I think this gives me a unique perspective and insight into the world of DB2.
Before I take my leave I want to give some feedback and my thoughts on the future of DB2. I hope that some of my ideas find their way into future planning and will be a turning point for a change in strategy.
Please note that it is not my intention to offend anyone. I write this as constructive feedback, please treat it as such.
If you are not able to read an opinion objectively (without taking it personally) stop reading here.
DB2 is a great product.
Unfortunately a lot of things have changed and so has the quality of DB2. Over the years the quality has decreased more and more.
One of the reasons is that we try to put in as many features as possible instead of concentrating on a few - namely the most needed ones.
Another reason is that the release cycle is too short for a product that has 30 million lines of code and counting.
Moving essential components to countries where labor is cheaper than in North America might be good for accounting purposes, but at the end of the day it is more expensive, because we have to fix a lot more defects, thus doesn't help the quality of the product either. I know that this is something that you don't want to hear, but sugar-coating it doesn't change the fact that it's true.
Which brings me to the next point: IBM has the tendency to sacrifice their very own people (by laying off people with tangible skills) to keep up appearances for our stakeholders. On the other side IBM keeps their bean counters (which get millions in bonuses) who are responsible for wonderful ideas like having to release a new version every year.
This narrow-minded quarterly thinking is killing DB2. We need vision and a firm strategy. And this my friends we do not have.
Our only vision (handed down from our great leaders) is to earn a quick buck. This will not do.
Keep the guys who actually have skills and get rid of all the bean counters.
Over the years IBM has learned to listen a little bit more to their customers thanks to the new beta trials and feedback programs. We have improved our customer experience but we are not quite there yet.
We have to streamline our products again instead of selling bloat ware (I do not want to go into too much detail here but JAVA-fying all useful and fast products that have a small footprint is the wrong approach).
Our customers will not forgive this kind of irresponsible behavior forever.
Please think about it, change the development process and the release strategy to the better. I love DB2 and I always will. I would hate seeing such a wonderful product falling apart.
So Long, and Thanks for All the Fish
IBM also have another kick ass database - https://www.ibm.com/products/informix/editions
The latest v14.10 patch was releases just a few weeks ago, it has nosql and json and great python drivers frequently updated with https://github.com/ibmdb/python-ibmdb (same driver as for DB2)
I use the embedded C version on a raspberry pi and the developer version is free for personal use. I have 1.4TB of data in the largest one.
We use DB2 heavily in our on premise applications (on Z/OS) and for a couple of legacy data warehouse type applications (LUW flavour). I came to DB2 from a SQL server background and was really shocked at how difficult it is to learn and use in comparison to SQL Server. IBM's documentation is fairly impenetrable to a newbie and you don't see many online courses, forums or books out there. You also don't get a GUI query tool by default (we had to buy one). If IBM want to get more people using it they really need to put some effort into building a community around it and making it more approachable.
We are in the process of moving our data warehouse applications to Snowflake. So far the performance is way better than DB2, and there is great documentation with an active and helpful user community so it has been quick to get up and running. I'll be interested to see how total cost of ownership stacks up once we've finished moving over.
Db2 has become a victim at IBM, like Information Server, Optim, Cognos, to the mantra of software must be run as a container under CloudPak for Data.
All investment outside of Cloud Pak for Data has been quietly pulled, even if it will mean lower revenue medium to long term. As for CloudPaks, they have been successful as a licensing / modernization play as RedHat OpenShift was thrown in for free, however, actual successful deployments are about as common as verified sightings of the Yeti in Miami.
The Cloud Pak strategy is deeply flawed and IBM has bet the farm on it.
- Cloud Pak for Data is impossible to install, some customers have simply given up after nearly 6 months of trying to simply install the base product.
- There is no upgrade path between releases
- Did anyone say DR or even backups?
- The sizing for the base install is ridiculous, why do I need 48 to 64 cores? Recently size Db2 on Cloud Pak for Data, for 4 databases, result 128 cores, vs 32 usings VMs and stand alone Db2...
As a 34 year fortune 100 tech zDb2 vet - FINALLY - ibm is getting into the SMART marketing world!
All these years working in the shadows on the GREATEST rDBMS hardware / software set, EVER - FINALLY
https://www.theregister.com/2022/07/20/ibm_db2_operator/
;-]
IBM has seen the light, Hallelujah, Brothers & Sisters!!
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
