|
|
|
Перемещение LOP partitions в другую ТС
|
|||
|---|---|---|---|
|
#18+
Наплодили тут columns c LOB partitions c INITIAL 8M NEXT 1M, при этом 90% LOB'ов пустыею Пытаюсь перерести в другую ТС (или в этуже ТС) с изменением INITIAL и NEXT. Выдает ошибку: Код: plsql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. shrink_space не работает. В доке https://docs.oracle.com/cd/B28359_01/server.111/b28286/statements_3001.htm#i2104128 разделяют: отдельно: storage_clause, отдельно tablespace (+ может быть lob_parameters + может быть storage_clause) поэтому я отдельными запросамию ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.05.2018, 18:43 |
|
||
|
Перемещение LOP partitions в другую ТС
|
|||
|---|---|---|---|
|
#18+
maxski, одной командой можно подвинуть экстенты и ТП и неск полей на 11.2.0.4 проверил В имени поля не ошибся? Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.05.2018, 20:36 |
|
||
|
Перемещение LOP partitions в другую ТС
|
|||
|---|---|---|---|
|
#18+
Потенциальные не-всем-очевидные проблемы: - символы нац. алфавита вместо латиницы - регистрозависимые идентификаторы. - мисстайп при написании запроса (как вариант - символы нац. алфавита вместо латиницы как сайд-эффект от какого пунто-свитчера) Как порешать: Сделать describe или DDL таблицы, скопипастить идентификатор атрибута. Если в выводе describe/DDL атрибут не в uppercase, то взять в двойные кавычки. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.05.2018, 20:57 |
|
||
|
Перемещение LOP partitions в другую ТС
|
|||
|---|---|---|---|
|
#18+
Код: 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. VIRTUAL? Код: plsql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.05.2018, 09:48 |
|
||
|
Перемещение LOP partitions в другую ТС
|
|||
|---|---|---|---|
|
#18+
maxskiVIRTUAL? С чего ты взял? Код: plsql 1. А ANYDATA хоть и хранится как и LOB своей tablespace не имеет и всегда хранится в том-же tablespace что и сама таблица: Код: 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. SY. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.05.2018, 16:43 |
|
||
|
Перемещение LOP partitions в другую ТС
|
|||
|---|---|---|---|
|
#18+
SY, Завтра. проверю. С VIRTUAL, я тормознул. посмотрел не на тот столбец. Меня тут дергают, от оракла к постгресу и Mysql, от CISCO c ipsec - к сертификатам под nginx. Поэтому у меня и получился заголовок 'LOP' вместо 'LOB'. Хотя я был уверен, что писал "LOB'. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.05.2018, 21:47 |
|
||
|
Перемещение LOP partitions в другую ТС
|
|||
|---|---|---|---|
|
#18+
Выбираем LOB PARTITION SYS_LOB_P171731 и смотрим BYTES, INITIAL, NEXT Код: plsql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. Затем меняем INITIAL и NEXT: Код: plsql 1. И LOB сегмент исчезает: Код: plsql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. Зато есть табличный сегмент: Код: plsql 1. 2. 3. 4. 5. 6. Вообшем, имели на LOB сегменте 8M (плюс сколько-то в не LOB), сейчас 4М всего. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.05.2018, 15:21 |
|
||
|
Перемещение LOP partitions в другую ТС
|
|||
|---|---|---|---|
|
#18+
Ты бы определился что ты хочешь - перенести ANYDATA в другое табличное пространство или перенести PARTITION в другое табличное пространство. SY. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.05.2018, 16:06 |
|
||
|
Перемещение LOP partitions в другую ТС
|
|||
|---|---|---|---|
|
#18+
Задача изначально: "причесать" базу, по возможности, уменьшить размер сегментов. Два аспекта: место диске и фулсканы в память. Ну вот наткнулся на LOB'ы, которые, не то, что storage менять, не хотят перемещаться в другой тейблспейс, для чего есть примеры в доке. Ну если по доке не работает, значит какая то засада. Вот поэтому я спросил тут про то, что есть в доке, но не работает. Ну раз можно переместить в др тейблспейс, значит можно и storage поменять... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.05.2018, 16:34 |
|
||
|
Перемещение LOP partitions в другую ТС
|
|||
|---|---|---|---|
|
#18+
maxskiпо доке не работаетУ тебя anydata, а не lob. Претензия может быть только к непропатченной dbms_metadata, которая вернула лишнее в get_ddl. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.05.2018, 16:57 |
|
||
|
Перемещение LOP partitions в другую ТС
|
|||
|---|---|---|---|
|
#18+
Нмкуда LOB'ы не исчезли, после move partition они поменяли имя: Код: plsql 1. 2. 3. 4. 5. 6. 7. 8. С теми же самыми INITIAL и NEXT Код: plsql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.05.2018, 17:11 |
|
||
|
Перемещение LOP partitions в другую ТС
|
|||
|---|---|---|---|
|
#18+
maxskiВот поэтому я спросил тут про то, что есть в доке, но не работает. Так тебе и ответили. Для поля LOB (LOB/CLOB/XMLTYPE...) можно указывать и соответственно менять табличное пространство. Для поля ANYDATA табличное пространство указать нельзя и соответственно менять табличное пространство нельзя, табличное пространство поля ANYDATA всегда то-же что и самой таблицы и посему перемещается поле ANYDATA только вместе с таблицей. SY. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.05.2018, 18:07 |
|
||
|
Перемещение LOP partitions в другую ТС
|
|||
|---|---|---|---|
|
#18+
SYmaxskiВот поэтому я спросил тут про то, что есть в доке, но не работает. Так тебе и ответили. Для поля LOB (LOB/CLOB/XMLTYPE...) можно указывать и соответственно менять табличное пространство. Для поля ANYDATA табличное пространство указать нельзя .... SY. Похоже, тут сказочники завелись. Создаю такую же таблицу с другим табличным пространством для LOB partitions (USERS и USERS2): Код: 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. Код: 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. Вставляю строки из первой таблицы. Код: 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. Пытаюсь сменить ТС и получаю ошибку: Код: plsql 1. 2. 3. 4. 5. 6. 7. 8. 9. При этом если СLOB, то все перемещается. Я это делал еще в 2005 году без проблем. Единственное, где нашел про ограничения для отдельных типов данных, тут: https://docs.oracle.com/cd/B28359_01/appdev.111/b28393/adlob_tables.htm#ADLOB510 "Relational and object partitioned index-organized tables (partitioned by range, hash, or list) can hold LOBs stored as follows; however, partition maintenance operations, such as MOVE, SPLIT, and MERGE are not supported with: VARRAY datatypes stored as LOB datatypes Abstract datatypes with LOB attributes Nested tables with LOB types" но это не мой случай. может dbms_redefinition? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.05.2018, 18:48 |
|
||
|
Перемещение LOP partitions в другую ТС
|
|||
|---|---|---|---|
|
#18+
maxski, Похоже ты нашел баг который позволяет задать tablespace для ANYDATA если таблица партицирoвана. По идее при указании tablespace для LOB сегмента для партиции Oracle должен ба проверить откуда у LOB сегмента ноги растут, т.е. какого типа поле породившее LOB сегмент. Попробуй указать tablespace для ANYDATA если таблица HE партицирoвана. Но все что этот баг тебе даeт это возможность создать ANYDATA в другом tablespace. А вот при попытке изменить tablespace для поля ANYDATA бага нет и посeму приехали... SY. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.05.2018, 22:00 |
|
||
|
Перемещение LOP partitions в другую ТС
|
|||
|---|---|---|---|
|
#18+
Меня другое волнует. Допустим я поменял INITIAL_EXTENT c 8M на 64k на всех LOB PARTITIONS (пересоздал таблцу). А дальще при вставке строки с "CHANGE_TIME" выходящей за диапазон текущих HIGH_VALUE, то так как PARTITION BY RANGE ("CHANGE_TIME") INTERVAL (NUMTOYMINTERVAL(1,'MONTH')) автоматом создастся новая 'monthly' PARTITION как вот тут: Код: plsql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. При этом, создастся с INITIAL_EXTENT = 8M и NEXT_EXTENT = 1M. Хотя при создании таблицы я прямо указываю: " STORAGE(INITIAL 65536 NEXT 65536 ..." т.е партиции созданные с INITIAL 65536 , а добавленная партиция будет с INITIAL_EXTENT = 8M Как бы это исправить? Чтоб добавленная была бы с INITIAL 65536? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.05.2018, 10:04 |
|
||
|
Перемещение LOP partitions в другую ТС
|
|||
|---|---|---|---|
|
#18+
SYmaxski, Похоже ты нашел баг который позволяет задать tablespace для ANYDATA если таблица партицирoвана. По идее при указании tablespace для LOB сегмента для партиции Oracle должен ба проверить откуда у LOB сегмента ноги растут, т.е. какого типа поле породившее LOB сегмент. Попробуй указать tablespace для ANYDATA если таблица HE партицирoвана. Но все что этот баг тебе даeт это возможность создать ANYDATA в другом tablespace. А вот при попытке изменить tablespace для поля ANYDATA бага нет и посeму приехали... SY. Это не бвг, это ваши фантазии. Создаем таблицу, с TABLESPACE USERS, и первая партиция P00 тоже USERS, a LOB для P00 в USERS2: при этом для определения партиционировния указываю опцию: store in (users2) Код: plsql 1. и теперь уже LOB'ы создаются в USERS2: Код: 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. И LOB'ы ушли в USERS2: Код: 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. при этом NEXT я могу поменять: Код: plsql 1. 2. 3. но не могу поменять все остальное: Код: plsql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. В расшифровке ошибки говорится, что 'TABLESPACE' входит в список разрещенных, а на деле нет. В доке говорится, что уже созданное modify нельзя, можно move, Но про ANYDATA я ничего не нашел. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.05.2018, 10:42 |
|
||
|
Перемещение LOP partitions в другую ТС
|
|||
|---|---|---|---|
|
#18+
maxskiЭто не бвг, это ваши фантазии. Создаем таблицу, с TABLESPACE USERS, и первая партиция P00 тоже USERS, a LOB для P00 в USERS2: В расшифровке ошибки говорится, что 'TABLESPACE' входит в список разрещенных, а на деле нет. В доке говорится, что уже созданное modify нельзя, можно move, Но про ANYDATA я ничего не нашел. Послeдняя попытка. Попробуй указать tablespace для ANYDATA если таблица HE партицирoвана. Не получится ибо поле ANYDATA. И не верь всему что написано в документации. Ноги растут с как минимум Oracle 8. Там в move_table_clause находим: You can also move any LOB data segments associated with the table using the LOB_storage_clause. (LOB items not specified in this clause are not moved.) Что есть правда посколько только поля LOB типов хранились в отдельных сегментах и такие сегменты получили имя LOB segments. Ничего другое в LOB segments не хранилось. В Oracle 9 добавили varray columns и ANYDATA однaко изменили move_table_clause только относительно varray columns move_table_clause : You can also move any LOB data segments associated with the table using the LOB_storage_clause and varray_col_properties clause . LOB items not specified in this clause are not moved. Т.е доку подправили насчет varray columns а про то что теперь LOB data segments используются не только для хранения данных полей LOB типов но и для хранения данных полей ANYDATA которые в отличие от полей LOB типов своей tablespace не имеют и всегда живут в том-же tablespace что и таблица и отдельно их моve'ать нельзя забыли. Так и тащится это в доке... SY. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.05.2018, 14:47 |
|
||
|
Перемещение LOP partitions в другую ТС
|
|||
|---|---|---|---|
|
#18+
SY но и для хранения данных полей ANYDATA которые в отличие от полей LOB типов своей tablespace не имеют и всегда живут в том-же tablespace что и таблица и отдельно их моve'ать нельзя забыли. Так и тащится это в доке... SY. Спасибо за подробный ответ. Вы упорно не хотите видеть, что таблица и ее PARTITION P00 - в одном тейблспейсе USERS, а LOB-PARTITION - в другом USERS2 Код: plsql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. При вставке новых строк в таблицу, создалась новая партиция SYS_P172048, в соответствии с установками по умолчанию. Не я ее добавлял. "oracle" сам создал автоматом при добавлении строк. А P00 -LOB была создана мной: Код: plsql 1. 2. 3. Аргумент "Попробуй указать tablespace для ANYDATA если таблица HE партицирoвана", получается не аргумент. По мне так, Oracle (company) просто реализовали отдельный тейблспейс для LOB-партиций типа ANYDATA (также как и для CLOB). А реализацию MOVE для ANYDATA не закончили из-за багов (Возможно, как указывал Андрей_Анонимус - Orphaned Lobs after marking LOB column unused (Doc ID 461651.1)), поэтому не стали корректировать oerr по этой ошибке (см выше), чтоб потом не возвращать обратно. А реально все мои ANYDATA данные живут в таблице, по той причине, что они меньше 4000 символов (каждая строка ANYDATA). И из-за этого все LOB-партиции пустые, поэтому я и хочу их сократить до 64к, каждую (сейчас 8М, каждая). И пока не знаю как. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.05.2018, 12:59 |
|
||
|
Перемещение LOP partitions в другую ТС
|
|||
|---|---|---|---|
|
#18+
maxskiВы упорно не хотите видеть, что таблица и ее PARTITION P00 - в одном тейблспейсе USERS, а LOB-PARTITION - в другом USERS2 А ты упорно не веришь что это просто баг где для партиций Oracle забывает проверить тип поля которое хранится в LOB сегменте и упорно игнорируешь "Попробуй указать tablespace для ANYDATA если таблица HE партицирoвана". Так-что продолжай биться головой об стену. Хотя, можешь воспользоваться этим багом и попробовать: 1. EXPDP (или EXP) партицированной таблицы 2. DROP партицированная таблицa PURGE. 3. CREATE партицированная таблицa с ANYDATA в нужных tablespace. 4. IMPDP (или IMP) экспортированной таблицы c TABLE_EXISTS_ACTION=APPEND или TRUNCATE. Второй вариант: 1. Переименовать партицированную таблицу. 2. Удалить ключи, индексы итд. 3. Coздать партицированную таблицу (без ключей и индексов итд) со старым именем и с ANYDATA в нужных tablespace. 4. Создать непартицированную таблицу с той-же структурой. 5. Для каждой партиции переименованной таблицы: a) truncate непартицированной таблицы. б) exchange очередной партиции переименованной таблицы с непартицированной таблицей. в) exchange очередной партиции новой партицированной таблицы с непартицированной таблицей. 6) Создать ключи, индексы итд в новой партицированной таблице. 7) Удалить переименованную таблицу (DROP PURGE). SY. P.S. Будеть интересно узнать сработает ли. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.05.2018, 14:00 |
|
||
|
Перемещение LOP partitions в другую ТС
|
|||
|---|---|---|---|
|
#18+
SY, exchange partition не сработает, так как параметры storage должны быть одинаковыми у LOB партиции и у обмениваемой таблицы. Я думал на счет пересоздания таблицы, и это сработало бы, но следующие новые будут создаваться с INITIAL 8M Я пробовал создавать новую таблицу с Код: plsql 1. и для создаваемых партиций указывал: Код: plsql 1. все создавалось, но, новые партиции оракл создавал автоматом с INITIAL 8М, и потом уже эти 8М никак не смувить в 64к. И через какое-то время придется повторять пересоздание. Что вообщем-то не устраивает. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.05.2018, 14:52 |
|
||
|
|

start [/forum/topic.php?fid=52&fpage=114&tid=1883971]: |
0ms |
get settings: |
9ms |
get forum list: |
21ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
47ms |
get topic data: |
12ms |
get forum data: |
3ms |
get page messages: |
71ms |
get tp. blocked users: |
2ms |
| others: | 227ms |
| total: | 398ms |

| 0 / 0 |
