Поведение менялось несколько раз
TM-блокировка накладывается в RX режиме (и держится, препятствуя изменению структуры), но на сам момент проверки пытается захватить в режиме SRX (или S?)
В 9-ке, насколько помню, блокировочка была RS

Что SX это и есть RX

Как поймать, какая блокировка будет на момент проверки, надеюсь, не надо объяснять?

Не знаю, что ты неправильно понял

Изменение (INSERT/UPDATE/DELETE) дочерней или родительской таблицы накладывает RX (другое название SX) блокировку на обе таблицы, чтобы предотвратить изменение структуры обеих таблиц.

При модификации родительской таблицы (UPDATE/DELETE) при неиндексированном внешнем ключе на время операции пытается еще дополнительно получить S (shared) блокировку на дочерней таблице. Что вызовет ожидание, если кто-то уже изменил родительскую или дочернюю таблицу (повесил RX блокировку на дочернюю таблицу)
При вставках в родительскую или при индексированном ключе на дочернюю таблицу вешается только RX, что совместимо с обновлениями, сделанными в других сессиях.

Это поведение сейчас в 11g, оно несколько раз менялось в деталях и не всегда точно отражалось в документации.

В 10g (и раньше, непомню точно, возможно во всех предыдущих версиях) при изменении дочерней на родительскую таблицу накладывалась менее ограничивающая блокировка RS (SS), что так же предохраняла от изменения структуры, но позволяла, например создать еще один внешний ключ на эту же родительскую таблицу (Share совместима с Row Share, а вот с Row eXclusive уже нет).
С 11g при изменении в какой-либо дочерней таблице нельзя поднять еще один внешний ключ на эту же родительскую таблицу

С секционированными таблицами там еще блокировки вешаются на секции и там уже SRX появляются, если склероз не изменяет

Я так понимаю, у них в документации сделана попытка упростить термины
Типо TM-блокировки Row Share / Row eXclusive -- RS/RX (SS/SX) не считаются FULL TABLE LOCK, в отличии от S / SRX (SSX) / X

Хужее, что подобная тенденция и на MOS:
Текущая "Foreign Keys, Indexes and Locking (Doc ID 1945574.1)" тоже отсылает в доку и стыдливо умалчивает о Row TM блокировках
И только отсылка оттуда же к древней "Documentation Correction to 9.2.0 Foreign Key Constraint Locking Behaviour (Doc ID 223303.1)" немного проясняет:...no table locks of any kind are acquired...

There are errors in this information.

Starting in version 9.2.0, a Row-SS lock is taken on the parent table for any DML issued against the child table... Further, there will be a ROW-SS lock taken on the child table for any INSERT/DELETE/UPDATE issued against the parent table when an index on the foreign key column of the child table is defined. There will be a ROW-SX lock taken on the child table for an DELETE issued against the parent table when no index on the foreign key column of the child table is defined and a delete cascade constraint is defined.
...
This change in behaviour was introduced in version 9.2.0
...
This new locking behaviour is an expected behaviour for the Oracle code. As only shared locks are involved, it does not prevent DML from being issued against either the child or parent tables. It will prevent operations that require an exclusive table level lock.