Ефективно передавати велику кількість (84 мільйонів рядків) даних

У мене близько 84 мільйонів рядів. З цих усіх їх потрібно перенести в окрему базу даних на одному сервері, тоді я видаляю, щоб видалити близько 60 мільйонів рядків із вихідної бази даних.

84 мільйони рядків - це все в одній таблиці. Сама таблиця становить 90% всієї бази даних.

Отже ... Джерело: 84 мільйони рядків -> 24 мільйони рядків Місце призначення: 0 рядків -> 84 мільйони рядків

Джерело працює в повному режимі відновлення, призначення буде працювати просто.

Мені цікаво, який би був найефективніший спосіб зробити це?

План A:

1) ВСТАВКА В НАЗАД, ВИБІРТИ * З джерела

2) джерело TRUNCATE

3) ВСТУПИТИ В Джерело SELECT * ІЗ місця призначення, Звідки Keep_condition = 1

План Б:

1) Відновлення резервної копії вихідної бази даних як бази даних призначення

2) Опускайте всі таблиці, крім тієї, яка потрібна в базі даних призначення

3) джерело TRUNCATE

4) ВСТУПИТИ В Джерело SELECT * ВІД місця призначення, де Keep_condition = 1

План C:

1) ВСТАВКА В НАЗАД, ВИБІРТИ * З джерела

2) ВИДАЛИТИ джерело, де зберігати_умова = 0

чи щось інше?

Дякую

Я хотів би додати, що як би ви не вирішили підійти до цього, вам потрібно буде проводити пакет цих транзакцій . Останнім часом мені дуже пощастило із пов’язаною статтею, і я ціную те, як вона використовує індекси на відміну від більшості пакетних рішень, які я бачу.

Навіть мінімально зареєстровані, це великі транзакції , і ви можете витратити багато часу, займаючись наслідками ненормального росту журналу (VLF, обрізання, розмір права тощо).

Дякую

"Ефективне" може застосовуватися для використання файлів журналу, продуктивності вводу / виводу, часу процесора чи часу виконання.

Я б спробував досягти мінімально зареєстрованої операції, яка була б досить ефективною з точки зору ведення журналу. Це повинно заощадити певний час виконання, як бонус. Якщо у вас є простір tempdb, для вас може працювати наступне.

CREATE TABLE #temp;
ALTER source -> BULK_LOGGED recovery model

BEGIN TRANSACTION;

    INSERT INTO dest SELECT FROM source;
    INSERT INTO #temp SELECT FROM source WHERE keep_condition=1;
    TRUNCATE TABLE source;
    INSERT INTO source SELECT FROM #temp;

COMMIT TRANSACTION;

ALTER source -> FULL recovery model
DROP TABLE #temp;

Щоб відбулася операція з мінімально зареєстрованим журналом, має виконуватися ряд умов, включаючи відсутність резервних копій, які зараз виконуються, базу даних, встановлену в BULK_LOGGEDрежимі відновлення, і залежно від ваших індексів цільова таблиця може бути порожньою. Частина цієї поведінки також змінилася (покращилася) від SQL Server 2005 до 2008 року.

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

SET STATISTICS IO ON;
SET STATISTICS TIME ON;

.. і подивіться, що працює найкраще.

РЕДАКТУВАННЯ . Під час виконання операцій з масовим журналом переконайтесь, що ви робите резервну копію (повний журнал трансакцій) до та після операції, якщо вам потрібна можливість відновлення в часі і ви підозрюєте, що в базі даних може відбуватися інша діяльність в той же час, коли працює ваше ETL.

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

Чому б не БКП?

1. Завантажте резервну частину
2. Змініть джерело на груповий запис

3. Відкрити командний рядок

4. bcp server.sourcedb.table out Filename.flt -T -c

5. bcp "SELECT * FROM sourcedb.table WHERE keep_condition = 1" queryout Filename2.flt -T -c

6. bcp Server.destinationdb.table in Filename.flt -T -c -b1000

7. перевірити дані

8. З SSMS Обрізати таблицю джерел
9. bcp server.sourcedb.table in Filename2.flt -T -c -b1000
10. Зміна джерела повернення на повний

Не думайте, що вам слід рекомендувати змінити модель відновлення без повної резервної копії бази даних або резервної копії t-log до і після . Однією з особливостей моделі відновлення BULK_LOGGED є те, що ви втратите можливість виконувати точне час відновлення для t-журналів, що містять операції масового входу. Класичний сценарій: нічне повне резервне копіювання, погодинна резервна копія t-log. Ви змінюєте модель відновлення на масовий запис і починаєте свою операцію. Щось піде не так, і транзакція відкочується назад (або ви її не використали). Однак ви не впевнені, що ще відбувається в базі даних, тому ви хочете відновити до відомого хорошого моменту.

Коли можна відновити назад? Остання погодинна резервна копія t-log, яка не містить операцій масового входу, потенційно втрачає n хвилин транзакцій. Повне резервне копіювання або t-log резервного копіювання перед зміною моделі відновлення створить точку резервного копіювання. Який ви обираєте, залежить від вашої RTO.

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

Однак вартість включення розділу може зробити цю операцію дорожчою в цілому.