У меня есть ситуация, которой я не могу найти объяснение, вот оно. (Я буду использовать гипотетическую информацию, так как оригинал действительно большой.)
У меня есть таблица, скажем:
table_a
-------------
name
last name
dept
status
notes
И эта таблица имеет триггер на вставку, который выполняет большую проверку информации, чтобы изменить поле состояния новой записи в соответствии с результатами проверки, некоторые из проверок:
- check for the name existing in a dictionary
- check for the last name existing in a dictionary
- check that fields (name,last name,dept) aren't already inserted in table_b
- ... and so on
Дело в том, что если я делаю вставку в таблицу через запрос, например
insert into table_a
(name,last_name,dept,status,notes)
values
('john','smith',1,0,'new');
для выполнения всего процесса проверки, обновления поля статуса и вставки записи в таблицу требуется всего 173 мс. (процесс проверки выполняет все поиски по индексам)
Но если я попробую это через SQLloader, прочитав файл с 5000 записями, потребуется около 40 минут для проверки и вставки 149 записей (конечно, я его убил...)
Итак, я попытался загрузить данные, отключив триггер (для проверки скорости), и я получил, что он загружается, как и все записи, менее чем за 10 секунд.
Итак, мой вопрос: что я могу сделать, чтобы улучшить этот процесс? Моя единственная теория заключается в том, что я мог перегружать базу данных, потому что она загружается так быстро и запускает много экземпляров триггера, но я действительно не знаю.
Моя цель — загрузить около 60 файлов с информацией и проверить их через процесс в триггере (хотя я готов попробовать другие варианты).
Я бы очень признателен за любую помощь, которую вы можете предоставить!
ДОПОЛНЕНИЕ---------------------------------------------------------- ---------------------------------------
Спасибо за ответ, теперь я прочитаю все об этом, теперь надеюсь, что вы можете помочь мне с этой частью. позвольте мне объяснить некоторые функции, которые мне нужны (и я использовал триггер, потому что не мог придумать ничего другого)
поэтому данные таблицы поставляются с этими (важными) полями:
pid name lastname birthdate dept cicle notes
данные приходят вот такие
name lastname birthdate dept
теперь триггер делает это с данными:
Вызывает функцию для расчета pid (вычисляется на основе имени, фамилии и даты рождения с помощью алгоритма)
Вызывает функцию для проверки имен в словаре (это потому, что в моем словаре у меня есть отдельные имена, то есть, если человека зовут Джон Аарон Смит Джонс, функция разбивает Джона Аарона на две части и ищет Джона и Аарона в словаре в отдельные запросы, вот почему я не использовал внешний ключ [чтобы избежать большого количества комбинаций john aaron, john alan, john pierce..etc]) ---> как бы застрял на том, как реализовать это с ключами, не меняя словарь ... может быть, с ПРОВЕРКОЙ ?, внешний ключ фамилии был бы хорошей идеей.
Получает цикл из другой таблицы в соответствии с отделом и текущей датой (поскольку человек может дважды появляться в таблице в одном и том же отделе, но в другом цикле) ---> как я могу получить это значение цикла более эффективным способом для сделать правильный поиск?
И, наконец, после того, как вся эта проверка выполнена, мне нужно точно знать, какая проверка не была выполнена (таким образом, примечания к полю), поэтому триггер объединяет все строки неудачных проверок, например:
lastname not in dictionary, cannot calculate pid (invalid date), name not in dictionary
я знаю, что если проверка ограничения не выполняется, все, что я могу сделать, это вставить запись в другую таблицу с сообщением об ошибке ограничения, но это оставляет мне только одну проверку, я прав? но мне нужно проверить их все и отправить отчет в другой отдел, чтобы они могли просмотреть данные и внести в них все необходимые корректировки.
В любом случае, это моя ситуация прямо сейчас, я изучу возможности и надеюсь, что вы сможете пролить свет на общий процесс. Большое спасибо за ваше время.
name
иlast_name
вместо использования триггера рассмотрели ли вы ограничения внешнего ключа, которые ссылаются на таблицу (при условии, что она есть), которая представляет ваш словарь? Для третьей проверки вы имели в видуtable_a
илиtable_b
? Если вы имели в видуtable_a
, рассматривали ли вы вместо этого уникальное ограничение? Если вы имели в видуtable_b
, вы могли бы рассмотреть возможность использования одной таблицы вместо (или в дополнение), чтобы вы могли использовать уникальное ограничение для обеспечения уникальности - удивительно сложно написать триггер, чтобы сделать это правильно при одновременных вставках/обновлениях (вам нужно использовать блокировку). - person Brian Camire   schedule 03.07.2013