|
|
|
Вопросы о том, как Оракл ищет/выделяет экстенты. И COALESCE впридачу.
|
|||
|---|---|---|---|
|
#18+
Специфика приложения такова, что в схеме пользователя постоянно создаются и удаляются таблицы. (Не будем жужжать насчет того, провильно или нет). Но факт в том, что этот тэйблспэйс, в котором обитают эти таблицы растет бесконтрольно. Казалось бы почему? Ведь по-идее при удалении таблицы все занятые ей экстенты маркируются как свободные и оракл начинает сканировать tablespace на наличие свободных подходящих блоков/экстентов с начала (то есть с первого блока), что гарантирует при многократном удалении одной таблицы и создании ее снова постоянный размер tablespace'а. Ан нет. Оракл пользуется каким-то магическим алгоритмом и выбирает свободные блоки не в начале tablespace'а, а вообще где угодно, вплоть до того, что может увидеть, что в данном куске tablespace'а нет свободных блоков и он, используя параметр AUTOEXTEND расширит tablespace. Например: Из под привелигированного пользователя (например sys'a), создадим tablespace и пользователя, кидающего свои таблицы в этот tablespace: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. Смотрю на созданный tablespace и записываю его размер: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. В общем 5 мег, все как и должно быть. Теперь запускаю тестовый пример (от пользователя TEST): Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. И смотрю чего у меня там со свободным местом: Код: plaintext 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. Вопрос по ходу: почему оракл делает один экстент размером 10 блоков, а не 8, что равно 64К??? (но это не основной вопрос). Теперь снова тест: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. И смотрю, какое же место в свободном пространстве tablespac'а заняли таблицы: Код: plaintext 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. Вижу, что оракл раздал каждой вновь создаваемой таблице свободный экстент почти от балды (первой - 62-й, второй 272-й и тд). Вопрос первый: каким образом оракл сканирует tablespace чтобы раздать таблицам именно такое пространство, то биш как оракл ищет свободные экстенты??? Из этого примера не видно, что оракал также может не найти свободные экстенты, даже если они очевидно присутствуют, что показывает следующий пример: Код: plaintext 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. Много раз вызвав удаление и создание таблиц получаю что мой tablespace раздулся аж до 125 мегабайт. "Умный" оракл!!! Либо я дурак. Код: plaintext 1. 2. 3. 4. 5. 6. 7. Поэтому вопрос второй: при явном наличии свободных экстентов оракл не может их найти, выделяет в незанятой области а уже после и наращивает tablespace??? Далее... Знаю, что решить мою проблему может "слитие" свободных экстентов с момощью комманды: Код: plaintext Экстенты сливаются и роста tablespace не происходит. Оракл становится по-настоящему умным и выбирает блоки последовательно с начала tablespac'а. Ну и естественно напрашивается решение для приложения: почему бы после каждого DROP TABLE не далать ALTER TABLESPACE ... COALESCE? А вот здесь начинается настоящее шаманство: COALESCE не сливает эктенты, если вызывать его в процедуре с коммандами CREATE/DROP и именно только из SQL+'а. Такой пример: Это из под sys: Код: plaintext 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. Все чинно, видим одим длинный экстент. А это из под пользователя: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. "COALESCED OK" говорит о том, что экстенты слились, однако: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. говорит о том, что хоть комманда ALTER TABLESPACE TEST_TDATA_TSPACE COALESCE хоть и отработалась, но экстенты не слились. Поэтому вопрос третий: почему, черт возьми, не случилось того, что должно было случится - почему не слились экстенты. Но, если я снова просто вызову SYS.COALESCE_TABLESPACE('TEST_TDATA_TSPACE') - то свободные экстенты благополучно сольются. Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. И самое забавное, если верхнюю процедуру я вызову не из SQL+ а, например из SQL Navigator - то процедура обработается как надо. То есть экстенты сольются благополучно. В чем, черт возьми, тут дело то? PS - Oracle 8.1.7 без патчей и под Windows 2000 AdvServer ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.06.2003, 14:35:48 |
|
||
|
Вопросы о том, как Оракл ищет/выделяет экстенты. И COALESCE впридачу.
|
|||
|---|---|---|---|
|
#18+
Сделай EXTENT MANAGEMENT LOCAL. При этом не требуется сращивания свободных экстентов. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.06.2003, 14:43:55 |
|
||
|
Вопросы о том, как Оракл ищет/выделяет экстенты. И COALESCE впридачу.
|
|||
|---|---|---|---|
|
#18+
Нет, софтбильдер, даже при CREATE TABLESPACE TEST_TData_TSpace DATAFILE 'TEST_TData_TSpace_DATA.DAT' SIZE 5M REUSE AUTOEXTEND ON NEXT 5M MAXSIZE UNLIMITED EXTENT MANAGEMENT LOCAL UNIFORM SIZE 64K; происходит рост tablespace при многократном удалении-создании таблиц. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.06.2003, 15:25:42 |
|
||
|
Вопросы о том, как Оракл ищет/выделяет экстенты. И COALESCE впридачу.
|
|||
|---|---|---|---|
|
#18+
Ты табличную область создаёшь из существующего файла. А в нём уже имеется какое-то определённое распределение экстентов. В данном случае нет чистоты экспериментов. Создай новый. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.06.2003, 15:40:43 |
|
||
|
Вопросы о том, как Оракл ищет/выделяет экстенты. И COALESCE впридачу.
|
|||
|---|---|---|---|
|
#18+
И попробуй сделать: EXTENT MANAGEMENT LOCAL AUTOALLOCATE; ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.06.2003, 15:47:26 |
|
||
|
Вопросы о том, как Оракл ищет/выделяет экстенты. И COALESCE впридачу.
|
|||
|---|---|---|---|
|
#18+
А, таже самая фигня. EXTENT MANAGEMENT LOCAL AUTOALLOCATE - не помогает. PS - я всегда дропал tablespace, потом удалял файл средствами ОС. Так что эксперимент чист. Видно нечист Оракл. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.06.2003, 16:18:29 |
|
||
|
Вопросы о том, как Оракл ищет/выделяет экстенты. И COALESCE впридачу.
|
|||
|---|---|---|---|
|
#18+
А размеры таблиц какие? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.06.2003, 16:20:00 |
|
||
|
Вопросы о том, как Оракл ищет/выделяет экстенты. И COALESCE впридачу.
|
|||
|---|---|---|---|
|
#18+
None Вот результаты тестов на моем Код: plaintext 1. 2. Код: plaintext 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. 140. 141. 142. 143. 144. 145. 146. 147. 148. 149. 150. 151. 152. 153. 154. 155. 156. 157. 158. 159. 160. 161. 162. 163. 164. 165. 166. 167. 168. 169. 170. 171. 172. 173. 174. 175. 176. 177. 178. 179. 180. 181. 182. 183. Как видно Oracle честно освобождает все сегменты, а говорить надо именно про них. Ведь: Код: plaintext 1. 2. 3. Код: plaintext 1. 2. Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. Итак, видно, что для каждой таблицы создается отдельный сегмент, размером в один экстент. Размер этого экстента зависит только от конкретных настроек твоей базы. Вопрос в другом. Почему при удалении таблицы ее сегмент все же остается (первая выборка из DBA_FREE_SPACE) - это явный глюк. Т.е. видно, что весь сегмент пустой, но не понятно откуда вообще взялся тот сегмент, если таблицы уже нет. Поэтому при создании новых таблиц выделяются сегменты из оставшегося свободного места, т.к. нет возможности создания сегмента по верх другого (обрати внимание на мои дампы - в обоих случаях выборка из DBA_FREE_SPACE вернула одну строку!!!) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.06.2003, 16:33:21 |
|
||
|
Вопросы о том, как Оракл ищет/выделяет экстенты. И COALESCE впридачу.
|
|||
|---|---|---|---|
|
#18+
>>Итак, видно, что для каждой таблицы создается отдельный сегмент, размером в один экстент. Размер этого экстента зависит только от конкретных настроек твоей базы. Согласен и не поддается сомнению. >>Вопрос в другом. Почему при удалении таблицы ее сегмент все же остается (первая выборка из DBA_FREE_SPACE) - это явный глюк. Т.е. видно, что весь сегмент пустой, но не понятно откуда вообще взялся тот сегмент, если таблицы уже нет. Итак, насколько я понимаю что творится при удалении: 1) Удалется таблица 2) Удаляются записи о ее экстентах во вьюшке DBA_EXTENTS 3) Эти записи переносятся в DBA_FREE_SPACE. DBA_FREE_SPACE - очевидно вьюшка, которая говорит ораклу о "дырах" свободного пространства в tablespac'e, которые позже можно заюзать. Поэтому никакого глюка нет. Вопрос в другом, почему Оракл так криво использует для поиска свободных экстентов DBA_FREE_SPACE. Почему бы тупо не взять первый пустой подходящий по размеру экстент (так как написано в доке) - и разместить данные в нем. Нет же, выхватывает по одному ему ведомому алгоритму. Так же (наверно) и при EXTENT MANAGEMENT LOCAL - из битовой карты выхватывется не первый (напримр нулевой) бит, а хз какой. >>Поэтому при создании новых таблиц выделяются сегменты из оставшегося свободного места, т.к. нет возможности создания сегмента по верх другого (обрати внимание на мои дампы - в обоих случаях выборка из DBA_FREE_SPACE вернула одну строку!!!) Думаю это не верно. Сегмент - есль логическое объединение экстентов (таблица, индекс и прочее). А экстент - это непрерывный участок блоков - то биш физически живет на диске. В общем я делаю вывод что в девятке все умнее и экстенты сливаются автоматом про DROP TABLE. Или у тебя просто у Вас EXTENT MANAGEMENT LOCAL - в нем всегда DBA_FREE_SPACE возвращает одну строку. to softbuilder@inbox.ru >>А размеры таблиц какие? А какая разница то? В данном случае они пустые. Но даже пустые занимают по одному экстенту, что абсолютно естественно. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.06.2003, 17:17:38 |
|
||
|
Вопросы о том, как Оракл ищет/выделяет экстенты. И COALESCE впридачу.
|
|||
|---|---|---|---|
|
#18+
Так... Нашел 8.1.5 и провел на ней тест: Код: plaintext 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. 140. 141. 142. 143. 144. 145. 146. 147. 148. 149. 150. 151. 152. 153. 154. 155. 156. 157. 158. 159. 160. 161. 162. 163. 164. 165. 166. 167. 168. 169. 170. 171. 172. 173. 174. 175. 176. 177. 178. 179. 180. 181. 182. 183. 184. 185. 186. 187. 188. 189. 190. 191. 192. 193. 194. 195. 196. 197. 198. 199. 200. 201. 202. 203. 204. 205. 206. 207. 208. 209. 210. 211. 212. 213. 214. 215. 216. 217. 218. 219. 220. 221. 222. 223. 224. 225. 226. 227. 228. 229. 230. 231. 232. Прекрасно видно, что вместо одного свободного сегмента имеем 30 свободных сегментов от удаленных таблиц и сегмент остаточного свободного места. А теперь фишка! При повторном прогоне этого же теста таблицы размещаются в тех же сегментах, что и их предшественники!!! Проверь :) Код: plaintext 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. 140. 141. 142. 143. 144. 145. 146. 147. 148. 149. 150. 151. 152. 153. 154. 155. 156. 157. 158. 159. 160. 161. 162. 163. 164. 165. 166. 167. 168. 169. 170. 171. 172. 173. 174. 175. 176. 177. 178. 179. 180. 181. 182. 183. 184. 185. 186. 187. 188. 189. 190. Это определенно глюк Oracle 8i. Сейчас залезу в доку именно по нему и посмотрю подробнее. To be continued... :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.06.2003, 17:44:30 |
|
||
|
Вопросы о том, как Оракл ищет/выделяет экстенты. И COALESCE впридачу.
|
|||
|---|---|---|---|
|
#18+
Па-ба! Ту-ру-ру!!! Смотри: Код: plaintext 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. Вот ключевая фраза: Dictionary-Managed Tablespaces This is the default method of space management in a tablespace. It was the only method available in Oracle releases 8.0 and earlier. Проверяем: Код: plaintext 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. 140. 141. 142. 143. 144. 145. 146. 147. 148. 149. 150. 151. 152. 153. 154. 155. 156. 157. 158. 159. 160. 161. 162. 163. 164. 165. 166. 167. 168. 169. 170. 171. 172. 173. 174. 175. 176. 177. 178. 179. 180. 181. 182. 183. 184. 185. 186. 187. 188. 189. 190. 191. 192. 193. 194. 195. 196. 197. 198. 199. 200. 201. 202. 203. 204. 205. 206. 207. 208. 209. 210. 211. 212. 213. 214. 215. 216. 217. 218. 219. 220. 221. 222. 223. 224. 225. 226. 227. 228. 229. 230. Итог: нефиг использовать Dictionary-Managed Tablespaces, которые являются default в 8i! Переходи на Locally-Managed Tablespaces - default в 9i. Так что это может быть и глюк, но так как он документирован, то перерастает в фичу :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.06.2003, 18:04:14 |
|
||
|
Вопросы о том, как Оракл ищет/выделяет экстенты. И COALESCE впридачу.
|
|||
|---|---|---|---|
|
#18+
to Fedorchenko Aleksey: Алексей, еще раз повторюсь - нету здесь накакого бага. Все аккуратно. А баг вот в чем, и пусть большие люди мне объяснят почему такое происходит: Код: plaintext 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. Код: plaintext 1. 2. 3. 4. 5. 6. 7. Все осталось по прежнему! И другая виюшка, фри-спэйсная: Код: plaintext 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. Откуда видно, что Оракл размещает таблицы аккурат на место свободных экстентов. (Даже полсе 5 проходов. Очевидно что и после 1000 все будет также). А как он там это уж делает - черт с ним. Главное остается в пределах заданного пространства. А теперь забава. Оракл утирает мне нос: Для читоты сливаю экстенты: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. И запускаю процедуру, которая казалось бы ничем не отличается от верхних 10 блоков: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. Смотрю место: Код: plaintext 1. 2. 3. 4. 5. 6. 7. Файл раздулся до 15Мегов. ИТОГ: В пределах одного PL/SQL блока вновь созданные объекты (таблицы, индексы), могут размещаться только выше последнего выделенного экстента. ЧТД писать совсем не хочется. Потому, что нужно много что переписывать. Аминь. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.06.2003, 19:41:04 |
|
||
|
Вопросы о том, как Оракл ищет/выделяет экстенты. И COALESCE впридачу.
|
|||
|---|---|---|---|
|
#18+
Есть еще одна тонкая фишка: если на tablespace в default storage (pctincrease N) N>0, то процесс SMON будет сам сливать свободные экстенты. Почему он не делает этого при pctincrease = 0? Логика тут железная: если pctincrease = 0, то считается, что в этом tablespace все экстенты имеют одинаковый размер, т.е. сегменты могут без проблем пользоваться освобожденными экстентами друг друга без всяких там слияний, и, соответственно, сливать освобожденные экстенты незачем. Естественно, в этом случае любые отклонения storage для отдельных экстентов от default параметров tablespace приводят.. к тому, к чему они приводят. Если pctincrease = 1 (например), то smon будет периодически просыпаться и собирать свободное место. ВОВСЕ НЕ ФАКТ, что он проснется тогда, когда надо, и успеет вовремя. По этому поводу есть какие-то недокументированные параметры (на память не помню). Вполне возможно, что в последнем блоке после удаления таблиц надо было разбудить smon, и все бы отработало. Вот тут кое-что объясняется: http://www.dbazine.com/hordila3.html. Просто в Oracle никто не подумал, что кто-то попробует сделать 1000 create/drop table в секунду :-) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.06.2003, 11:10:29 |
|
||
|
Вопросы о том, как Оракл ищет/выделяет экстенты. И COALESCE впридачу.
|
|||
|---|---|---|---|
|
#18+
None еще раз повторюсь - нету здесь накакого бага. Все аккуратно. Ну да, если используется Dictionary-Managed Tablespaces, то это действительно "аккуратно" - не всегда сегмент из-под таблицы присоединяется к сегменту неиспользованного пространства. В случае с Locally-Managed Tablespaces не остаются пустые сегменты после таблиц - создается одно нефрагментированное свободное пространство. Это можно отнести к особенностям управления распределения места в табличных пространствах. ИТОГ: В пределах одного PL/SQL блока вновь созданные объекты (таблицы, индексы), могут размещаться только выше последнего выделенного экстента. Похоже, что так. Причем это актуально и для Locally-Managed Tablespaces - в 30 циклах создания/удаления 30 таблиц файл разросся до 60 Мб, хотя по завершении теста табличное пространство было пустым. Это похоже на багофичу :( X-Max Вот тут кое-что объясняется Интересная статья, только она применима к ручной сборке на Dictionary-Managed Tablespaces, а как показали опыты и на Locally-Managed Tablespaces виден рост табличного пространства, хотя там если память освобождается, то она сразу без помощи SMON возвращается Oracle как свободная. Да... Надо бы у Тома спросить :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.06.2003, 12:10:12 |
|
||
|
Вопросы о том, как Оракл ищет/выделяет экстенты. И COALESCE впридачу.
|
|||
|---|---|---|---|
|
#18+
Вобщем вывод такой из всей этой бадяги - нех... создавать таблицы в PL/SQL. А делать по человечески в скриптах. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.06.2003, 12:18:13 |
|
||
|
Вопросы о том, как Оракл ищет/выделяет экстенты. И COALESCE впридачу.
|
|||
|---|---|---|---|
|
#18+
ИТОГ: В пределах одного PL/SQL блока вновь созданные объекты (таблицы, индексы), могут размещаться только выше последнего выделенного экстента. Похоже, что так. Причем это актуально и для Locally-Managed Tablespaces - в 30 циклах создания/удаления 30 таблиц файл разросся до 60 Мб, хотя по завершении теста табличное пространство было пустым. Это похоже на багофичу :( Вполне, кстати, ожидаемая. После чтения о ... freelists! Там примерно тоже самое -- блоки, которые освободила сессия, становятся доступными другим только по окончании транзакции. Кстати, о кратности числа блоков пяти -- это вполне описанная фича. Если не ошибаюсь, в девятке её пофиксили. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.06.2003, 00:50:06 |
|
||
|
|

start [/forum/topic.php?fid=52&msg=32174481&tid=1990143]: |
0ms |
get settings: |
7ms |
get forum list: |
14ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
177ms |
get topic data: |
6ms |
get forum data: |
2ms |
get page messages: |
49ms |
get tp. blocked users: |
1ms |
| others: | 221ms |
| total: | 483ms |

| 0 / 0 |
