SQL Server - Тимчасові та фізичні таблиці

14

На моєму місці руху є рух, щоб відійти від використання таблиць #temp і замість цього використовувати постійні фізичні таблиці з SPID. Кожного разу, коли б раніше ВСТАВЛЯЛО INTO таблицю #temp, тепер INSERT INTO dbo.MyPermanentTable (SPID, ...) VALUES (@@SPID, ...)потрібна анкета - разом із купою DELETE FROM dbo.MyPermanentTable WHERE SPID = @@SPIDвисловлювань на початку, наприклад, збережена процедура. Крім того, безперечно, що там, де використовуються ці "постійні таблиці для зберігання тимчасових даних", потрібно бути обережними, щоб включити WHERE SPID = @@SPID.

Логіка, що рухається до цієї практики, полягає в тому, що вона покращить загальну продуктивність сервера, на якому запущені запити (за рахунок зменшення вводу / виводу та суперечок у tempdb). Я не захоплююсь цим підходом з кількох причин - це некрасиво, потенційно небезпечно і, здається, може зашкодити виконанню запитів, які використовують нову схему.

Хтось має досвід із цим чи подібними підходами до усунення таблиць #temp?

sql-server performance

— Буде A
джерело

18

Можна досить легко продемонструвати, що це не зменшить ІО, ні спори, а натомість збільшить обоє.

IO : Кожен рядок, вставлений, прочитаний або видалений із таблиці #temp, тепер буде вставлений, прочитаний або видалений із таблиці @@ SPID. Але кожен рядок буде ширшим із додатковим стовпчиком @@ SPID, отже, кількість потрібних сторінок трохи збільшиться, а IO буде настільки дещо більшим. Але ще важливіше - падіння таблиці #temp та ініціалізація таблиці #temp нового сеансу за сеансом тепер доведеться моделювати за допомогою DELETE FROM @@spidTable WHERE spid = @@SPIDі, таким чином, скорочувати / створювати операцію (тобто операції з управління масштабами сторінки) будуть трансформовані. в рядкових операціях, незрівнянно повільніше.
Зміст : Кожне сканування, яке використовувало блокування сторінок у таблиці #temp, тепер матиме можливість заблокувати сторінку неспорідненими рядками-павуками, створюючи таким чином раніше неіснуючий суперечку. Кожне оновлення, що робить більше, що перевищує поріг ескалації блокування, має можливість ескалації блокування до блокування таблиці та таким чином блокувати кожен інший шпід.

Тож правда, що ви не вдаритесь до міфічної суперечливості IAM / SGAM / GAM у tempdb, єдиною причиною цього стане те, що ваші операції стануть набагато повільнішими завдяки звичайному додатковому IO та додатковій суперечці.

— Ремус Русану
джерело

Я повністю згоден з вищезгаданим Ремусом - і дякую за відмінну відповідь. Проблема полягає в тому, що ми наносимо передбачуваний показник ефективності третьої програми (з декількома базами даних на сервері, на якому ми маємо власну базу даних - нам потрібно виконувати запити проти їх даних). Я все ще думаю, що ти маєш рацію, розум - Я розумний, я б очікував, що новий підхід буде набагато гіршим, ніж раніше - суперечить мудрому, з точки зору tempdbs, все буде краще - від нашого, дещо гірше.

— Чи буде

Скільки у вас файлів tempdb? Стандартна настройка насправді не має масштабів - у вас повинно бути кілька файлів набору tempdb dile та log, по одному на видиме ядро процесора (по 2 у випадку, якщо гіпер-v).

— TomTom

1

Ви повинні прочитати ці дві статті: sqlskills.com/BLOGS/PAUL/post/… та sqlskills.com/BLOGS/PAUL/post/…, оскільки вони вирішують найпоширеніші проблеми масштабованості tempdb.

— Рем Русану

@TomTom whoa, whoa. Кілька файлів журналу? Дійсно?

— Аарон Бертран

5

Це здається кардинальним рішенням. В Інтернеті є чимало статей про зменшення суперечки з tempdb (та оптимізацію її використання) - чи ваш орган ретельно вивчив цю дорогу?

http://www.sql-server-performance.com/tips/tempdb_p1.aspx

http://www.sqlservercentral.com/blogs/robert_davis/archive/2010/03/05/Breaking-Down-TempDB-Contention.aspx

http://searchsqlserver.techtarget.com/tip/Optimize-tempdb-in-SQL-Server-by-striping-and-splitting-to-multiple-files

тощо.

+1 повністю згоден - оптимізуйте tempdb, не винаходити колесо, оскільки ваша реалізація буде гіршою. :)

Я все за те, що не йду цим шляхом, якщо це не виправдано - дякую за інформацію Бен - я розслідую і внесу пропозиції до нашої довідкової служби, якщо це доречно.

— Чи буде

2

Звуки мені , як ви повинні бути усунення несправностей проблеми з продуктивністю в межах TempDb, є кілька пропозицій в тут

— SPE109
джерело

Здається корисним - спасибі SPE109, я перегляну це питання та викладу рекомендації до нашої довідкової сторони, якщо це доречно.

— Чи буде