|
как узнать timestamp бэкапа
|
|||
---|---|---|---|
#18+
Кстати, а что, я настолько часто нажираюсь, что несу чушь? Ты только моему работодателю об этом не говори... ... |
|||
:
Нравится:
Не нравится:
|
|||
28.08.2020, 14:17 |
|
как узнать timestamp бэкапа
|
|||
---|---|---|---|
#18+
сорян, дошли руки глянуть внимательнее Код: plsql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15.
21589873590 - ожидаемо) с него - SCN_TO_TIMESTAMP - это почти дата опена в ридонли того, что восстановлено из бэкапа) Код: plsql 1. 2.
а вот это ещё один вариант оно) Код: plsql 1. 2. 3. 4. 5. 6. 7. 8.
... |
|||
:
Нравится:
Не нравится:
|
|||
31.08.2020, 12:06 |
|
как узнать timestamp бэкапа
|
|||
---|---|---|---|
#18+
итог-то какой? где достоверно смотреть достоверное время до секунд? пробовать методом тыка?) ... |
|||
:
Нравится:
Не нравится:
|
|||
01.09.2020, 08:12 |
|
как узнать timestamp бэкапа
|
|||
---|---|---|---|
#18+
Тебе нужно посмотреть, до какого SCN можно восстановить, чтоб открыть без проблем? Или тебе просто нужно узнать время, к которому будет относиться RESETLOGS ? На момент восстановления у тебя архивлоги закаталогизированы (или информация о них изначально находится в восстановленном контролфайле) А тут к тебя и V$ARCHIVED_LOG и V$BACKUP_ARCHIVELOG_DETAILS -- если ты целиком катил этот лог, то NEXT_TIME скорее всего то, что тебе нужно А SCN_TO_TIMESTAMP, как я уже говорил, работает на основании обычной таблицы SYS.SMON_SCN_TIME, которая доступна только при открытой (в том числе в READ ONLY) БД. Ну и дальше банальная интерполяция (хотя возможно, последние 1-5-10-60 минут могут храниться и в какой-нибудь динамической вьюхе) Да, она часто (как правило, каждую минуту, но зависит от нагрузки) обновляется, поддерживая небольшое кол-во записей (до 11g там вообще фиксированное количество строк было), где-то 5-7 дней, но при открытии в RO ты точно не перезапишешь старые (восстановленные с бэкапа) записи, поэтому время будет правильное PS. Ну и очень похоже, что TIME_DP таки хранится в UTC ... |
|||
:
Нравится:
Не нравится:
|
|||
01.09.2020, 09:43 |
|
как узнать timestamp бэкапа
|
|||
---|---|---|---|
#18+
Вячеслав Любомудров Или тебе просто просто нужно узнать точное время) целиком катил лог 1145 (ресторе и рековер until sequence 1146) тогда глупый вопрос: (в архивлоге 1145 Next SCN) 21589873591 останется накачен или нет? AlexVin (он же в 1146 Low SCN) current_scn = 21589873590 в развернутой из бэкапа и открытой на чтение базе на 1 меньше почему-то в заголовках файлов 21589873591 12-AUG-2020 01:45:51 в SMON_SCN_TIME максимальный 12-AUG-20 01.39.42.000000000 AM 21589852576 TIME_DP таки хранится в UTC - похоже) Код: plsql 1. 2. 3. 4. 5.
так на 01.39.42 или на 01:45:51 будет база после RESETLOGS? ... |
|||
:
Нравится:
Не нравится:
|
|||
01.09.2020, 12:23 |
|
как узнать timestamp бэкапа
|
|||
---|---|---|---|
#18+
Вроде как не включается +- 1 к SCN это там вообще какая-то чехарда (насколько помню, это обсуждалось в топике что-то типа "прыжок через resetlogs") Кстати, в контролфайле текущий SCN увеличивается при каждой попытке открытия (есть и более радикальные способы) В твоем случае получается что таки ближе к "01:45:51", из NEXT_TIME Но ты мог попробовать и проинтерполировать значения из SYS.SMON_SCN_TIME на значение RESETLOGS_CHANGE# (после открытия), да или просто запросить scn_to_timestamp(resetlogs_change#) from v$database, но тут проблема, как быстро оно перезапишет содержимое таблички под актуальные данные. Ну и на какой SCN (точно) у тебя произошел RESETLOGS ты можешь посмотреть в V$DATABASE или alert.log Что-то я вообще перестал понимать, что именно тебе непонятно ... |
|||
:
Нравится:
Не нравится:
|
|||
01.09.2020, 12:58 |
|
как узнать timestamp бэкапа
|
|||
---|---|---|---|
#18+
Хотя там тоже иногда погоду показывают Код: plsql 1. 2. 3. 4. 5.
Лог RMAN DUPLICATE Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13.
alert.log Код: plaintext 1. 2.
Но все-таки DUPLICATE это там, где не очень-то повлияешь на такие мелочи ... |
|||
:
Нравится:
Не нравится:
|
|||
01.09.2020, 13:15 |
|
как узнать timestamp бэкапа
|
|||
---|---|---|---|
#18+
Вячеслав Любомудров В твоем случае получается что таки ближе к "01:45:51", из NEXT_TIME мне не надо ближе) в итоге мне надо поднять базу на максимально возможное время и сказать его с точностью до секунды) на какое время в ней данные казалось бы просто всё until да, не включает указанное значение как between. вроде бы) а что в SCN_TO_TIMESTAMP чехарда, это я уже в курсе) ... |
|||
:
Нравится:
Не нравится:
|
|||
01.09.2020, 14:24 |
|
как узнать timestamp бэкапа
|
|||
---|---|---|---|
#18+
AlexVin не включает указанное значение как between between включает (>= and <=) .... stax ... |
|||
:
Нравится:
Не нравится:
|
|||
01.09.2020, 14:45 |
|
как узнать timestamp бэкапа
|
|||
---|---|---|---|
#18+
Не, не чехарда Я подзабыл это за давностью и ненужностью Но именно с 10g SMON_SCN_TIME хранит базовое время/scn (time_dp/scn) для совместимости, обеспечивая точность как минимум в 5 мин +- интерполяция, дополнительно к этому хранится еще и более мелкая карта (TIM_SCN_TIME) которая позволяет хранить до 300 "уточнений" повышая точность до 1 сек. А scn_to_timestamp(resetlogs_change#) from v$database вполне себе точное время RESETLOGS-а ... |
|||
:
Нравится:
Не нравится:
|
|||
01.09.2020, 14:49 |
|
как узнать timestamp бэкапа
|
|||
---|---|---|---|
#18+
Stax AlexVin until да, не включает указанное значение как between between включает (>= and <=) .... stax -- Чем, чем лучше? -- Чем армяне ... |
|||
:
Нравится:
Не нравится:
|
|||
01.09.2020, 14:51 |
|
как узнать timestamp бэкапа
|
|||
---|---|---|---|
#18+
Вячеслав Любомудров Stax пропущено... between включает (>= and <=) .... stax -- Чем, чем лучше? -- Чем армяне until да, не включает указанное значение как включает between )) ... |
|||
:
Нравится:
Не нравится:
|
|||
01.09.2020, 15:36 |
|
как узнать timestamp бэкапа
|
|||
---|---|---|---|
#18+
Вячеслав Любомудров дополнительно к этому хранится еще и более мелкая карта (TIM_SCN_TIME) которая позволяет хранить до 300 "уточнений" повышая точность до 1 сек. TIM_SCN_TIME = TIM_SCN_MAP ? ... |
|||
:
Нравится:
Не нравится:
|
|||
01.09.2020, 21:58 |
|
как узнать timestamp бэкапа
|
|||
---|---|---|---|
#18+
Кстати, я тут немного поковырял новое содержимое SMON_SCN_TIME Получилось примерно следущее Код: plsql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42. 43. 44. 45. 46. 47. 48. 49. 50. 51. 52. 53. 54. 55. 56. 57. 58. 59. 60. 61. 62. 63. 64. 65. 66. 67. 68. 69. 70. 71. 72. 73. 74. 75. 76. 77. 78.
Все эти приседания с Big/Little Endian связаны с тем, что utl_raw.cast_to_binary_integer работает со знаковым INTEGER, а нужен беззнаковый -- тут либо превращать в HEX используя соответствующий порядок байт (закоментировано), либо тупо таки добавить недостающее -- кто работал с машинным представлением, тот не увидит ничего необычного По-хорошему это надо делать со всеми значениями, но смещение от UNIX_DATE пока положительно и SCN_WRAP (у меня по крайней мере, но подозреваю, что у всех) тоже положительно, поэтому не парился :-( Последние 2 байта названы как opts_or_thread ибо мне не понятно, что там -- после 12.2 там всегда 0 (но у меня single instance), а до этого там попадались и более другие значения, возможно просто мусор Ну и дырки от клонирования тоже вполне присутствуют -- БД после DUPLICATE из предыдущих постов Код: plsql 1. 2. 3. 4. 5. 6. 7. 8. 9.
На нормально работающих БД это значение лежит в районе 5 мин. старые версииЧто еще смешнее, в 10g смещение для TIME_MP было вообще каким-то странным Код: plsql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27.
Это все на Solaris SPARC (Big endian) 9-ку развернуть уже сложно, не поддерживается новой соляркой :-( ... |
|||
:
Нравится:
Не нравится:
|
|||
02.09.2020, 15:45 |
|
как узнать timestamp бэкапа
|
|||
---|---|---|---|
#18+
AlexVin current_scn = 21589873590 в развернутой из бэкапа и открытой на чтение базе на 1 меньше почему-то в заголовках файлов 21589873591 12-AUG-2020 01:45:51 в SMON_SCN_TIME максимальный 12-AUG-20 01.39.42.000000000 AM 21589852576 Код: plsql 1. 2. 3. 4. 5.
так на 01.39.42 или на 01:45:51 будет база после RESETLOGS? после alter database open resetlogs: Код: plsql 1. 2. 3. 4. 5. 6. 7. 8.
а next_time действительно не включен. пока не резетлогнешь, не узнаешь до скольки накатили?)) ... |
|||
:
Нравится:
Не нравится:
|
|||
04.09.2020, 14:22 |
|
как узнать timestamp бэкапа
|
|||
---|---|---|---|
#18+
чем checkpoint_time не подходит... ... |
|||
:
Нравится:
Не нравится:
|
|||
06.09.2020, 12:00 |
|
|
start [/forum/topic.php?fid=52&msg=39994492&tid=1880924]: |
0ms |
get settings: |
8ms |
get forum list: |
14ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
48ms |
get topic data: |
10ms |
get forum data: |
3ms |
get page messages: |
49ms |
get tp. blocked users: |
1ms |
others: | 310ms |
total: | 451ms |
0 / 0 |