Постоянные временные таблицы в SQL?

Возможно ли иметь «постоянную» временную таблицу в MS-SQL? Я имею в виду, что в настоящее время у меня есть фоновая задача, которая генерирует глобальную временную таблицу, которая используется множеством других задач (поэтому я сделал ее глобальной). К сожалению, если таблица становится неиспользуемой, она автоматически удаляется SQL - моя система изящно обрабатывает это, поскольку она просто ставит ее в очередь для повторного построения, но в идеале я бы хотел, чтобы она создавалась только один раз в день. Итак, в идеале я мог бы просто установить что-то вроде параметра тайм-аута, например «Если ничего не касается этого в течение 1 часа, затем удалить».

Я действительно не хочу, чтобы это было в моей существующей БД, потому что это вызовет больше головной боли, связанной с управлением БД (фрагментация, рост журнала и т. чем один гигабайт HD-пространства.

В худшем случае мой план состоит в том, чтобы создать еще одну БД на том же диске, что и tempdb, назвать ее как-то вроде PseudoTempDB и просто справиться с удалением.

Любая информация будет принята с благодарностью!


sql sql-server tempdb
person Mark    schedule 10.05.2009    source источник
comment
Используйте план Б, управляйте сроком службы самостоятельно, нет поддержки того, что вы просите, только в SQL Server.   -  person Lasse V. Karlsen    schedule 10.05.2009
comment
Я нашел этот пост, который может быть полезен: stackoverflow.com/questions/27835/   -  person Kekoa    schedule 10.05.2009
comment
kekoav, насколько я понимаю, табличные переменные работают так же, как временные таблицы (с точки зрения постоянства). Итак, я предполагаю, что переменная таблицы просто исчезнет, ​​как только я перестану к ней обращаться (как и временная таблица).   -  person Mark    schedule 11.05.2009
comment
Отметьте публикацию, которой Кекоа поделился публикацией stackoverflow.com/a/27849/77198, отмечает, что таблица с двойным префиксом хеша например, ##TempTableName будет сохраняться в базе данных tempdb. Даже после того, как объект ссылается или создает его, он выходит за рамки. Чтобы удалить его, нужно явно удалить таблицу или перезапустить экземпляр базы данных.   -  person SQLBobScot    schedule 07.12.2013
comment
@BobF для глобальной временной таблицы ## они сохраняются только в том же экземпляре sql, если таблица остается бездействующей, а созданный экземпляр sql уничтожается, тогда эти таблицы также удаляются. Пожалуйста, поправьте меня, если я ошибаюсь   -  person hardyz009    schedule 13.05.2015

Ответы (5)


arrow_upward
3
arrow_downward

Я бы пошел с вашим планом Б: «создайте еще одну БД на том же диске, что и tempdb, назовите ее как-то вроде PseudoTempDB и просто справьтесь с удалением».

person codeulike    schedule 10.05.2009

arrow_upward
9
arrow_downward

Если вы создадите таблицу как tempdb.dbo.TempTable, она не будет удалена до тех пор, пока:

а — SQL Server перезапускается

b - Вы явно отказываетесь от него

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

person LeoPasta    schedule 11.05.2009
comment
Интересно, так что, если вы создадите его, используя TempDB в качестве базы данных вместо того, чтобы добавлять # или ## в начале, тогда он станет фактически постоянным до перезагрузки (когда tempdb все равно сбрасывается)? Это именно то, что мне нужно - я могу воссоздать его, если его не существует. - person Mark; 11.05.2009
comment
@ Марк, не могли бы вы подтвердить, что все, что говорил ЛеоПаста, правильно или нет? - person peakit; 20.10.2009
comment
@ Марк, это когда-нибудь подтверждалось? - person Code Novice; 16.04.2020

arrow_upward
3
arrow_downward

Как насчет создания постоянной таблицы? Скажем, MyTable. Раз в 24 часа обновляйте данные следующим образом:

  1. Создайте новую таблицу MyTableNew и заполните ее.
  2. В транзакции удалите MyTable и используйте rename_object, чтобы переименовать MyTableNew в MyTable.

Таким образом, вы воссоздаете таблицу каждый день.

Если вас беспокоят файлы журналов, сохраните таблицу в другой базе данных и задайте для нее модель восстановления: простая.

person Andomar    schedule 10.05.2009
comment
Это в основном то, что я изложил выше - единственная разница в том, что вы предлагаете делать это в той же БД. Я, конечно, мог бы поместить его в ту же БД, но, поскольку это бесполезные долгосрочные данные, я не хочу, чтобы они были в резервных копиях для БД (и не хочу усложнять ситуацию исключениями). - person Mark; 11.05.2009
comment
@Mark Хотя я действительно думаю, что «другая база данных и установка для нее модели восстановления: простая» имеет свои достоинства, поскольку позволяет вам использовать многопользовательский SQL Server, не беспокоясь о конфликтах имен в tempdb.dbo.. - person binki; 28.11.2018

arrow_upward
2
arrow_downward

Должен признаться, что дважды ответил на этот вопрос: «постоянный» и «временный» обычно несовместимы! Как насчет немного нестандартного мышления? Возможно, ваша фоновая задача может периодически запускать тривиальный запрос, чтобы SQL не помечал таблицу как неиспользуемую. Таким образом, вы получите прямой контроль над созданием и уничтожением.

person Mark Brittingham    schedule 10.05.2009
comment
Да, немного дихотомии - я просто хочу большее окно для моих "временных" данных. :) На самом деле вам даже не нужно запускать запрос в фоновом режиме, пока у вас есть открытое соединение, которое однажды выполнило запрос к нему, оно останется. Как хак, это то, что я сейчас делаю, но если соединение по какой-то причине обрывается, тогда нужно все перестроить, так что это не такое чистое решение, как мой план Б. - person Mark; 11.05.2009
comment
Это было бы довольно легко сделать. Если временная таблица не содержит слишком много строк, это сделает select count(*) из foo. - person George Silva; 21.10.2009

arrow_upward
0
arrow_downward

Имея 20-летний опыт работы со всеми основными существующими СУБД, я могу предложить на ваше рассмотрение только пару вещей:

  1. Обратите внимание на оксюморонные понятия: постоянные и временные — это полные противоположности. Выберите один, и только один.

  2. Вы не оказываете своей базе данных никаких услуг, записывая данные во временную БД для ручной, полупостоянной, управляемой пользователем основе. Обычные табличные пространства (то есть пользовательские) уже существуют для этой цели. Временная БД предназначена для временных вещей.

  3. Если вы уже знаете, что такая таблица будет использоваться постоянно (ежедневно ЯВЛЯЕТСЯ постоянной), создайте ее как обычную таблицу в пользовательской базе данных/схеме.

  4. Каждый раз, когда вы удаляете и воссоздаете одну и ту же таблицу, вы фрагментируете всю свою базу данных. И получите извращенный бонус, заключающийся в том, что оптимизатор механизма БД никогда не даст вам шанса помочь вам в какой-либо грубой оптимизации. Вместо этого попробуйте обрезать его. Сегменты отката будут вам благодарны за это небольшое облегчение, а дисковое пространство, вероятно, все еще будет выделено, когда вы снова заполните его на следующий день. Вы можете добиться желаемого поведения, указав отдельное табличное пространство и файл данных только для этой таблицы.

  5. И наконец, что еще более важно: прекратите изнурять себя и свой движок БД из-за жалкого 1 ГБ данных. Вы тратите ЦП, циклы ввода-вывода, добавляете задержку, фрагментацию и т. д. ради экономии буквально 0,02 цента реального состояния оборудования. Поговорим о том, как упасть на пол в смокинге, чтобы подобрать коричневый цент. ????

person alejandrob    schedule 25.07.2020