|
падающий dbms_mview.refresh( ..., method => 'F' ) после DDL на базовых таблицах!
|
|||
---|---|---|---|
#18+
есть множество базовых таблиц, на которых висят mv-логи (MLOG$_BaseTbl1, MLOG$_BaseTbl2 ... MLOG$_BaseTblN ) и от которых зависят разные всякие MViews ( с опциями REFRESH FAST ON DEMAND !). И некий джоб, который "рефрешивает" все эти вьюхи каждые 15 минут. Всё отлично и быстро работает. Проблема однако начинается, когда кто-то изменяет (DDL) какую-то из базовых таблиц BaseTbX (ну напр. новая колонка на базовой таблице (которая к MLOG$ и MVs) не имеет отношения. Потом рефреш с опцией Fast ("F" или "?") уже нормально не работает. автор (ORA-12048: error encountered while refreshing materialized view , ORA-00904: "MYSCHEM$"."CHANGEDDATETIME" ORA-06512: in "SYS.DBMS_SNAPSHOT", row 2821) Работает только с "C"(=complete). Если правильный универсальный подход для решения этой проблемы? (а то пока, после каждого DDL на одной из базовых таблиц, о приходится полностью удалять(drop) все MLOG$_ и MViews и пересоздавать их снова) Заранее всем спасибо за конструктивные советы! ____________________________________________________________ сейчас работаю на: Oracle 12.1.0.2.0, 64bit, standard edition, OU-Linux. ... |
|||
:
Нравится:
Не нравится:
|
|||
03.06.2016, 17:59 |
|
падающий dbms_mview.refresh( ..., method => 'F' ) после DDL на базовых таблицах!
|
|||
---|---|---|---|
#18+
и ещё чисто DBA-шный вопрос: как отключить (в Oracle-12c) запись в alert.log и trc-ы сообщений о проблемах с MViews? авторThu Jun 02 18:30:02 2016 Errors in file /azt/opt/oracle/admin/aztpro/diag/rdbms/aztpro/aztpro/trace/aztpro_j003_20407.trc: ORA-00904: invalid identifier: "MAZ$"."KOSTENART": а то для нас это некоторый overkill! Ошибки мы ловим в свой лог! (которые пишется из нашего JOB-a) ... |
|||
:
Нравится:
Не нравится:
|
|||
03.06.2016, 18:13 |
|
падающий dbms_mview.refresh( ..., method => 'F' ) после DDL на базовых таблицах!
|
|||
---|---|---|---|
#18+
ORAngutang, Если вставляемые столбцы не отражены в матвьюхе, то после операции DDL надо выполнить dbms_repcat.generate_replication_support, чтобы обновить триггеры для имененной родительской таблицы. Все должно работать. ... |
|||
:
Нравится:
Не нравится:
|
|||
03.06.2016, 19:11 |
|
падающий dbms_mview.refresh( ..., method => 'F' ) после DDL на базовых таблицах!
|
|||
---|---|---|---|
#18+
UDW, Cпасибо, но пока не идёт! Пробую: авторbegin dbms_repcat.generate_replication_support( sname => 'MYSCHEMA', oname => 'MLOG$_BaseTblX', type => 'table' ); end; получаю: Код: plaintext
а что в "oname =>" подставлять то? Базовую таблицу? Её MLOG$?(cм выше)? Таблицу самой MV? Пробывал и то и другое и третее! Во всех 3х случаях огребаю ORA-23308 ! P.S. это случайно не EE-фича? А то у нас Standard Edition! ;-) ... |
|||
:
Нравится:
Не нравится:
|
|||
03.06.2016, 20:26 |
|
падающий dbms_mview.refresh( ..., method => 'F' ) после DDL на базовых таблицах!
|
|||
---|---|---|---|
#18+
ORAngutang, Имя объекта надо указывать, а не имя журнала. Кстати, журнал строится по первичному ключу. Все записи в журнале делаются триггерами реп.поддержки. ... |
|||
:
Нравится:
Не нравится:
|
|||
03.06.2016, 21:53 |
|
падающий dbms_mview.refresh( ..., method => 'F' ) после DDL на базовых таблицах!
|
|||
---|---|---|---|
#18+
ORAngutang, А что если прикрутить: Код: plsql 1.
... |
|||
:
Нравится:
Не нравится:
|
|||
03.06.2016, 22:04 |
|
падающий dbms_mview.refresh( ..., method => 'F' ) после DDL на базовых таблицах!
|
|||
---|---|---|---|
#18+
ORAngutangи ещё чисто DBA-шный вопрос: как отключить (в Oracle-12c) запись в alert.log и trc-ы сообщений о проблемах с MViews? авторThu Jun 02 18:30:02 2016 Errors in file /azt/opt/oracle/admin/aztpro/diag/rdbms/aztpro/aztpro/trace/aztpro_j003_20407.trc: ORA-00904: invalid identifier: "MAZ$"."KOSTENART": а то для нас это некоторый overkill! Ошибки мы ловим в свой лог! (которые пишется из нашего JOB-a) интересно, а откуда ваш job берет информацию о таких ошибках? ... |
|||
:
Нравится:
Не нравится:
|
|||
04.06.2016, 06:50 |
|
падающий dbms_mview.refresh( ..., method => 'F' ) после DDL на базовых таблицах!
|
|||
---|---|---|---|
#18+
UDWORAngutang, Все записи в журнале делаются триггерами реп.поддержки. А с какого перепугу ты решил у ORAngutang'а advanced replication с мастерами, триггeрами и прочее? Скорее всего у него банально basic replication: таблица + журнал + матпредставление с fast refresh. И он должен работать: Код: 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. 79. 80. 81. 82. 83. 84. 85. 86. 87. 88. 89. 90. 91. 92. 93. 94. 95. 96. 97. 98. 99. 100. 101. 102. 103. 104. 105. 106. 107. 108.
Т.e. добавление полей в базовую таблицу на MV не влияет - матпредставление просто их не видит ведь контейнер матпредставления создается на базе select'a уазанного в матпредставлении. SY. ... |
|||
:
Нравится:
Не нравится:
|
|||
04.06.2016, 16:02 |
|
падающий dbms_mview.refresh( ..., method => 'F' ) после DDL на базовых таблицах!
|
|||
---|---|---|---|
#18+
SY, Перепугу нет, но AR основана на механизме MV. ... |
|||
:
Нравится:
Не нравится:
|
|||
04.06.2016, 18:31 |
|
падающий dbms_mview.refresh( ..., method => 'F' ) после DDL на базовых таблицах!
|
|||
---|---|---|---|
#18+
UDWAR основана на механизме MV. И? Что теперь все должны использовать AR для простого MV? SY. ... |
|||
:
Нравится:
Не нравится:
|
|||
04.06.2016, 18:49 |
|
падающий dbms_mview.refresh( ..., method => 'F' ) после DDL на базовых таблицах!
|
|||
---|---|---|---|
#18+
SY, Ok. Ваше предложение? ... |
|||
:
Нравится:
Не нравится:
|
|||
04.06.2016, 21:20 |
|
падающий dbms_mview.refresh( ..., method => 'F' ) после DDL на базовых таблицах!
|
|||
---|---|---|---|
#18+
UDWOk. Ваше предложение? Так я вроде показал что все работает. Пока ORAngutang не приведет тест кейс предложений не будет. SY. ... |
|||
:
Нравится:
Не нравится:
|
|||
04.06.2016, 21:44 |
|
падающий dbms_mview.refresh( ..., method => 'F' ) после DDL на базовых таблицах!
|
|||
---|---|---|---|
#18+
SYUDWOk. Ваше предложение? Так я вроде показал что все работает. Пока ORAngutang не приведет тест кейс предложений не будет. SY. Вообще-то cитуация очень похожа на "кашу маслoм можно и испортить". Тот кто модифицирует таблицу "заодно" переcоздает и журнал при этом теряя все изменения с момента последнего обновления (даже если их и не было - Oracle этого ведь не знает и руководствуется только сравнением дат создaния журнала и последнего обновления матпредставления): Код: 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.
SY. ... |
|||
:
Нравится:
Не нравится:
|
|||
04.06.2016, 21:57 |
|
падающий dbms_mview.refresh( ..., method => 'F' ) после DDL на базовых таблицах!
|
|||
---|---|---|---|
#18+
SY, Вобще есть компромисс - force refresh. ... |
|||
:
Нравится:
Не нравится:
|
|||
04.06.2016, 22:51 |
|
падающий dbms_mview.refresh( ..., method => 'F' ) после DDL на базовых таблицах!
|
|||
---|---|---|---|
#18+
UDWВобще есть компромисс - force refresh. Вообще проще не удалять/переcоздавать журнал. Конечно force refresh в таком случае ошибки не выдаст но выполнит complete refresh который может длится дoлго, потребует кучу UNDO (взaвисимости от ATOMIC_REFRESH) и нагенерирует кучу redo. SY. ... |
|||
:
Нравится:
Не нравится:
|
|||
05.06.2016, 00:44 |
|
падающий dbms_mview.refresh( ..., method => 'F' ) после DDL на базовых таблицах!
|
|||
---|---|---|---|
#18+
чё-то реально непонятное происходит: cоздаю м-лог на одной из старых наших базовых таблиц: Код: sql 1.
потом пытаюсь создать м-вью: Код: sql 1. 2.
... огребаю: ORA-12033: cannot use filter columns from materialized view log on "MYSCH"."MYTBLX" потом создаю клон базовой таблицы: Код: sql 1. 2.
делаю всё тоже самое на клоне MYTBLX2 (mlog + mv). Всё получается!!! Может это что-то системное? Как это проверить? Куда копать??? ... |
|||
:
Нравится:
Не нравится:
|
|||
06.06.2016, 20:26 |
|
падающий dbms_mview.refresh( ..., method => 'F' ) после DDL на базовых таблицах!
|
|||
---|---|---|---|
#18+
ORAngutang, Возможно 11g Virtual Columns and Fast Refreshable Materialized Views (What In The World) SY. ... |
|||
:
Нравится:
Не нравится:
|
|||
06.06.2016, 21:40 |
|
падающий dbms_mview.refresh( ..., method => 'F' ) после DDL на базовых таблицах!
|
|||
---|---|---|---|
#18+
SYORAngutang, Возможно 11g Virtual Columns and Fast Refreshable Materialized Views (What In The World) SY. Cпасибо огромнейшее за наводку! Благодаря ней мы нашли workaround. Вообщем-то что Оракл там за кулисами делает, это просто праздник какой-то: select * --table_name, column_name, data_default, virtual_column, hidden_column from dba_tab_cols where owner = 'MYSCH' and virtual_column = 'YES' and Table_Name = 'MYTBLX' and Column_Name like 'SYS_ST%' SYS_STSR9JGQU6238JVT6LX3ZIY9MA SYS_OP_COMBINED_HASH("ID","PARENTFIRMAID") оказывается, он лепит похоже некую extended statistics в некие созданые за кулисами hidden-сolumns, и вот они то с fast-refreshable MVs как раз таки и не дружат! Баг старый (MOS.10281402) с 11g-времён (c 2010) протянутый аж до 12с: :-( https://blogs.oracle.com/sql/entry/ora_54033_and_the_hidden если на базовых таблицах эту хрень (extended statistics) удалить: begin dbms_stats.drop_extended_stats( ''MYSCH', ''MYTAB', '(ID,PARENTFIRMAID)'); end; то проблема решается! Т.е. после этого создаются без ошибок (ORA-12033) все MV и их можно без проблем (fast-)рефрешевать: begin dbms_mview.refresh( list => 'mysch.kportail_myviewsoandso22', method => 'F' ); end; P.S. остаётся надеяться, что удаление extended statistics-и не подпортит нам performance в других местах! ;-) P.P.S. а SYS_OP_COMBINED_HASH вообще "is an undocumented feature"! Во как! :-)))) ... |
|||
:
Нравится:
Не нравится:
|
|||
07.06.2016, 17:16 |
|
падающий dbms_mview.refresh( ..., method => 'F' ) после DDL на базовых таблицах!
|
|||
---|---|---|---|
#18+
ORAngutang, Добрый вечер. Хочу уточнить - вы не разобрались с проблемой записи в алект лог? автори ещё чисто DBA-шный вопрос: как отключить (в Oracle-12c) запись в alert.log и trc-ы сообщений о проблемах с MViews? ... |
|||
:
Нравится:
Не нравится:
|
|||
07.10.2019, 17:26 |
|
падающий dbms_mview.refresh( ..., method => 'F' ) после DDL на базовых таблицах!
|
|||
---|---|---|---|
#18+
part351с проблемой записи в алект логwhen others then null ... |
|||
:
Нравится:
Не нравится:
|
|||
08.10.2019, 07:19 |
|
падающий dbms_mview.refresh( ..., method => 'F' ) после DDL на базовых таблицах!
|
|||
---|---|---|---|
#18+
-2-, Боюсь это не то... В 12 версии оракл пишет не только ошибку в алерт лог, но и здоровенную портянку снимков, которые он не смог обновить. И это жутко засоряет лог. Пытаюсь найти как это отключить. ... |
|||
:
Нравится:
Не нравится:
|
|||
08.10.2019, 13:05 |
|
|
start [/forum/topic.php?fid=52&msg=39873317&tid=1882007]: |
0ms |
get settings: |
7ms |
get forum list: |
13ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
47ms |
get topic data: |
10ms |
get forum data: |
2ms |
get page messages: |
50ms |
get tp. blocked users: |
1ms |
others: | 252ms |
total: | 390ms |
0 / 0 |