fix(db): introspect the Oracle schema in a fixed number of queries [10.16]

[oc-tmueller]

The problem

occ maintenance:install against Oracle takes over 40 minutes on 10.16, while the same install on master finishes in under a minute. This is what makes the Oracle CI job on this branch look hung.

Root cause

The bundled doctrine/dbal 2.13 introspects a schema table by table. AbstractSchemaManager::listTables() loops over listTableDetails(), which issues four queries per table — columns, indexes, foreign keys, table comment. Each of them inlines the table name as a literal, so Oracle cannot share cursors and hard parses every single one, measured at ~230–245 ms each.

OC\DB\Migrator::getDiff() then asks for the full schema once per applied migration. With 68 migrations and ~48 tables that is thousands of hard parsed queries, so the cost grows with tables × migrations.

doctrine/dbal batches this natively from 3.4 onwards (selectTableColumns / selectIndexColumns / selectForeignKeyColumns), which is why master, on dbal 3.10, was never affected.

Why not just upgrade doctrine/dbal

• No 2.x release behaves like 3.x: 2.13.9 is the last 2.x and contains none of the batched methods.
• PHP is not the blocker — dbal 3.10.6 requires php ^7.4 || ^8.0 — but the 2→3 migration on master touched 181 files and changes public API (Statement → Result, DBALException → Exception). Shipping that in a 10.16 patch release would break third-party apps.

So this PR adds an ownCloud subclass instead. No vendor code is patched.

The change

OC\DB\OracleSchemaManager extends Doctrine's OracleSchemaManager and overrides listTables() to read the whole data dictionary in a fixed number of queries, grouping the rows by table in PHP and feeding them to the same unmodified _getPortableTable*List() consumers. OC\DB\Connection::getSchemaManager() returns it for Oracle platforms only; every other platform is untouched.

The schema asset filter semantics are preserved, since the table list still comes from listTableNames().

Results

	before	after
introspecting the 48 table install	194 queries (= 4×48+2)	6 queries, flat
introspection at 30 / 62 tables	122 / 250 queries, 23.6 s / 57.1 s	6 queries, 1.70 s / 1.67 s
occ maintenance:install, Oracle + PHP 7.4 + oci8	2603 s (43 min 23 s)	30 s

6 flat queries is exactly what master's dbal 3.10 does.

Correctness evidence

• Doctrine\DBAL\Schema\Comparator reports no difference between the stock and the batched introspection in both directions, at 30 and at 62 tables, including edge cases: tables without comments, tables without foreign keys, a primary-key-only table, and quoted mixed-case identifiers.
• Two independently produced physical schema dumps — sqlplus and the data dictionary only, no PHP or dbal involved — are identical: 48 tables, 285 columns, 136 indexes, 177 index columns, 242 constraints, 252 constraint columns, 48 table comments, 35 sequences, including every column type, length, precision, scale, nullability, ordinal, default and comment. The only differences were Oracle's system-generated SYS_C… names, which differ between any two installs.
• tests/lib/DB passes on Oracle (275 tests) and on SQLite (275 tests, the 3 new ones skipping), which also proves the non-Oracle fall-through.
• php-cs-fixer and phpstan are clean.

Tests

tests/lib/DB/OracleSchemaManagerTest.php asserts that Oracle connections get the batched manager, that its result is Comparator-identical to the stock one, and that the query count does not grow when the table count triples.

Known trade-off

When setFilterSchemaAssetsExpression filters out most tables, the batched queries still scan the whole user schema and discard the extra rows. More rows scanned, but 6 queries instead of 4N — and this is what dbal 3.4+ does too.

🤖 Generated with Claude Code

[oc-tmueller]

Retargeted onto the branch of #41815, because Oracle CI does not exist on 10.16 yet — that is what #41815 adds. Stacking the two makes the PHP Unit (7.4, oracle:23) job run here, so the speedup is visible in CI rather than only in the local measurements above.

Two consequences worth noting for review:

• The commit list also shows fix(composer): consume icewind deps from GitHub mirrors… (fix(composer): consume icewind deps from GitHub mirrors to survive Codeberg outages [10.16] #41816, already on 10.16). fix(db): speed up Oracle schema introspection and run the PHPUnit DB suite against Oracle again [10.16] #41815's branch predates that merge, and it is needed for composer install to survive a Codeberg outage — the failure that broke an earlier run of fix(db): speed up Oracle schema introspection and run the PHPUnit DB suite against Oracle again [10.16] #41815. It drops out of this diff automatically once fix(db): speed up Oracle schema introspection and run the PHPUnit DB suite against Oracle again [10.16] #41815 lands on 10.16 and GitHub retargets this PR.
• Merge order therefore matters: fix(db): speed up Oracle schema introspection and run the PHPUnit DB suite against Oracle again [10.16] #41815 first, then this one. The other way round, fix(db): speed up Oracle schema introspection and run the PHPUnit DB suite against Oracle again [10.16] #41815's Oracle job still pays the 43 minute install.

[oc-tmueller]

CI now confirms the measurements. Same workflow, same runner class, same gvenzl/oracle-free 23 service container:

step	#41815 without this fix (job)	with this fix (job)
Install Server	30 min 11 s, failure	62 s, success
Run PHPUnit	skipped — install never finished	15 min 4 s, success
job total	failed after ~32 min	pass, 18 min 21 s

The baseline job never executed a single test. This is the first time the Oracle PHPUnit suite on 10.16 gets past installation.

All checks are green: oracle:23, sqlite, mariadb:10.6, mariadb:10.11, mysql:8.0, postgres:10.21, code style, lint, semantic commits, CLA.

[phil-davis]

Is all this temp debug needed?
Back it out?
@oc-tmueller