|
|
|
как ускорить MERGE
|
|||
|---|---|---|---|
|
#18+
Сергей АрсеньевSYМожет я еще не проснулся, но вышесказанное есть нe что иное как: К этому обсуждение и пришло. (Хотя в общем случае нет ибо truncate внетранзакционен, а значит будет момент времени, когда старое порушили, а нового так и не завезли. :)) возможно уменьшение времени между уничтожением (truncate) и завершением insert с использованием промежуточной таблицы - и swap partition между ней и целевой. наши замеры говорят, что случаи: а) расчет во временной табл - 30 мин, затем truncate и insert (append) в постоянную - еще 30 мин б) расчет во временной (определенной как постоянная с секционированием как у целевой) - около 60 мин, затем truncate и swap partition (0 мин) - почти равны по времени работы (оба около часа, разницы на уровне погрешности замера) есть ли еще способы ускорения? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.09.2016, 16:45 |
|
||
|
как ускорить MERGE
|
|||
|---|---|---|---|
|
#18+
Alexus12, У Вас inser во временную идет тоже чехом? И при этом insert туда, а потом в постоянную быстрее? Или просто insert во временную быстрее? Если второе, то понятное дело - все ж таки журналирование операций оно не бесплатное. И ест ввод-вывод. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.09.2016, 16:46 |
|
||
|
как ускорить MERGE
|
|||
|---|---|---|---|
|
#18+
Alexus12есть ли еще способы ускорения? В зависимости от способа заполнения на стадии предварительных расчетов, Может заработать nologging, а потом включить logging и swap partition. Для примера. Если же обновления идут одинарными операциями, то возможно под миллионы добавляемых строк можно будет сменить tablespace на MSSM. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.09.2016, 17:07 |
|
||
|
как ускорить MERGE
|
|||
|---|---|---|---|
|
#18+
Сергей АрсеньевК этому обсуждение и пришло. (Хотя в общем случае нет ибо truncate внетранзакционен, а значит будет момент времени, когда старое порушили, а нового так и не завезли. :)) Ну это-то как раз просто. Партицированная тaблица (например по дням если процесс раз в дeнь). Каждая транзакция ссылающаяся на таблицу сохраняет дату начала транзакции - TRUNC(SYSDATE) и при обращeнии к таблице использует партиционный_ключ = датa_начала_транзакции. Ну и создаем drop old partition по расписанию. SY. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.09.2016, 17:11 |
|
||
|
как ускорить MERGE
|
|||
|---|---|---|---|
|
#18+
SY, swap не проще drop? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.09.2016, 17:17 |
|
||
|
как ускорить MERGE
|
|||
|---|---|---|---|
|
#18+
SYНу это-то как раз просто. Упс, забыл упомянуть - у меня данные на завтра грузятся сегодня, посeму TRUNC(SYSDATE). Если по-принципу смотреть данные последней загрузки, то нужно хранить дату загрузки в базе и при обращeнии к таблице использoвaть партиционный_ключ = (SELECT MAX(дата_загрузки) FROM таблица_загрузки). SY. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.09.2016, 17:22 |
|
||
|
как ускорить MERGE
|
|||
|---|---|---|---|
|
#18+
Сергей АрсеньевSY, swap не проще drop? В общем случае swap не катит - транзакция начавшаяся до последней загрузки должна продолжать их использовать. SY. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.09.2016, 17:25 |
|
||
|
как ускорить MERGE
|
|||
|---|---|---|---|
|
#18+
SYВ общем слуае swap не катит - транзакция начавшаяся до последней загрузки должна продолжать их использовать. Согласен. Но тогда, по хорошему, еще нужно следить за самой долгой транзакцией, а до техз пор ничего не дропать. :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.09.2016, 17:55 |
|
||
|
как ускорить MERGE
|
|||
|---|---|---|---|
|
#18+
Сергей АрсеньевНо тогда, по хорошему, еще нужно следить за самой долгой транзакцией, а до техз пор ничего не дропать. :) Ну если транзакции долгоиграют сутками то проблема скорее всего куда глубже . SY. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.09.2016, 13:03 |
|
||
|
как ускорить MERGE
|
|||
|---|---|---|---|
|
#18+
Подниму старую тему, нежели создавать новую. Delete из партиции, insert 500 тыс. строк В во время данной операции log file switch начинает пожирать CPU, и иногда это приводит к тормозам в работе пользователей. Если я правильно гуглю, это запись в архивлоги. В поисках решения, подумал о nologging на таблицу и insert append. Но волнует вопрос: влияет ли nologging и insert append на восстановление данных из бэкапа. Если вдруг понадобится восстановить базу из бжкапа, кроме потери данных в таблице, есть еще какие-то нюансы о которых следуте знать? Бэкап полный раз в неделю, а подобную операцию приходится раз в сутки делать. Сокращу: Хочу перейти на truncate, insert append, rebuid index и не логгировать, так как при потере данных можно будет их заново рассчитать за разумное время. Есть ли угроза другим данным при восстановлении ( у Бурлесона прочел что-то страшное и подозрение закралось)? Лучше ли будет перенести в отдельный tablespace такие таблицы? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.01.2017, 10:12 |
|
||
|
как ускорить MERGE
|
|||
|---|---|---|---|
|
#18+
nata44845, А зафиксировать статистику для этих темп таблиц не пробовали? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.01.2017, 10:30 |
|
||
|
как ускорить MERGE
|
|||
|---|---|---|---|
|
#18+
ссу, 1. Делайте бэкап после ваших манипуляций, например. Возможно, ваш ДБА подозревает, что вы хотите сделать и предусмотрительно включил режим FORCE LOGGING; ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.01.2017, 10:37 |
|
||
|
как ускорить MERGE
|
|||
|---|---|---|---|
|
#18+
ссуDelete из партиции, insert 500 тыс. строк В во время данной операции log file switch начинает пожирать CPU, и иногда это приводит к тормозам в работе пользователей. Если я правильно гуглю, это запись в архивлоги. Если Вы правильно гуглите и у Вас долго ждут при переключении активного журнала из-за того, что цепочка замкнулась, а перелететь в архив не успевает. То в ервую очередь стоит подумать над увеличением скорости или удлинением цепочки, чтоб ее хватало на пиковую нагрузку с запасом, а потом она медленно рассасывалась. И IMHO только после того, как это не поможет, над вариантом который увеличит время и трудоемкость восстановления после сбоя. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.01.2017, 11:15 |
|
||
|
|
start [/forum/topic.php?fid=52&msg=39393648&tid=1886555]: |
0ms |
get settings: |
5ms |
get forum list: |
9ms |
check forum access: |
2ms |
check topic access: |
2ms |
track hit: |
150ms |
get topic data: |
7ms |
get forum data: |
2ms |
get page messages: |
32ms |
get tp. blocked users: |
1ms |
| others: | 197ms |
| total: | 407ms |
| 0 / 0 |
