В общем, у меня возникнут вопросы по поводу модели данных, если вы обнаружите, что регулярно обновляете T2 на основе данных в T1, что звучит как система очень OLTP-типа. Это подразумевает отсутствие нормализации, которая касается. У вас может быть совершенно веская причина иметь отдельную таблицу T2, которая реплицирует некоторые данные в T1 (т.е. вы пытаетесь поддерживать запросы типа DSS с денормализованным объектом в дополнение к запросам типа OLTP с нормализованными объектами) в этом случае было бы полезно понять деловую цель T2.
Если это случай попытки поддержки запросов типа DSS с денормализованным объектом, который объединяет данные из нескольких нормализованных таблиц, моей первой мыслью было бы создать T2 как материализованное представление, а не как таблицу. Ваше материализованное представление может постепенно обновляться через запланированный интервал (оно также может обновляться при фиксации изменений, но, поскольку это происходит синхронно, это может замедлить вставку сеансов). Вам потребуются материализованные журналы представлений в базовых таблицах, которые добавят некоторые накладные расходы к операциям DML, но это будет меньше, чем накладные расходы для триггера, особенно если каждое обновление обновляет 300-рядные строки (при условии, что 300k - это число строки обновляются для 100 обновлений в секунду).
Вы также можете использовать потоки для поддержки T2. Это существенно устранит накладные расходы на отслеживание изменений в операциях DML, потому что Streams просто читает данные повтора. Вам придется включить дополнительное ведение журнала, если оно еще не включено, что может незначительно увеличить объем данных, записываемых для восстановления, но маловероятно, что это будет заметно. Однако для настройки потоков будет немного больше работы - вам нужно написать собственный обработчик применения, который будет принимать изменения из T1 и обновлять T2. И T2 всегда будет отставать от T1 хотя бы на несколько секунд.