Тема "оптимизация" не сводится к какой то одной галочке, которую надо включить.
Начать нужно с кода этой "транзакции", изучения модели данных, потом посмотреть статистику выполнения (трейс и актуальные планы).
Из этого можно будет хоть что то сказать по теме (предположить, какие в самых общих чертах есть варианты, и что дальше нужно исследовать).

1. Много мелких изменений делать дольше, чем одно большое, как правило.

2. Убедитесь, что всё это делается именно в одной транзакции, в одиночных транзакциях получится в десяток раз медленней. У вас написано begin tran, или вы транзакцией называете бизнес-операцию?

3. Смотрите, сколько занимает каждая операция, может, есть те, которые сильно медленней - тогда изучайте их индивидуально.
Снимите трейс с записью в таблицу, потом его можно анализировать запросами, например, выводить статистику по типам операций, по времени выполнения в начале ив конце, ну и т.д.

Да тут 300 Мб тоже сферические, автор же не говорит, что это за цифра, в его понимании. Может, это запись 30 млн. строк по 10 байт (int, int, smallint) каждая?
Или там "цикл с записью простых объектов" получает каждый объект снаружи через веб-сервис?

Повторю, нужны хоть какие то детали.
Например, трейс одного прохода "цикла".

Ну вот, что я говорил? :-)
Вообще да, не те размеры, что бы были проблемы именно из за размера.
Но умеючи можно и, ээээ, этим сервер сломать.
Можно писать в цикле во временную таблицу, а потом сделать вставку в постоянную.
Так можно сделать транзакцию короче, что полезно при многопользовательской работе.

Второй приёмчик - разбирать XML и вставлять данные каким то более оптимальным способом, например, используя XMLBulkLoad, или свой балко-подобный код. Так можно на рядовом железе довести разбор XML со вставкой в БД до десятков или сотен мб/сек
Но это если действительно есть проблема с производительностью (например, если у вас поток таких файлов по 300 мб), в противном случае можно не заморачиваться, не те объёмы, делайте на чём умеете.