YS
Не пинайте за глупый вопрос.
Есть ли возможность пересоздать файл страницы _fsm в каталоге базы?
Есть ли возможность пересоздать файл страницы _fsm в каталоге базы?
"VACUUM таблица;", кажется. А Вам зачем? ;)
Size: a a a
2021 February 25
AL
только встал чтоб пойти спать... но передумал )))
AL
таки да, зачем?
АШ
В попытках восстановить базу 1С после краха фс
AL
а бэкапы?
АШ
По глупости на разных дисках, но на одном сервере.
После аппаратного сбоя диск с архивами восстановлен, но срок давности того что смог восстановить слишком большой
После аппаратного сбоя диск с архивами восстановлен, но срок давности того что смог восстановить слишком большой
D
а бэкапы?
Для слабаков
AL
если смогли запустить постгрес, перед тем как продолжать попытки recovery, попытайетсь вытащить максимум данных из БД (pg_dump)
AL
Для слабаков
наличие бэкапов БД это как базовый уровень в пирамиде маслоу
DO
Виктор Ткаченко
Это боль...
В одной из систем не могли сделать вакуум тк система постоянно находилась под нагрузкой и с долгими транзакционными перерасчетами.
По итогу несколько месяцев наблюдали как стремительно деградирует производительность. Не знаю правда, чем дело закончилось и смогли ли "выбить" время на тех обслуживание.
В одной из систем не могли сделать вакуум тк система постоянно находилась под нагрузкой и с долгими транзакционными перерасчетами.
По итогу несколько месяцев наблюдали как стремительно деградирует производительность. Не знаю правда, чем дело закончилось и смогли ли "выбить" время на тех обслуживание.
Выставлется таймаут на транзакцию и постепенно уменьшается, заставляю разработчиков писать ноомальный код
2021 February 26
ФГ
Выставлется таймаут на транзакцию и постепенно уменьшается, заставляю разработчиков писать ноомальный код
А что произойдет ну скажем с тяжёлым апдейтом в такой ситуации в постгрес ?
Пойдет роллбак и не будет ли это ещё более тяжёлым испытанием для системы ?
Ясно что транзакции д.б короткие но вот если вдруг на это время попадет процесс масс.апдейта что произойдет тогда ?
Пойдет роллбак и не будет ли это ещё более тяжёлым испытанием для системы ?
Ясно что транзакции д.б короткие но вот если вдруг на это время попадет процесс масс.апдейта что произойдет тогда ?
VY
Федор Гулин
А что произойдет ну скажем с тяжёлым апдейтом в такой ситуации в постгрес ?
Пойдет роллбак и не будет ли это ещё более тяжёлым испытанием для системы ?
Ясно что транзакции д.б короткие но вот если вдруг на это время попадет процесс масс.апдейта что произойдет тогда ?
Пойдет роллбак и не будет ли это ещё более тяжёлым испытанием для системы ?
Ясно что транзакции д.б короткие но вот если вдруг на это время попадет процесс масс.апдейта что произойдет тогда ?
в Postrges отмена транзакций очень быстрая. транзакция просто помечается как “rolled back”. когда запросы (любые другие) обращаются к данным которые такая транзакция успела записать, они:
- проверят статус транзакции
- увидят, что она откатилась, т.е. данные надо игнорить
- т.к. всё равно уже влезли, проставим хинты в заголовках записей, что они удалённые
именно из-за этого в Postgres-е возникает эффект, когда чистый SELECT может что-то записать
- проверят статус транзакции
- увидят, что она откатилась, т.е. данные надо игнорить
- т.к. всё равно уже влезли, проставим хинты в заголовках записей, что они удалённые
именно из-за этого в Postgres-е возникает эффект, когда чистый SELECT может что-то записать
VY
Федор Гулин
А что произойдет ну скажем с тяжёлым апдейтом в такой ситуации в постгрес ?
Пойдет роллбак и не будет ли это ещё более тяжёлым испытанием для системы ?
Ясно что транзакции д.б короткие но вот если вдруг на это время попадет процесс масс.апдейта что произойдет тогда ?
Пойдет роллбак и не будет ли это ещё более тяжёлым испытанием для системы ?
Ясно что транзакции д.б короткие но вот если вдруг на это время попадет процесс масс.апдейта что произойдет тогда ?
ну и никто не запрещает перед важными долгими операциями переопределить лимит
ФГ
в Postrges отмена транзакций очень быстрая. транзакция просто помечается как “rolled back”. когда запросы (любые другие) обращаются к данным которые такая транзакция успела записать, они:
- проверят статус транзакции
- увидят, что она откатилась, т.е. данные надо игнорить
- т.к. всё равно уже влезли, проставим хинты в заголовках записей, что они удалённые
именно из-за этого в Postgres-е возникает эффект, когда чистый SELECT может что-то записать
- проверят статус транзакции
- увидят, что она откатилась, т.е. данные надо игнорить
- т.к. всё равно уже влезли, проставим хинты в заголовках записей, что они удалённые
именно из-за этого в Postgres-е возникает эффект, когда чистый SELECT может что-то записать
Поясните последнюю.фразу
Это грязное чтение ??
Это грязное чтение ??
VY
в Postgres-е не бывает грязного чтения.
если после отмены транзакции первым к данным обратиться SELECT и окажется, что нужно обновить хинт биты для записей, то получиться, что читающий SELECT вызвал запись данных.
если после отмены транзакции первым к данным обратиться SELECT и окажется, что нужно обновить хинт биты для записей, то получиться, что читающий SELECT вызвал запись данных.
D
в Postgres-е не бывает грязного чтения.
если после отмены транзакции первым к данным обратиться SELECT и окажется, что нужно обновить хинт биты для записей, то получиться, что читающий SELECT вызвал запись данных.
если после отмены транзакции первым к данным обратиться SELECT и окажется, что нужно обновить хинт биты для записей, то получиться, что читающий SELECT вызвал запись данных.
А где про это можно почитать подробнее?
ФГ
А где про это можно почитать подробнее?
+1 надо б почитать. Обдумать явно не похоже на скл или оракл.
D
Я просто вообще ничего не понял) Либо отупел, либо устал. Если читающий SELECT вызвал запись, то это значит, что транзакция, которая как бы отменилась, по факту не отменилась? Или о какой именно записи идёт речь?
W
в Postrges отмена транзакций очень быстрая. транзакция просто помечается как “rolled back”. когда запросы (любые другие) обращаются к данным которые такая транзакция успела записать, они:
- проверят статус транзакции
- увидят, что она откатилась, т.е. данные надо игнорить
- т.к. всё равно уже влезли, проставим хинты в заголовках записей, что они удалённые
именно из-за этого в Postgres-е возникает эффект, когда чистый SELECT может что-то записать
- проверят статус транзакции
- увидят, что она откатилась, т.е. данные надо игнорить
- т.к. всё равно уже влезли, проставим хинты в заголовках записей, что они удалённые
именно из-за этого в Postgres-е возникает эффект, когда чистый SELECT может что-то записать
Казалось-бы причем тут xmin xmax
AN
А где про это можно почитать подробнее?
2ая лекция DBA-2