Db2 Experts on a Data Science Quest
This is part of a series focusing on the details of each item that needs to be pruned in a Commerce database.
STAGLOG
Staglog is a table in the staging database that records changes in data. Staging triggers on all stagingprop tables write to it when there is a change to any of those tables.… Read the rest
Continue reading »So the easy thing to do on Commerce build is to use your DB2 instance owner for everything related to the database. But that’s not really the best choice. It’s almost always the choice I see when a DBA was not involved with the architecture or build of a Commerce system.… Read the rest
Continue reading »Ok, so there are several good reasons for Backing up your Commerce DB2 database
Schedule DB2 backups starting immediately after instance creation – the most common time that restores are needed is during the build process. Of course the most common cause for needing a restore is human error, but that’s something that is important to protect against during build.… Read the rest
Continue reading »Just a quick tip. When building Commerce environments, select a different database name for each environment (Stage, Prod, etc), even if they are on different database servers. This will help you ensure that you(or developers or whoever else accesses the databases) never do something in the wrong environment.… Read the rest
Continue reading »So I’m starting out my series on DBClean and data pruning items with the one that I have seen cause the most immediate severe performance impact. I’ve seen this one take a site to its knees within two months of go-live.… Read the rest
Continue reading »One of the most important things for performance of Commerce databases is the proper use of dbclean and data pruning.
It is a simple fact of life for OLTP databases that the same database with less data will perform better. This is especially true of Commerce databases, and even before a site has gone live, I try to have data pruning planned, scripted, and running on a regular basis.… Read the rest
Continue reading »There is a flag that can be set on DB2 tables to mark them as “Volatile”. But not everyone knows what a volatile table is or what this does, so I thought I’d write a quick post on it.
A true volatile table is one that is used only for transient data – data that is put into tables and then quickly removed, meaning that a table marked as volatile could have zero rows one minute, 40,000 the next, and then back to zero.… Read the rest
Continue reading »This probably falls more in the DB2 newbie category, but I suspect I may have some readers who are DB2 newbies or at least not veterans.
Several years ago (ok, probably more than 5), DB2 seemed to be considering a “Problem Determination Mastery” certification.… Read the rest
Continue reading »I have generally been a bit disappointed on the information coming out of IBM on supporting Commerce databases. I also meet clients who don’t believe they need a dba or that they can hire someone out of college or with minimal database experience to fill such a role.… Read the rest
Continue reading »So one of the most common questions I get is about moving data between homogenous Commerce databases. Our standard setup includes 4 environments – Dev, QA, Stage, and Prod. Dev/QA are a stagingprop pair, Stage/Prod are a stagingprop pair, and Prod usually has HADR.… Read the rest
Continue reading »Ok, so everyone will tell you that it doesn’t matter if you do runstats on volatile tables. The volatile flag is supposed to tell DB2 that the statistics are absolutely not correct, and heavily bias db2 to use indexes over table scans.… Read the rest
Continue reading »