A cloud-hosted database is billed on consumption, including I/O requests, storage and data transferred out. After a partner integration went live, the monthly bill rose sharply although the user count stayed flat. Which practice will show what is driving the increase?

Data metering measures resource consumption that drives cost in consumption-based services: I/O requests, compute time, storage, backup storage and data egress. Breaking consumption down by resource type and, where possible, by client, application or connection lets the DBA attribute the increase to the partner integration and identify the specific behavior, such as frequent full-table reads, large exports or repeated polling, that should be optimized or charged back. Comparing settings with the baseline configuration detects configuration drift, which could raise cost in some cases, but here the change coincides with new workload, not with a settings change, and a configuration diff does not show who consumed what. The entity relationship diagram documents structure and relationships; it can show which tables the integration could touch but provides no measurements of actual usage or cost. Purchasing reserved capacity may reduce unit prices, but committing to it before understanding the drivers risks locking in spending on wasteful behavior, and reserved pricing typically does not cover egress or per-request charges. Exam caveat: metering supports cost management, chargeback, capacity planning and detection of abnormal use. Operational check: enable consumption reporting at the finest available granularity, tag or label resources and connections by consumer, compare usage before and after the go-live, and work with the partner to reduce the heaviest operations.