Upgrade Order and S-TAP Compatibility in a Three-Tier Guardium Deployment
Your customer runs Guardium v11.0 patch 620 with one central manager (CM), two aggregators, and 14 collectors. The CM manages 40 database servers through S-TAP 11.0. The change window is six hours. The target is v11.2. The CM has 16 GB RAM and 500 GB free; aggregator B in the DR site has only 80 GB free. During pre-check, the patch installer on the CM reports that several managed units are below the minimum supported version. The customer wants to upgrade collectors first because they generate the audit data, and wants to postpone S-TAP upgrades until after the change window. A DB2 production outage is scheduled two hours into the window. Explain the sequence and constraints, and identify what must be verified before touching any unit.
1. What upgrade order should be used, and why is the customer's proposed collector-first order unsafe?
Read the worked answer
The safe order is CM -> aggregators -> collectors, then S-TAPs in controlled waves. The CM holds version metadata and management APIs; a managed unit that is ahead of the CM can be rejected or left in an unsupported state. Aggregators come next because collectors send audit data through them; upgrading collectors first risks a newer collector feeding an older aggregator. The customer's collector-first plan is therefore unsafe even though collectors generate data. S-TAP upgrades are separate: confirm the S-TAP-to-collector interoperability matrix, keep S-TAPs at 11.0 only if supported, and use GIM to upgrade them after their collector is stable. Do not start the DB2 outage until the CM, both aggregators, and the DB2 collector path have passed validation.
2. What pre-checks and rollback evidence should be collected, especially for the DR aggregator with only 80 GB free?
Read the worked answer
Collect CM and aggregator backups, exported policies, GIM status, /var and /tmp free space, patch level, certificates, NTP, and S-TAP inventory. For the DR aggregator with 80 GB free, check the installer's staging requirement and current aggregation data size; if free space is below requirement plus a safety margin, expand the volume or move/archive data before upgrade. Take VM snapshots where supported. Rollback evidence should include the exact patch bundles, current versions, and a tested restore step. Schedule the DB2 outage after the DR path is validated, not two hours in as proposed.
3. After the upgrade, what evidence proves audit data is still complete end to end?
Read the worked answer
Validate end to end: all S-TAPs Connected, no K-TAP errors, collector buffers draining, a known test query visible on the collector, aggregation from collector to aggregator successful, and CM aggregation from aggregator successful. Compare pre- and post-upgrade row counts for a fixed time window and check for gaps in the CM report. A green managed-unit icon alone is not proof; the aggregation job log and a real report query are.