6b3b2abe4f
73 stackexchange-grounded, 516 model-knowledge (ESCO-seeded gemma3), 0 review_needed (calibration caveat documented). Adapters rebuilt with the full competence sets; final REPORT numbers; all verify checks pass. Known gap: engineering-manager lacks an ESCO package counterpart. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01PDKeXvpT6tENSvyQGLV1Uq
2.6 KiB
esco_uri, esco_label, relation, onet_soc, source, confidence, qa_count, generator, generated
| esco_uri | esco_label | relation | onet_soc | source | confidence | qa_count | generator | generated |
|---|---|---|---|---|---|---|---|---|
| http://data.europa.eu/esco/skill/9ba8fd27-275d-4bad-8c48-f668aa99a578 | balance database resources | essential | 15-1242.00 | model-knowledge | high | 0 | gemma3:27b (prompt-designed and spot-checked by Claude) | 2026-07-10 |
balance database resources — Database Administrator
As a Database Administrator (DBA), 'balancing database resources' isn’t about theoretical optimization – it’s constant firefighting and proactive tuning. Daily, you're looking at things like CPU utilization on your database servers, disk I/O bottlenecks, memory pressure, and network latency. Typical tasks include monitoring long-running queries that hog resources (using tools like Performance Monitor in Windows or top/iotop in Linux), identifying tables needing indexing adjustments, and configuring connection pooling to prevent resource exhaustion from too many simultaneous requests. You'll also be managing storage – adding disk space, archiving old data, and potentially migrating to faster storage tiers.
A big part of this competence is understanding how different applications use the database. A poorly written application can easily overwhelm a perfectly tuned system. So you’re often collaborating with developers to review queries, suggest code changes, or implement caching strategies. Tools like SQL Server Profiler/Extended Events, Oracle's AWR reports, or PostgreSQL's pg_stat_statements are your bread and butter for pinpointing problem areas. Pitfalls include blindly applying 'best practices' without understanding the specific workload, ignoring slow-but-frequent operations (they add up!), and failing to monitor proactively – waiting until users complain is too late.
The ‘cost/risk ratio’ aspect means you aren’t just maximizing performance at any cost. You need to balance speed with storage costs, server licensing fees, and the potential for downtime during maintenance or upgrades. For example, choosing between more RAM (expensive) versus optimizing queries (time-consuming but cheaper). Reliability is key – ensuring backups are running correctly, disaster recovery plans are tested, and servers have sufficient redundancy.
Good looks like a database that consistently meets service level agreements (SLAs), minimal performance complaints from users, predictable resource usage patterns, and the ability to scale efficiently as data volumes grow. It's about preventing problems before they impact business operations, not just reacting to them.
Weitere Anreicherung
Stage-2 source for future practitioner grounding: arXiv cs.SE (software-engineering preprints).