|
|
|
Насколько известны баги Oracle 8.1.6.1i / WinNT
|
|||
|---|---|---|---|
|
#18+
Где можно найти перечень обнаруженных багов и roundtrip этих багов? На данный момент я обнаружил и постоянно вынужден обходить следующие баги:SELECT из GROUP BY неправильно выбирает DATE поле Код: plaintext 1. 2. Лечится тривиально: Код: plaintext 1. 2. Включение параллельности приводит к неправильной записи данных в UPDATE. Здесь вообще ничего выяснить не удалось, ибо после первых же признаках порчи данных пришлось напрочь все выключить без дальнейших экспериментов. На сервере один процессор, может это для меня вообще неактуально? Использование COMPRESSED индекс по полю с малым количеством уникальных значений (а ведь именно на таких полях имеет смысл их использовать) приводит к ORA-600. Где-то от кого я слышал, что народ не рекомендует использовать COMPRESSED index, но на сайте у Тома я встречал в контексте упоминание об использовании COMPRESSED индексов. Да и "если звезды зажигают, значит это кому-то нужно", или: "если фича присутствует, значит ее можно использовать". Только вот не получается... Отсюда вопросы: Я что-то делаю не так, или действительно есть такие баги? Известны ли такие баги? Где найти описание know bugs вне МЕТА-линк? P.S. У меня нет входа на META-link ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.06.2003, 10:46:29 |
|
||
|
Насколько известны баги Oracle 8.1.6.1i / WinNT
|
|||
|---|---|---|---|
|
#18+
Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. Очередной какой-то гон на Oracle. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.06.2003, 11:14:05 |
|
||
|
Насколько известны баги Oracle 8.1.6.1i / WinNT
|
|||
|---|---|---|---|
|
#18+
Я не гоню на Oracle, но факт остается фактом. Я жалуюсь на судьбу :) Привести весь пример с исходниками очень накладно из-за объема описаний VIEW, таблиц и больших селектов. Есть некоторая агрегирующая VIEW, из которой потом выбираются данные. Обнаружив странные результаты выборки вставил во VIEW только TRUNC(date) и результат стал нормальным. Я думаю, что это связано прежде всего с тем, что во второй селект попадает уже не исходное поле, а результат вычисления, что и послужило изменению логики выборки и конечного результата. На подобное поведение я натолкнулся уже три раза. В первый раз потратил полдня на поиск причины, пока уже не стал пробовать все подряд и случайно напоролся на такое "решение". Во второй и третий раз я потратил менее 10 минут на поиск нужного места (нужной VIEW) и замену поля на формулу от поля. И каждый раз все сразу исправляется. Я сделал единственно верный вывод -- это баг. И что, я один на такое наткнулся? Стганно, стганно... Ну а как вы, softbuilder, прокоментируете Compressed Index? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.06.2003, 11:32:29 |
|
||
|
Насколько известны баги Oracle 8.1.6.1i / WinNT
|
|||
|---|---|---|---|
|
#18+
Я прокомментирую, что нужно переходить на 8.1.7 и патчиться до опупения. Искать описания багов мне лень, но в 8.1.6 и других полно. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.06.2003, 11:34:53 |
|
||
|
Насколько известны баги Oracle 8.1.6.1i / WinNT
|
|||
|---|---|---|---|
|
#18+
to Поплюев Алексей: Прежде чем я поверю что это баг, опубликуй результат : Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.06.2003, 11:43:16 |
|
||
|
Насколько известны баги Oracle 8.1.6.1i / WinNT
|
|||
|---|---|---|---|
|
#18+
Нашел немного другое место, но демонстрирует лучше некуда. Собственно сам запрос (TRUNC закоментировал): Код: 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. Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.06.2003, 12:37:41 |
|
||
|
Насколько известны баги Oracle 8.1.6.1i / WinNT
|
|||
|---|---|---|---|
|
#18+
to Поплюев Алексей: Неужели ты думаешь, что кому либо удобно анализировать такие результаты запросов? И понять в чём между ними разница. А нельзя ли сделать, то что я просил? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.06.2003, 12:53:16 |
|
||
|
Насколько известны баги Oracle 8.1.6.1i / WinNT
|
|||
|---|---|---|---|
|
#18+
Все нормально, так и должно быть - это не баг. В твоем примере сортировка идет по полю doc_date, как в первом случае, так и во втором (именно по полю doc_date, а не по функции TRUNC(d.doc_date) ). Если ты хочешь, что-бы сортировка шла по функции пиши Код: plaintext 1. 2. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.06.2003, 12:58:41 |
|
||
|
Насколько известны баги Oracle 8.1.6.1i / WinNT
|
|||
|---|---|---|---|
|
#18+
2 softbuilder Дело в том, что при попытке сократить количество полей во внутреннем селекте теряется эффект aka BUG. Я привожу так как есть и именно так есть BUG, анализировать остальные поля нет необходимости, пользователи их анализировали, и сказали, что все кроме даты верно. 2 drive Поле DOC_DATE -- это чистая дата, там нет времени, оно так хранится в БД, посему хоть по нему сортируй, хоть по резльтату функции. Причем из второго результата видно, что в поле нет времени (мой формат по умолчанию выводит время). All Итак, в селекте меняю только одно -- вычислимость DATE. Результат разный. Решать вам -- баг это или нет. Я для себя это определяю однозначно -- баг. Могу кинуть сюда описание всех используемых таблиц. Я не первый год работаю с разными СУБД. Как-никак лет 20 программирую. В каждой из СУБД, ОС, компиляторах, редакторах -- есть свои баги. Я предполагаю, что ORACLE -- не исключение. Я c ORACLE работаю недавно. Чем дольше работаю, тем больше нравится. Хотелось бы не открывать самому Америку (баги), а найти перечень. Могу, как оказалось и сам добавить в копилочку свои две копейки... Вот и все, собственно. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.06.2003, 13:12:47 |
|
||
|
Насколько известны баги Oracle 8.1.6.1i / WinNT
|
|||
|---|---|---|---|
|
#18+
to Поплюев Алексей: Как всё таки трудно с такими как ты общаться, слов нет просто. Код: plaintext 1. 2. 3. 4. 5. Где видно доказательство твоих слов? Если бы время было были бы нули, а у тебя их вообще нет. У меня например прекрасно всё видно. Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. Как что не надо гнать. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.06.2003, 13:47:12 |
|
||
|
Насколько известны баги Oracle 8.1.6.1i / WinNT
|
|||
|---|---|---|---|
|
#18+
Пожалуйста, еще раз объясните, что вам не понравилось в результатах ваших запросов. Что закоментаренный, что откоментаренный вариант выдают полностью правильные результаты! Это не то, что не баг - это правильное выполнение запроса, если бы было не так, то тогда был бы баг. Пожалуста, напишите, что по вашему должен выдавать откоментаренный (с функцией TRUNC) запрос. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.06.2003, 14:03:32 |
|
||
|
Насколько известны баги Oracle 8.1.6.1i / WinNT
|
|||
|---|---|---|---|
|
#18+
Ok. Нашел более упрощенную форму, дающую тот же результат, чтобы удовлетворить обоих оппонентов сразу: Код: 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. А теперь без вычислений: Код: 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. Как видим, время выводится, если оно есть. Это ответ и softbuilder, а также и для drive. 2 drive Обрати внимание на ID записи -- порядок ВСЕГДА ОДИН И ТОТ ЖЕ ! Обрати внимание так же на дату (и в моем первом посте именно об этом и говориться). 2 softbuilder Насчет неудобств промолчу. Готов говорить по существу. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.06.2003, 14:20:36 |
|
||
|
Насколько известны баги Oracle 8.1.6.1i / WinNT
|
|||
|---|---|---|---|
|
#18+
А куда нолики делись во втором случае? В какой среде ты выполняешь запросы? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.06.2003, 14:41:03 |
|
||
|
Насколько известны баги Oracle 8.1.6.1i / WinNT
|
|||
|---|---|---|---|
|
#18+
А, ну теперь более менее понятно. Во-первых, попробуй, заменить "d.doc_date doc_date" на "to_char(d.doc_date,'DD-MM-YYYY HH24:MI:SS') doc_date" Во-вторых, попробуй те же самые запросы выполнить не в SQL Navigator, а в SQL*Plus (для запуска выполни команду "sqlplusw")! Вполне возможно, что это как раз баг SQL Navigator'а. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.06.2003, 14:41:14 |
|
||
|
Насколько известны баги Oracle 8.1.6.1i / WinNT
|
|||
|---|---|---|---|
|
#18+
И еще, ты хочешь сказать что это Oracle виноват в том что для документа: id=188839402 doc_date=20-июн-2003 doc_num=48 При добавлении doc_date+1/24 = 19-июн-2003 1:00:00 ??? to drive: Я его с самого начала посоветовал это сделать, но человек явно не понимает. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.06.2003, 14:47:14 |
|
||
|
Насколько известны баги Oracle 8.1.6.1i / WinNT
|
|||
|---|---|---|---|
|
#18+
2 softbuilder Выполняю запросы в SQLnav v4.0c2 [build 148]. Он сам автоматом показывает время, если оно есть, иначе -- только дату. Вот и нету ноликов. И я даже сейчас не гоню :) 2 drive Если я, следуя твоему совету, сделаю "to_char(d.doc_date,'DD-MM-YYYY HH24:MI:SS') doc_date", то это уже формула от поля, а в данном случае как раз ЛЮБАЯ формула от поля дает правильный результат. Но дело-то как раз в том, что в случае выборки голимого поля возникает БАГ. И то, что это не баг SQLnav мне очевидно потому, что пользователи заметили данный фефект в прикладной системе, и эти тетеньки ничего об SQLnav не знают, ессно. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.06.2003, 14:52:50 |
|
||
|
Насколько известны баги Oracle 8.1.6.1i / WinNT
|
|||
|---|---|---|---|
|
#18+
2 softbuilder Именно это я и толдычу! Именно, в документе действительно 19е число, но при ТАКОМ селекте выдает 20е! В этом-то и есть весь сыр-бор. А то, что я могу вычислить из 19го числа 19-е число, так оно мне надо? Что, вам вместо "+1/24" сделать TO_CHAR ? Пожайлуста: Код: 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. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.06.2003, 14:57:19 |
|
||
|
Насколько известны баги Oracle 8.1.6.1i / WinNT
|
|||
|---|---|---|---|
|
#18+
В SQL*Plus проверь, по крайней мере точно будет понятно, у кого глюк ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.06.2003, 15:01:21 |
|
||
|
Насколько известны баги Oracle 8.1.6.1i / WinNT
|
|||
|---|---|---|---|
|
#18+
Да действительно, обязательно проверь в SQL*Plus. И еще, я посмотрел на cелект, его можно упростить: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. Лучше, обходиться без вложенного селекта (когда это возможно). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.06.2003, 15:13:06 |
|
||
|
Насколько известны баги Oracle 8.1.6.1i / WinNT
|
|||
|---|---|---|---|
|
#18+
Ну если это вас утешит... Только сразу предупреждаю: шаманства в SQLplus с форматированием результата -- не моя стихия. Главное сейчас ведь результат, не так ли ? А результат с каждым разом один и тот же -- БАГ. Код: 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. 233. 234. 235. 236. 237. 238. 239. 240. 241. 242. 243. 244. 245. 246. 247. 248. 249. 250. 251. 252. 253. 254. 255. 256. 257. 258. 259. 260. 261. 262. 263. 264. 265. 266. 267. 268. 269. 270. 271. 272. 273. 274. 275. 276. 277. 278. 279. 280. 281. 282. 283. 284. 285. 286. 287. 288. 289. 290. 291. 292. 293. 294. 295. 296. 297. 298. 299. 300. 301. 302. 303. 304. 305. 306. 307. 308. 309. 310. 311. 312. 313. 314. 315. 316. 317. 318. 319. 320. 321. 322. 323. 324. 325. 326. 327. 328. 329. 330. 331. 332. 333. 334. 335. 336. 337. 338. 339. 340. 341. 342. 343. 344. 345. 346. 347. 348. 349. 350. 351. 352. 353. 354. 355. 356. 357. 358. 359. 360. 361. 362. 363. 364. 365. 366. 367. 368. 369. 370. 371. 372. 373. 374. 375. 376. 377. 378. 379. 380. 381. 382. 383. 384. 385. 386. 387. 388. 389. 390. 391. 392. 393. 394. 395. 396. 397. 398. 399. 400. 401. 402. 403. 404. 405. 406. 407. 408. 409. 410. 411. 412. 413. 414. 415. 416. 417. 418. 419. 420. 421. 422. 423. 424. 425. 426. 427. 428. 429. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.06.2003, 15:13:59 |
|
||
|
Насколько известны баги Oracle 8.1.6.1i / WinNT
|
|||
|---|---|---|---|
|
#18+
Уважаемые, я так и не понял: пошумели, понаехали, и успокоились. :) Есть где known bugs & trip around глянуть outside of the META-link ? И, однако, так и остались мои вопросы без резолюции: признать случай с датой багом и занести в анналы. :) работают ли compressed index в 8.1.6 ? есть ли необходимость при одном проце использовать параллельность? если да, то что я мог сделать не так, чтобы параллельные update писали НЕПРАВИЛЬНЫЕ данные в записи? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.06.2003, 17:30:33 |
|
||
|
Насколько известны баги Oracle 8.1.6.1i / WinNT
|
|||
|---|---|---|---|
|
#18+
Надо по уму результы выкладывать - здесь же действительно не служба поддержки, которая будет во что-бы то ни стало что-то делать. Потом, про 8.1.6 вообще никто и не спорит что она глючная. И что надо переходить на 8.1.7. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.06.2003, 17:53:13 |
|
||
|
Насколько известны баги Oracle 8.1.6.1i / WinNT
|
|||
|---|---|---|---|
|
#18+
Я понимаю, что не служба поддержки, так я ведь и не прошу ничего конкретного за меня сделать, а только общие соображения. А то наткнешься вот на такой баг с датой, и сидишь часами у себя ошибку пытаешься найти, эксперименты ставишь там где просто кодировать нужно. Или вот про compressed -- прочитал, настроил свои процедуры генерации по мета, ночью они пересторили все нужные индексы на Compressed, утром пришли юзеры, и тут ТАКОЕ началось... А ведь это просто ТЕ ЖЕ ИНДЕКСЫ в другом внутреннем формате, который никоим образом не должен повлиять на принципиальную работоспособность системы, только на быстродействие! Аналогично получилось с PARALLEL -- опять же ночью везде где по логике распараллеливание будет полезным прикрутил в таблицы, настроил adaptive, а утром часа через два пользователи начали таскать и тыкать мне свои фактуры, прайсы и всякую другую лабуду, как будто бы мне интересно очень что там у них понавылазило. :) А я ведь все это после прочтения официальной документации делаю. Не сам же придумываю. Синтаксически все корректно, да и разумом все понятно и должно работать, раз задекларировано. Ан нет. Вот и подумалось, что неплохо бы найти достаточно большой список чужих шишек, чтобы самому все это себе не набивать. Почему на боевой базе все это делаю? Как же я на тестовой базе буду параллельность иммитировать? Да и не интересно мне проверять написанное в официальной документации. Я ведь почему без продробностей писал, только как вопрос: где найти know bug list. А не для того, чтобы у меня ошибку нашли и поправили меня. То что это баг оракла я сам уже понял и не хотел на кого-то гнать и наезжать. И уж конечно не хочется, чтобы на меня гнали и наезжали. :) Насчет 8.1.7. Тут нужно осторожничать. Ведь если я вдруг сжал индексы и получил по мордам, я смог восстановить работоспособность системы простым пересозданием индексов. С переходом на другую версию так просто не выйдет -- быстро перейти обратно не получится. Поэтому перед ТЕМ КАК нужно четко представлять себе все грабли такого перехода. Если придется тонну кода перелопатить -- я просто физически не смогу это быстро сделать, а фирма стоять не может. А если - не дай бог - еще и отличия возникнут для Клиента (Дельфи/ODAC), то тут мне полная хана наступит. Так что я уж лучше как-нибудь "пешком постою". ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.06.2003, 18:45:56 |
|
||
|
|

start [/forum/topic.php?fid=52&msg=32188917&tid=1989857]: |
0ms |
get settings: |
9ms |
get forum list: |
14ms |
check forum access: |
2ms |
check topic access: |
2ms |
track hit: |
179ms |
get topic data: |
10ms |
get forum data: |
2ms |
get page messages: |
63ms |
get tp. blocked users: |
1ms |
| others: | 192ms |
| total: | 474ms |

| 0 / 0 |
