|
|
|
Загрузка большой таблицы из oracle в mssql
|
|||
|---|---|---|---|
|
#18+
Всем привет. Необходимо из оракла залить таблицу в mssql. В таблице ~ 2.5 миллиарда записей. Естественно нужно сделать циклом и проблема заключается в том, что нет ни одного поля за которое можно зацепиться в цикле. Есть номер обращения клиента, идентификатор обращения (оба варчар :( ), но есть дата обращения на которой есть индекс и выборка по этому полю осуществляется достаточно быстро, но проблема в том что там дата + время и чтобы пройтись циклом думал взять в отдельную таблицу distinct дата, но такой запрос крутился несколько часов безрезультатно. Как в таком случае можно попытаться загружать данные? + это не единоразово и нужно в дальнейшем за что то зацепляться чтобы подгружать новые записи инкриментно ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.06.2018, 12:22 |
|
||
|
Загрузка большой таблицы из oracle в mssql
|
|||
|---|---|---|---|
|
#18+
assmsk, Чем вам помешало время? Не нужно получать список всех уникальных дат достаточно знать минимальную и максимальную дату. Остальные даты, при желании, можно сгенерировать простенбким запросом и материализовать в таблицу-справочник... А дальше - грузить порциями по нужному числу дней. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.06.2018, 12:27 |
|
||
|
Загрузка большой таблицы из oracle в mssql
|
|||
|---|---|---|---|
|
#18+
assmskВсем привет. Необходимо из оракла залить таблицу в mssql. В таблице ~ 2.5 миллиарда записей. Естественно нужно сделать циклом и проблема заключается в том, что нет ни одного поля за которое можно зацепиться в цикле. Есть номер обращения клиента, идентификатор обращения (оба варчар :( ), но есть дата обращения на которой есть индекс и выборка по этому полю осуществляется достаточно быстро, но проблема в том что там дата + время и чтобы пройтись циклом думал взять в отдельную таблицу distinct дата, но такой запрос крутился несколько часов безрезультатно. Как в таком случае можно попытаться загружать данные? + это не единоразово и нужно в дальнейшем за что то зацепляться чтобы подгружать новые записи инкриментноЭто задача, которая решается инструментами CDC. Например, GoldenGate. Он читает логи базы данных и передает только те записи, которые изменились. Ему не нужны будут поля с датой или номером версии. Доп. нагрузка будет в пределах 3-5% ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.06.2018, 14:15 |
|
||
|
Загрузка большой таблицы из oracle в mssql
|
|||
|---|---|---|---|
|
#18+
Alexander RyndinЭто задача, которая решается инструментами CDC. Например, GoldenGate. Он читает логи базы данных и передает только те записи, которые изменились. Ему не нужны будут поля с датой или номером версии. Доп. нагрузка будет в пределах 3-5%Для тебя полная копия и передача изменений тождественны? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.06.2018, 14:45 |
|
||
|
Загрузка большой таблицы из oracle в mssql
|
|||
|---|---|---|---|
|
#18+
ElicAlexander RyndinЭто задача, которая решается инструментами CDC. Например, GoldenGate. Он читает логи базы данных и передает только те записи, которые изменились. Ему не нужны будут поля с датой или номером версии. Доп. нагрузка будет в пределах 3-5%Для тебя полная копия и передача изменений тождественны?Ну у человека ведь явно написано: "это не единоразово и нужно в дальнейшем за что то зацепляться чтобы подгружать новые записи инкриментно2 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.06.2018, 14:52 |
|
||
|
Загрузка большой таблицы из oracle в mssql
|
|||
|---|---|---|---|
|
#18+
ElicAlexander RyndinЭто задача, которая решается инструментами CDC. Например, GoldenGate. Он читает логи базы данных и передает только те записи, которые изменились. Ему не нужны будут поля с датой или номером версии. Доп. нагрузка будет в пределах 3-5%Для тебя полная копия и передача изменений тождественны? GG имеет инструменты для создания начальной копии, для которого 2.5 ярда - вполне посильный объем (проблемы, ЕМНИП, были на ~10ярдах) - если, конечно, таблица не обновляется массово. Но таки да - GG стоит денег, и на счет непревзойденных качеств адаптера к MSSQL лично я не в курсе. Но есть и аналоги подешевле - минимум два, один был у HP, еще один у каких-то французов... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.06.2018, 14:58 |
|
||
|
Загрузка большой таблицы из oracle в mssql
|
|||
|---|---|---|---|
|
#18+
В общем-то, команду CREATE TRIGGER никто не отменял ))) Ну и если есть дата, и данные не правятся задним числом, то проблемы лично я не вижу. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.06.2018, 15:05 |
|
||
|
Загрузка большой таблицы из oracle в mssql
|
|||
|---|---|---|---|
|
#18+
Leonid KudryavtsevВ общем-то, команду CREATE TRIGGER никто не отменял ))) Ага. Как и direct insert, и disable trigger. И попробуй потом за вменяемое время синхронизировать промеж собой 2х2.5 ярда, ага... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.06.2018, 15:09 |
|
||
|
Загрузка большой таблицы из oracle в mssql
|
|||
|---|---|---|---|
|
#18+
assmskВ таблице ~ 2.5 миллиарда записей. В таблице происходит только добавление записей или еще идут и изменения? Данные вводятся задним числом? (За вчера например) assmskно есть дата обращения на которой есть индекс и выборка по этому полю осуществляется достаточно быстро, но проблема в том что там дата + время и чтобы пройтись циклом думал взять в отдельную таблицу distinct дата, но такой запрос крутился несколько часов безрезультатно. distinct тут каким боком? Выгружаешь все записи с датой большей чем дата предыдущей выгрузки и меньшей чем текущая..... индекс по дате у тебя есть. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.06.2018, 15:47 |
|
||
|
Загрузка большой таблицы из oracle в mssql
|
|||
|---|---|---|---|
|
#18+
982183с датой большей чем Это не очень хорошо работает с бизнес-датами. И даже с технологическими - только если временной лаг от создания записи до начала выгрузки этого периода (защитный интервал) заведомо больше, чем длительность самой длинной транзакции. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.06.2018, 16:15 |
|
||
|
Загрузка большой таблицы из oracle в mssql
|
|||
|---|---|---|---|
|
#18+
andrey_anonymousчем длительность самой длинной транзакции. А разве мы оперируем понятием "длительность транзакции"? Есть время записи строки или время указанное в строке. Не более того. А "длительность" подразумевает либо вторую дату/время в той же строке, либо вторую строку с тем же идентификатором. В постановке это не упоминается. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.06.2018, 02:26 |
|
||
|
Загрузка большой таблицы из oracle в mssql
|
|||
|---|---|---|---|
|
#18+
982183andrey_anonymousчем длительность самой длинной транзакции. А разве мы оперируем понятием "длительность транзакции"? Есть время записи строки или время указанное в строке. Не более того. В 09:00:00 началась транзакция, вставляющая данные. Напихала строчек: 09:00:01 09:05:32 09:28:22 В 09:20:00 запущен процесс репликации данных, переносящий все записи от прошлого завершения - скажем, от 08:30:00 до 09:10:00 В 09:30:00 транзакция, вставляющая данные, зафиксировалась. Вопрос: как и каким образом будет реплицирована строчка с датой 09:00:00, если применяется алгоритм, построенный на датах? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.06.2018, 04:17 |
|
||
|
Загрузка большой таблицы из oracle в mssql
|
|||
|---|---|---|---|
|
#18+
Понял. Транзакция - процесс загрузки из одной таблицы в другую, а не записи в большой таблице. Идея в том, чтоб не скидывать все свежие данные, а ограничиться данными "по вчера" Именно это я и написал: "Выгружаешь все записи с датой большей чем дата предыдущей выгрузки и меньшей чем текущая....." ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.06.2018, 05:27 |
|
||
|
Загрузка большой таблицы из oracle в mssql
|
|||
|---|---|---|---|
|
#18+
982183"Выгружаешь все записи с датой большей чем дата предыдущей выгрузки и меньшей чем текущая....." Типовой контрпример именно к этой "стратегии" я привел. Как, когда и кем будет выгружена запись от 09:00:00, если выгрузка за период 8:30-09:10 ее физически не видела? Еще раз, медленно: защитный интервал между "меньшей чем текущая"и текущей датой должен превышать длительность самой длинной транзакции, меняющей реплицируемые таблицы. Это при условии, что дата - сугубо техническая и автомагически модифицируется текущей датой при любом DML, что, вообще говоря, неправда. И появление пучка технологий CDC на базе журналов транзакций - прямое следствие этого незамысловатого факта; GG - лишь "придворный" представитель. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.06.2018, 05:50 |
|
||
|
Загрузка большой таблицы из oracle в mssql
|
|||
|---|---|---|---|
|
#18+
ДАТА<>ВРЕМЯ "Выгружаешь все записи с датой большей чем дата предыдущей выгрузки и меньшей чем текущая....." "по вчера" ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.06.2018, 06:22 |
|
||
|
Загрузка большой таблицы из oracle в mssql
|
|||
|---|---|---|---|
|
#18+
ВРУ. "Выгружаешь все записи с датой большей или равной дате предыдущей выгрузки и меньшей чем текущая....." ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.06.2018, 10:00 |
|
||
|
Загрузка большой таблицы из oracle в mssql
|
|||
|---|---|---|---|
|
#18+
... и пропускаем записи, которые вставлены ДО выгрузки, а зафиксированы - ПОСЛЕ. Что вам и пытаются объяснить. Безуспешно. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.06.2018, 12:37 |
|
||
|
Загрузка большой таблицы из oracle в mssql
|
|||
|---|---|---|---|
|
#18+
Basil A. Sidorov... и пропускаем записи, которые вставлены ДО выгрузки, а зафиксированы - ПОСЛЕ. Что вам и пытаются объяснить. Безуспешно. Я исхожу из того, что в 3-5 часов ночи, когда нагрузка поменьше и можно запустить скрипт , все данные за вчерашний день уже "зафиксированы" Это несомненно требует соблюдения ряда условий: Почему и были заданы вопросы: 1. В таблице происходит только добавление записей или еще идут и изменения? 2. Данные вводятся задним числом? (За вчера например) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.06.2018, 12:50 |
|
||
|
Загрузка большой таблицы из oracle в mssql
|
|||
|---|---|---|---|
|
#18+
982183Basil A. Sidorov... и пропускаем записи, которые вставлены ДО выгрузки, а зафиксированы - ПОСЛЕ. Что вам и пытаются объяснить. Безуспешно. Я исхожу из того, что в 3-5 часов ночи, когда нагрузка поменьше и можно запустить скрипт , все данные за вчерашний день уже "зафиксированы" И совершенно напрасно. Вот эта малозначительная строчка assmskВ таблице ~ 2.5 миллиарда записей. предполагает насыщенную и разнообразную жизнь, в т.ч. ночную. Ярды записей не берутся "из воздуха", обычно это результат различных техпроцессов. Но не исключает "ручных" модификаций. И однозначно делает довольно затруднительным поиск и устранение косяков репликации, являющихся следствием оптимистичных предположений, проистекающих из слабой информированности. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.06.2018, 14:35 |
|
||
|
Загрузка большой таблицы из oracle в mssql
|
|||
|---|---|---|---|
|
#18+
Апплодисменты, сэр ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.06.2018, 23:40 |
|
||
|
Загрузка большой таблицы из oracle в mssql
|
|||
|---|---|---|---|
|
#18+
andrey_anonymousИ совершенно напрасно.. Если техпроцесс не остановить, то людей, пользующихся отчетами из этой базы явно в это время меньше. Не знаю как у кого, но и резервное копирование и прочие операции я выполняю ночью. Про ручное исправление данных с датчиков техпроцессов что-то не верю. Оптимизм нужен всегда. И если топикстартер не дал полной информации о своей базе, то наверное не стоит предполагать самый худший вариант. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.06.2018, 03:21 |
|
||
|
Загрузка большой таблицы из oracle в mssql
|
|||
|---|---|---|---|
|
#18+
Тем более если это техпроцесс, то все данные за вчерашний день явно будут зафиксированы спустя несколько часов после полуночи. Теряя эти несколько часов в актуальности загруженных данных, мы можем резко упростить саму процедуру данной ручной репликации. Это только идей, которая не противоречит той информации, которую дал топикстартер. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.06.2018, 03:52 |
|
||
|
Загрузка большой таблицы из oracle в mssql
|
|||
|---|---|---|---|
|
#18+
982183Теряя эти несколько часов в актуальности загруженных данных, мы можем резко упростить саму процедуру данной ручной репликации.Сравнивать дату записи с trunc(sysdate) не сильно проще sysdate - несколько/24 . Только вот при старте все равно потребуется проверять, что sysdate > trunc(sysdate) + несколько/24 . И про актуальность - она составляет интервал_запуска+несколько часов. "ДАТА<>ВРЕМЯ" не позволит использовать интервал менее 24 часов. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.06.2018, 07:07 |
|
||
|
Загрузка большой таблицы из oracle в mssql
|
|||
|---|---|---|---|
|
#18+
Автор говорит: assmsk есть дата обращения на которой есть индекс и выборка по этому полю осуществляется достаточно быстро, -2-Сравнивать дату записи с trunc(sysdate) не сильно проще sysdate - несколько/24. Только вот при старте все равно потребуется проверять, что sysdate > trunc(sysdate) + несколько/24. Задача стоит отделить выгруженные данные от невыгруженных. И при определенных условиях выборка по дате вполне может сработать. В любом случае это будет быстрее чем выборка новых id (которых нет) -2- "ДАТА<>ВРЕМЯ" не позволит использовать интервал менее 24 часов. "ДАТА<>ВРЕМЯ" относилось к диалогу с andrey_anonymous который говорил о времени начала выгрузки а я говорил о ДАТЕ выгрузки. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.06.2018, 07:35 |
|
||
|
Загрузка большой таблицы из oracle в mssql
|
|||
|---|---|---|---|
|
#18+
982183-2- "ДАТА<>ВРЕМЯ" не позволит использовать интервал менее 24 часов. "ДАТА<>ВРЕМЯ" относилось к диалогу с andrey_anonymous который говорил о времени начала выгрузки а я говорил о ДАТЕ выгрузки. ...безнадежен... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.06.2018, 10:48 |
|
||
|
|

start [/forum/topic.php?fid=52&msg=39655521&tid=1883890]: |
0ms |
get settings: |
8ms |
get forum list: |
16ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
193ms |
get topic data: |
9ms |
get forum data: |
2ms |
get page messages: |
52ms |
get tp. blocked users: |
1ms |
| others: | 242ms |
| total: | 529ms |

| 0 / 0 |
