Длинная хранимая процедура SQL с таблицами, хранящими все больше и больше столбцов

Question

Этот вопрос относится к хранимым процедурам, написанным на SQL-92
то есть Oracle PL / SQL, SQL Server T-SQL или DB2 SQL

Я поддерживаю хранимую процедуру в 11000 строк.
Я обнаружил, что к концу хранимой процедуры мне нужно вывести 80 столбцов данных.

В этой хранимой процедуре есть 3 различных этапа.

1. Сбор данных (копирование данных из живых таблиц в промежуточные таблицы хранимых процедур)
   Мне нужно выполнить сбор данных для согласованности, потому что данные LIVE (т.е. в таблице элементов) в строке 30 могли бы измениться к тому времени, когда выполнение хранимой процедуры попадет в строку 10000
   Здесь сохраняется атомарность состояния фиксации (нет фиксации, пока не скопированы все необходимые данные)
2. Расчет (много SQL, достаточно сложный, чтобы Курсоры или Представления не выполняли свою работу)
3. Обратная запись в постоянные таблицы (счета, AR, платежи)
   Здесь сохраняется атомарность состояния фиксации (нет фиксации, пока не скопированы все необходимые данные)

«Промежуточные» таблицы используются только в хранимой процедуре.
Они индексируются для соединений по линии, но не имеют
Ограничения ссылочной целостности PK / FK или уникальные индексы
так как это значительно замедлит выполнение, кроме того
указывать обратно на данные в реальном времени (то есть в потоке)

Когда вы получаете до 80 столбцов данных, которые вам необходимо отчитаться к концу сохраненного
процедура, которую вы запускаете с учетом ограничений СУБД (ограничения индекса, ограничения памяти,
SQL присоединяются к ограничениям COST, неконтролируемой подкачки и данных, переходящих в виртуальные память / своп, когда БД считает, что она должна использовать HASH вместо NESTED LOOPS)

Я нормализовал данные LIVE (которые записываются и читаются пользователями с 24/7)

Мне пришло в голову, что способ оптимизации пространства, занимаемого промежуточными таблицами
используется в хранимой процедуре (на шаге 2), чтобы найти составные первичные ключи и назначить
каждый уникальный идентификатор (суррогатный PK), тем самым ссылаясь на n столбцов с 1 столбцом. Тогда я
восстановит эти данные в конце шага 2 и будет готов к
отпишитесь в начале шага 3. Это добавит больше обработки к
шаг 2, но будет скопировано меньше данных. Также отладка заняла бы
больше шагов (отслеживание идентификаторов до фактических данных в промежуточном звене
данные таблицы после выполнения)

Кто-нибудь сталкивался с этим сценарием с длительными хранимыми процедурами?
Кто-нибудь создал суррогатный ключ (заменив составной PK на PK с одним столбцом) в
промежуточные таблицы, которые используются только в хранимых процедурах?

Окупается ли это с точки зрения времени выполнения и используемой памяти / пространства во время
исполнение?

Answer 1

И я думал, что мои 1400 линейных проков были длинными!

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

Можно ли вообще уменьшить 80 столбцов? Я думаю, я спрашиваю, если вы использовали select * с объединениями, где объединенные повторы будут повторяться в запросе и от них можно будет отказаться.

Answer 2

Я создал несколько длинных SProcs и всегда использовал суррогатный ключ для столбца Indentity . Можно ли переосмыслить то, что делается, и создать отдельные временные таблицы для каждого промежуточного шага?

Я должен был сделать это в прошлом. В конце я " сшил " все отдельные временные таблицы в мой окончательный вывод.

Answer 3

Почему бы вам не попробовать написать пакеты служб SSIS. Большая часть ваших вычислений будет храниться в памяти SSIS без использования базы данных, кроме записи во временные таблицы.

Вы можете разбить ваш пакет на столько частей, сколько захотите, и процесс будет более легким в обслуживании.

Кстати, 11K sproc - это безумие ... Ничего не поделаешь, должен был сказать, что: -)

Answer 4

«Мне нужно выполнить сбор данных для согласованности, поскольку данные LIVE (т. Е. В таблице элементов) в строке 30 могут измениться к тому времени, когда выполнение хранимой процедуры попадет в строку 10000»

В Oracle вымог бы посмотреть на DBMS_FLASHBACK (или уровень изоляции SERIALIZABLE) для этого уровня согласованности.Флэшбэкинг-запросы могут избежать необходимости повторного копирования всех данных.

Я проделал аналогичное упражнение для переноса данных - множество временных таблиц.Одним из факторов для проверки является то, что статистика собирается в соответствующие моменты времени для временных таблиц.Если эти таблицы, как правило, пустые, то статистика в конце может все испортить.