|
|
|
IMPDP: Перенос секционированной на основе виртуальной колонки таблицы
|
|||
|---|---|---|---|
|
#18+
Всем привет! Есть задача - перенести схему на новый сервер. Сформировал дамп через expdp. Делаю импорт. Метаданные импортируются норм. Проблема с импортом данных. Некоторые таблицы имеют виртуальные колонки и на их основе выполнено секционирование. Такое ощущение, что при импорте данных производится попытка физической вставки данных в виртуальную колонку т.к. получаю ошибку: ORA-31693: Сбой при загрузке/выгрузке объекта данных "схема"."имя_таблицы":"секция", этот объект данных пропускается из-за ошибки: ORA-54013: Операция INSERT для виртуальных столбцов запрещена Кто-нибудь сталкивался с подобным? Есть варианты решения? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.08.2018, 10:44 |
|
||
|
IMPDP: Перенос секционированной на основе виртуальной колонки таблицы
|
|||
|---|---|---|---|
|
#18+
Andrew999Есть варианты решения? Версию огласи. SY. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.08.2018, 14:12 |
|
||
|
IMPDP: Перенос секционированной на основе виртуальной колонки таблицы
|
|||
|---|---|---|---|
|
#18+
SY, Release 12.1.0.2.0 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.08.2018, 17:00 |
|
||
|
IMPDP: Перенос секционированной на основе виртуальной колонки таблицы
|
|||
|---|---|---|---|
|
#18+
Сам нашел решение: 1. Переименовываем виртуальную колонку, например, part в part2. При этом правило секционирования автоматом подхватывает это изменение и смотрит на part2. 2. Добавляем колонку с исходным именем и типом - part number 3. Делаем импорт. При этом данные из таблицы-источника заливаются в новое физическое поле, а виртуальная колонка вычисляется. 4. Удаляем физическую колонку part 5. Переименовываем обратно виртуальную колонку part2 в part. Готово. Можно автоматизировать процесс для всех подобных таблиц. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.08.2018, 17:07 |
|
||
|
IMPDP: Перенос секционированной на основе виртуальной колонки таблицы
|
|||
|---|---|---|---|
|
#18+
Andrew999Release 12.1.0.2.0 Не воспроизводится: Код: 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. 109. 110. 111. 112. 113. 114. 115. 116. 117. 118. 119. SY. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.08.2018, 18:22 |
|
||
|
IMPDP: Перенос секционированной на основе виртуальной колонки таблицы
|
|||
|---|---|---|---|
|
#18+
SY, Большое спасибо за проделанную работу. Попробовал создать с нуля ситуацию у себя - тоже не воспроизвелась. Стал разбирать в чем еще отличие боевой и синтетической таблиц. Оказалось, наличие в таблице-источнике функционального индекса на любом поле и виртуальной колонки на другом (секционирование не влияет) приводит при импорте к ошибке "ORA-54013: Операция INSERT для виртуальных столбцов запрещена" даже если в таблице-приемнике не будет индексов. Если на источнике индекс удалить (сделать unusable не помогает), импорт проходит без ошибок. После чего можно создать индекс на таблице-приемнике. И все норм. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.08.2018, 14:00 |
|
||
|
IMPDP: Перенос секционированной на основе виртуальной колонки таблицы
|
|||
|---|---|---|---|
|
#18+
Иллюстрация: Приводит к ошибке: drop table tbl purge; / create table tbl( empno number, ename varchar2(30), date_start date, date_end date part number generated always as (case when date_end is null then 1 else 0 end) virtual ); / create index IDX_TBL_DATE_START on TBL (NVL(DATE_START,TO_DATE('2050-01-01 00:00:00', 'syyyy-mm-dd hh24:mi:ss'))); insert into tbl (empno, ename, date_start, date_end) select 1 ,'tst1' ,sysdate ,sysdate from dual; insert into tbl (empno, ename, date_start, date_end) select 0 ,'tst0' ,sysdate ,null from dual; / commit; impdp user/pwd@bd directory=IMP logfile=IMP.log NETWORK_LINK=link job_name=IMP SCHEMAS=schema_name CONTENT=METADATA_ONLY INCLUDE=TABLE:\"LIKE \'TBL\'\" impdp user/pwd@bd directory=IMP logfile=IMP.log NETWORK_LINK=link job_name=IMP SCHEMAS=schema_name CONTENT=DATA_ONLY INCLUDE=TABLE:\"LIKE \'TBL\'\" Делаем drop index IDX_TBL_DATE_START; и импорт просто данных impdp user/pwd@bd directory=IMP logfile=IMP.log NETWORK_LINK=link job_name=IMP SCHEMAS=schema_name CONTENT=DATA_ONLY INCLUDE=TABLE:\"= \'TBL\'\" Все отлично импортируется. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.08.2018, 14:09 |
|
||
|
IMPDP: Перенос секционированной на основе виртуальной колонки таблицы
|
|||
|---|---|---|---|
|
#18+
Так, impdp идет через network_link о чем ты умолчал. Oracle 12.1 это версия исходника или удаленной базы куда импортируем? Приведи обе версии. SY. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.08.2018, 15:26 |
|
||
|
IMPDP: Перенос секционированной на основе виртуальной колонки таблицы
|
|||
|---|---|---|---|
|
#18+
SY, разницы в поведении нет что по dblink, что из локального дампа. версии одинаковые и там и там. проблема решается пересозданием индекса. мне кажется, это глюк/фича оракла и вряд ли получится ее победить ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.08.2018, 16:18 |
|
||
|
IMPDP: Перенос секционированной на основе виртуальной колонки таблицы
|
|||
|---|---|---|---|
|
#18+
Такая ситуация, насколько помню, была в ранних версиях 10g Не она ли является источником? PS. FBI создают в метаданных виртуальную колонку в таблице, и иногда обращение к метаданным было не совсем корректным ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.08.2018, 16:27 |
|
||
|
IMPDP: Перенос секционированной на основе виртуальной колонки таблицы
|
|||
|---|---|---|---|
|
#18+
Вячеслав Любомудров, Возможно, источник проблемы в этом, но версия на обоих серверах - 12.1.0.2.0 Да, FBI создает скрытую виртуальную колонку, но если в таблице явно объявленной виртуальной колонки нет - ошибки нет. Ошибки нет если есть виртуальная колонка, но нет функционального индекса. А вот если если есть и колонка и индекс, такое чувство, что ораклу рвет крышу и он пытается в нее инсертить данные из виртуальной колонки источника или явной или скрытой. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.08.2018, 17:49 |
|
||
|
IMPDP: Перенос секционированной на основе виртуальной колонки таблицы
|
|||
|---|---|---|---|
|
#18+
Andrew999SY, разницы в поведении нет что по dblink, что из локального дампа. версии одинаковые и там и там. проблема решается пересозданием индекса. мне кажется, это глюк/фича оракла и вряд ли получится ее победить Да нет, проблема только с network_link. Без network_link (expdp/impdp): Код: 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. 109. 110. 111. 112. 113. 114. 115. 116. 117. 118. 119. 120. 121. 122. 123. 124. 125. 126. 127. 128. 129. 130. 131. 132. 133. 134. 135. 136. 137. 138. 139. Aвот с network_link: Код: 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. 109. 110. 111. Похоже на реинкарнацию ORA-54013 Raised During Network Link Import Of Tables With Virtual Columns (Doc ID 1305849.1). SY. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.08.2018, 18:03 |
|
||
|
IMPDP: Перенос секционированной на основе виртуальной колонки таблицы
|
|||
|---|---|---|---|
|
#18+
SY, Да, вчера вечером у себя проверил - тоже при impdp\expdp на одном сервере с remap_schema все работает. Я почему подумал что разницы нет, потому как я выгрузил только метаданные, перенес на новый сервер, залил, а потом только данные начал качать по dblink'у. Так что, да, только при перекачивании данных по сети получаем ошибку. Только решить ее оперативно не получится. Придется или выгружать ddl индексов, дропать их на источнике и создавать на приемнике после переливки или пытаться перенести и залить полный дамп с данными сразу. Большое спасибо за помощь в выявлении истинных причин проблемы. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.08.2018, 08:04 |
|
||
|
IMPDP: Перенос секционированной на основе виртуальной колонки таблицы
|
|||
|---|---|---|---|
|
#18+
Andrew999, Ошибка появляется при DATA_ONLY, так-что если нет весткой причины разбивать на METADATA_ONLY и DATA_ONLY: Код: plsql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. SY. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.08.2018, 15:06 |
|
||
|
IMPDP: Перенос секционированной на основе виртуальной колонки таблицы
|
|||
|---|---|---|---|
|
#18+
SY, Есть определенные условия вроде переноса метаданных некоторых таблиц без данных, но их можно решить экспортом/импортом в два прохода. Сейчас прорабатываю эту версию с выгрузкой и физическим переносом дампов. А при попытке перетянуть все по сети возникла непреодолимая ошибка. Я ее описывал тут: http://www.sql.ru/forum/1299803/neustranimaya-oshibka-pri-importe-impdp-cherez-dblink-kupw-worker-fetch-xml-objects К сожалению, даже по линку на саппорт оракла решение другой проблемы и проблема осталась нерешенной. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.08.2018, 10:33 |
|
||
|
|

start [/forum/topic.php?fid=52&msg=39688312&tid=1883592]: |
0ms |
get settings: |
8ms |
get forum list: |
15ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
41ms |
get topic data: |
10ms |
get forum data: |
3ms |
get page messages: |
69ms |
get tp. blocked users: |
2ms |
| others: | 231ms |
| total: | 385ms |

| 0 / 0 |
