|
Почему так медленно SELECT COUNT(*)
|
|||
---|---|---|---|
#18+
У меня есть таблица TempTbl, в которую я загружаю около 600тыс. записей. И запрос SELECT count(*) FROM TempTbl; длится около 10 сек. Почему так? ... |
|||
:
Нравится:
Не нравится:
|
|||
16.07.2004, 15:17 |
|
Почему так медленно SELECT COUNT(*)
|
|||
---|---|---|---|
#18+
А почему Вы считаете, что должно быть быстрее? _______________ Alex There are three kinds of people: those who can count and those who can't ... |
|||
:
Нравится:
Не нравится:
|
|||
16.07.2004, 15:22 |
|
Почему так медленно SELECT COUNT(*)
|
|||
---|---|---|---|
#18+
Попробуй SELECT COUNT(1) Удачи. ... |
|||
:
Нравится:
Не нравится:
|
|||
16.07.2004, 15:24 |
|
Почему так медленно SELECT COUNT(*)
|
|||
---|---|---|---|
#18+
Александр КПопробуй SELECT COUNT(1) Удачи.Миф /topic/92459&hl=#675568 ... |
|||
:
Нравится:
Не нравится:
|
|||
16.07.2004, 15:56 |
|
Почему так медленно SELECT COUNT(*)
|
|||
---|---|---|---|
#18+
stdioА почему Вы считаете, что должно быть быстрее? _______________ Alex There are three kinds of people: those who can count and those who can't Не, ну реально должно быть 7 секунд :)) ... |
|||
:
Нравится:
Не нравится:
|
|||
16.07.2004, 16:05 |
|
Почему так медленно SELECT COUNT(*)
|
|||
---|---|---|---|
#18+
Александр КПопробуй SELECT COUNT(1) Удачи. Нет, не помогло. ... |
|||
:
Нравится:
Не нравится:
|
|||
16.07.2004, 16:07 |
|
Почему так медленно SELECT COUNT(*)
|
|||
---|---|---|---|
#18+
Причиной может быть, например, высокий уровень hwm /topic/95726&hl= /topic/101861&hl= ... |
|||
:
Нравится:
Не нравится:
|
|||
16.07.2004, 16:20 |
|
Почему так медленно SELECT COUNT(*)
|
|||
---|---|---|---|
#18+
Johnny BombardirНет, не помогло. По-моему SELECT COUNT(ROWID) - наилучший вариант. ... |
|||
:
Нравится:
Не нравится:
|
|||
16.07.2004, 16:20 |
|
Почему так медленно SELECT COUNT(*)
|
|||
---|---|---|---|
#18+
olek Александр КПопробуй SELECT COUNT(1) Удачи.Миф /topic/92459&hl=#675568 Не миф. Практика. ... |
|||
:
Нравится:
Не нравится:
|
|||
16.07.2004, 16:24 |
|
Почему так медленно SELECT COUNT(*)
|
|||
---|---|---|---|
#18+
Alexander DubrovskyНе миф. Практика.Было бы интересно разобраться в этом вопросе. Не могли бы Вы выложить тест, который бы это подтверждал? О том того, что у count(1) или count(rowid) нет преимуществ, говорит тред на asktom, ссылка на которые приведена. мне не удалось найти такой "хитрый" пример, который бы подтверждал недостатки count(*). Если у Вас есть - приведите, пожалуйста. ... |
|||
:
Нравится:
Не нравится:
|
|||
16.07.2004, 16:37 |
|
Почему так медленно SELECT COUNT(*)
|
|||
---|---|---|---|
#18+
В таблице 632581 записей, ,Процессор 800 МГц count(*) - 14,860 count(1) - 15,015 сек count(rowid) - 14,891 сек Причем показания варьируются от запуска к запуску +/- 0,3-0,5 ... |
|||
:
Нравится:
Не нравится:
|
|||
16.07.2004, 17:13 |
|
Почему так медленно SELECT COUNT(*)
|
|||
---|---|---|---|
#18+
А так пробовали count(log(2,4)) ... |
|||
:
Нравится:
Не нравится:
|
|||
16.07.2004, 17:19 |
|
Почему так медленно SELECT COUNT(*)
|
|||
---|---|---|---|
#18+
sum(1) еще попробуйте :) ... |
|||
:
Нравится:
Не нравится:
|
|||
16.07.2004, 17:22 |
|
Почему так медленно SELECT COUNT(*)
|
|||
---|---|---|---|
#18+
2 denm Нет, так точно быстрее не будет, надо sum(2)/2 ... |
|||
:
Нравится:
Не нравится:
|
|||
16.07.2004, 17:27 |
|
Почему так медленно SELECT COUNT(*)
|
|||
---|---|---|---|
#18+
Ora-мучитель2 denm Нет, так точно быстрее не будет, надо sum(2)/2 На ноль дели, на ноль :) ... |
|||
:
Нравится:
Не нравится:
|
|||
16.07.2004, 17:32 |
|
Почему так медленно SELECT COUNT(*)
|
|||
---|---|---|---|
#18+
2 Alexander Dubrovsky Поделил на ноль. ORA-01476: делитель равен нулю Мне кажется на ноль делить нельзя ?! ... |
|||
:
Нравится:
Не нравится:
|
|||
16.07.2004, 17:40 |
|
Почему так медленно SELECT COUNT(*)
|
|||
---|---|---|---|
#18+
Ора-мучитель, ты ведь шутил, правда? Как шутил сегодня Эш+ в топике про модуль. Или может оракл корпу стоит задуматься о включении в доку "Math Concepts"? ... |
|||
:
Нравится:
Не нравится:
|
|||
16.07.2004, 17:52 |
|
Почему так медленно SELECT COUNT(*)
|
|||
---|---|---|---|
#18+
Кстати в топике "про модуль" тоже очевидные ошибки. По-моему каждый знает, что "модуль" - функция унарная и работает так MOD(-5) = MOD(5) = 5 А на счет деления на ноль, я "серьезно поделил". Буду ждать атаки Fuckera. ... |
|||
:
Нравится:
Не нравится:
|
|||
16.07.2004, 18:02 |
|
Почему так медленно SELECT COUNT(*)
|
|||
---|---|---|---|
#18+
Ну, если быть занудой, то тот модуль, о котором ты говоришь пишется в математике как |-5|, а само слово "mod" встречается в алгебре только в смысле 30 mod 7 = 2 =))) ... |
|||
:
Нравится:
Не нравится:
|
|||
16.07.2004, 18:08 |
|
Почему так медленно SELECT COUNT(*)
|
|||
---|---|---|---|
#18+
Все! Я опозорен ! ... |
|||
:
Нравится:
Не нравится:
|
|||
16.07.2004, 18:13 |
|
Почему так медленно SELECT COUNT(*)
|
|||
---|---|---|---|
#18+
Ora-мучительВсе! Я опозорен ! лол ... |
|||
:
Нравится:
Не нравится:
|
|||
16.07.2004, 18:30 |
|
Почему так медленно SELECT COUNT(*)
|
|||
---|---|---|---|
#18+
Johnny BombardirУ меня есть таблица TempTbl, в которую я загружаю около 600тыс. записей. И запрос SELECT count(*) FROM TempTbl; длится около 10 сек. Почему так? Попробуй собрать статистику по таблице. ... |
|||
:
Нравится:
Не нравится:
|
|||
17.07.2004, 10:54 |
|
Почему так медленно SELECT COUNT(*)
|
|||
---|---|---|---|
#18+
1.Долго по сравнению с чем? 2.Что значит "гружу данные", вроде разговор про запрос идет? 3.'Temp' - обычная таблица? 4. план выполнения (лучше трассировка) о чем говорит. 5. Если сразу после загрузки (изменения) данных сделать запрос, затрагивающий измененные данные, то часть вычислительных ресурсов уйдет на "очистку" блоков (строк, которые были ранее блокированы, информация об этом еще сидит в заголовке) (у Кайта есть кое что про это на стр 250). ... |
|||
:
Нравится:
Не нравится:
|
|||
17.07.2004, 16:26 |
|
Почему так медленно SELECT COUNT(*)
|
|||
---|---|---|---|
#18+
Ваша таблица должна быть надлежащим образом проиндексирована и проанализирована, тогда ваш count(*) будет быстрее. Но вообще count(*) - это не обчень быстрая операция. Что касается count(1), то это миф. Посмотрите, какие у вас индексы и если их нет, то создайте на ключвые колонки, а потом проанализируйте таблицу ANALYZE TABLE table_name COMPUTE STATISTICS FOR TABLE FOR ALL INDEXES FOR ALL INDEXED COLUMNS; ... |
|||
:
Нравится:
Не нравится:
|
|||
17.07.2004, 21:10 |
|
Почему так медленно SELECT COUNT(*)
|
|||
---|---|---|---|
#18+
DestroyНу, если быть занудой, то тот модуль, о котором ты говоришь пишется в математике как |-5|, а само слово "mod" встречается в алгебре только в смысле 30 mod 7 = 2 =))) В дополнение: в математике пишется |-5|, а на языках как правило ABS(-5). ... |
|||
:
Нравится:
Не нравится:
|
|||
19.07.2004, 10:57 |
|
Почему так медленно SELECT COUNT(*)
|
|||
---|---|---|---|
#18+
olek Alexander DubrovskyНе миф. Практика.Было бы интересно разобраться в этом вопросе. Не могли бы Вы выложить тест, который бы это подтверждал? О том того, что у count(1) или count(rowid) нет преимуществ, говорит тред на asktom, ссылка на которые приведена. мне не удалось найти такой "хитрый" пример, который бы подтверждал недостатки count(*). Если у Вас есть - приведите, пожалуйста. Ща на 9.2 создал большую таблицу - одинаково. На 8.1.7 пробовали как-то - было быстрее count(1) или count(rowid). ... |
|||
:
Нравится:
Не нравится:
|
|||
19.07.2004, 11:07 |
|
Почему так медленно SELECT COUNT(*)
|
|||
---|---|---|---|
#18+
Судя по тестам автора топика, count(*) - самый быстрый:) ... |
|||
:
Нравится:
Не нравится:
|
|||
19.07.2004, 11:12 |
|
Почему так медленно SELECT COUNT(*)
|
|||
---|---|---|---|
#18+
Alexander Dubrovsky, prostite chto pishu latinitsei - ya na rabote. Text -AskTom, Vi eto chitali. Plus moi opit s Oracle. (*) ili (1), or (8), ili chto ugodno - ne immet znachenia. Ne zabivaite, chto kogda vi v sessii SELECT count(*) pervyi raz eto vsegda dol'she chem vo 2-i ili v 3-i: SQL> set timing on SQL> select count(*) from customer_profile; COUNT(*) --------- 1651366 real: 6531 SQL> select count(1) from customer_profile; COUNT(1) --------- 1651366 real: 5281 SQL> select count(*) from customer_profile; COUNT(*) --------- 1651366 real: 5093 SQL> select count(8) from customer_profile; COUNT(8) --------- 1651366 real: 5187 SQL> select count(7) from customer_profile; COUNT(7) --------- 1651366 real: 5406 SQL> select count(*) from customer_profile; COUNT(*) --------- 1651366 real: 5203 SQL> ... |
|||
:
Нравится:
Не нравится:
|
|||
19.07.2004, 20:32 |
|
Почему так медленно SELECT COUNT(*)
|
|||
---|---|---|---|
#18+
B.prostite chto pishu latinitsei - ya na rabote. Помогает для работающих ... |
|||
:
Нравится:
Не нравится:
|
|||
19.07.2004, 20:39 |
|
Почему так медленно SELECT COUNT(*)
|
|||
---|---|---|---|
#18+
B.(*) ili (1), or (8), ili chto ugodno - ne immet znachenia . Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23.
2 Fucker Похоже труд был напрасен... ... |
|||
:
Нравится:
Не нравится:
|
|||
19.07.2004, 20:53 |
|
Почему так медленно SELECT COUNT(*)
|
|||
---|---|---|---|
#18+
Cпасибо, это здорово,но немного непривычно. Попробую привыкнуть ... |
|||
:
Нравится:
Не нравится:
|
|||
19.07.2004, 22:20 |
|
Почему так медленно SELECT COUNT(*)
|
|||
---|---|---|---|
#18+
Markelenkov , Ваш пример на друную тему. Речь шла о том, что быстрее. Здесь вы выбираете сколько всего у вас записей: select count(*) from emp; COUNT(*) ---------- 14 Здесь вы выбираете сколько у вас comm: SQL> select count(comm) from emp; COUNT(COMM) ----------- 4 Здесь вы выбираете сколько у вас null, SQL> select count(null) from emp; COUNT(NULL) ----------- 0 но этого вы не можете сделать с count, вы только можете select count (*) from emp where comm is null. ... |
|||
:
Нравится:
Не нравится:
|
|||
19.07.2004, 22:32 |
|
Почему так медленно SELECT COUNT(*)
|
|||
---|---|---|---|
#18+
B.Markelenkov , Ваш пример на друную тему. Речь шла о том, что быстрее. Здесь вы выбираете сколько всего у вас записей: select count(*) from emp; COUNT(*) ---------- 14 Здесь вы выбираете сколько у вас comm: SQL> select count(comm) from emp; COUNT(COMM) ----------- 4 Здесь вы выбираете сколько у вас null, SQL> select count(null) from emp; COUNT(NULL) ----------- 0 но этого вы не можете сделать с count, вы только можете select count (*) from emp where comm is null. Все, что я хотел показать в своем примере - это реакция на выделенное мной Ваше категоричное высказывание. ... |
|||
:
Нравится:
Не нравится:
|
|||
19.07.2004, 22:47 |
|
Почему так медленно SELECT COUNT(*)
|
|||
---|---|---|---|
#18+
2 B еще пример по поводу "(*) ili (1), or (8), ili chto ugodno - ne immet znachenia.". Код: 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.
Как видите я поменял всего лишь названия столбцов в count, но сделал возможным индексный доступ. Будьте осторожны с категоричными высказываниями. Успехов. ... |
|||
:
Нравится:
Не нравится:
|
|||
19.07.2004, 23:28 |
|
Почему так медленно SELECT COUNT(*)
|
|||
---|---|---|---|
#18+
Oracle newbie, Vi opat' ne o tom. Count(*) or count(1) or count (*) - eto count na vse recordi tablitsi. Plan takogo selecta zavisit ot indexov: 1* select count(*) from candidate SQL> / real: 359 Execution Plan ---------------------------------------------------------- 0 SELECT STATEMENT Optimizer=CHOOSE (Cost=2 Card=1) 1 0 SORT (AGGREGATE) 2 1 INDEX (FAST FULL SCAN) OF 'CANDIDATE_RUN' (UNIQUE) (Cost =2 Card=3594) Statistics ---------------------------------------------------------- 0 recursive calls 4 db block gets 20 consistent gets 21 physical reads 0 redo size 230 bytes sent via SQL*Net to client 417 bytes received via SQL*Net from client 2 SQL*Net roundtrips to/from client 1 sorts (memory) 0 sorts (disk) 1 rows processed SQL> ed Wrote file afiedt.buf 1* select count(1) from candidate SQL> / real: 344 Execution Plan ---------------------------------------------------------- 0 SELECT STATEMENT Optimizer=CHOOSE (Cost=2 Card=1) 1 0 SORT (AGGREGATE) 2 1 INDEX (FAST FULL SCAN) OF 'CANDIDATE_RUN' (UNIQUE) (Cost =2 Card=3594) Statistics ---------------------------------------------------------- 0 recursive calls 4 db block gets 20 consistent gets 0 physical reads 0 redo size 230 bytes sent via SQL*Net to client 417 bytes received via SQL*Net from client 2 SQL*Net roundtrips to/from client 1 sorts (memory) 0 sorts (disk) 1 rows processed SQL> ed Wrote file afiedt.buf 1* select count(8) from candidate SQL> / real: 344 Execution Plan ---------------------------------------------------------- 0 SELECT STATEMENT Optimizer=CHOOSE (Cost=2 Card=1) 1 0 SORT (AGGREGATE) 2 1 INDEX (FAST FULL SCAN) OF 'CANDIDATE_RUN' (UNIQUE) (Cost =2 Card=3594) Statistics ---------------------------------------------------------- 0 recursive calls 4 db block gets 20 consistent gets 0 physical reads 0 redo size 230 bytes sent via SQL*Net to client 417 bytes received via SQL*Net from client 2 SQL*Net roundtrips to/from client 1 sorts (memory) 0 sorts (disk) 1 rows processed SQL> Kogda vi delaete SELECT count(vasha_colonka) - eto SOVSEM DRUGOE, drugoi execution plan, VSE DRUGOE. SQL> select count(run_sw) from candidate; real: 359 Execution Plan ---------------------------------------------------------- 0 SELECT STATEMENT Optimizer=CHOOSE (Cost=2 Card=1 Bytes=1) 1 0 SORT (AGGREGATE) 2 1 INDEX (FAST FULL SCAN) OF 'CANDIDATE_RUN' (UNIQUE) (Cost =2 Card=3594 Bytes=3594) Statistics ---------------------------------------------------------- 0 recursive calls 4 db block gets 20 consistent gets 0 physical reads 0 redo size 235 bytes sent via SQL*Net to client 417 bytes received via SQL*Net from client 2 SQL*Net roundtrips to/from client 1 sorts (memory) 0 sorts (disk) 1 rows processed (u menia net indexa na run_sw). Eshe raz. (*), (1), (8), (6)...etc - eto uslovnie znachki dla count na vse zapisi. count(cust_id), count(case_id_nmbr), count(name) etc - 'to count na spetseficheskie kolonki. Vi pitaetes' sravnivat' yabloki s apel'sinami. Ya sravnivau yabloki s yablokami. ... |
|||
:
Нравится:
Не нравится:
|
|||
20.07.2004, 00:50 |
|
Почему так медленно SELECT COUNT(*)
|
|||
---|---|---|---|
#18+
сижу, меряю, пока все одинаково , в рамках погрешности дла рабочего сервера! ... |
|||
:
Нравится:
Не нравится:
|
|||
20.07.2004, 09:44 |
|
Почему так медленно SELECT COUNT(*)
|
|||
---|---|---|---|
#18+
Калинасижу, меряю, пока все одинаково , в рамках погрешности дла рабочего сервера!Вы tkprof'ом сравните: что там различается? Сторонники count(1)/count(rowid) говорят, что в этом случае должно быть меньше рекурсивных вызовов, нежели при использовании count(*) Еще интересно было бы узнать, сколько времени (в процентном отношении) тратиться на рекурсивные вызовы и разбор в целом. ... |
|||
:
Нравится:
Не нравится:
|
|||
20.07.2004, 09:56 |
|
Почему так медленно SELECT COUNT(*)
|
|||
---|---|---|---|
#18+
B.Alexander Dubrovsky, prostite chto pishu latinitsei - ya na rabote. Text -AskTom, Vi eto chitali. Plus moi opit s Oracle. (*) ili (1), or (8), ili chto ugodno - ne immet znachenia. Ne zabivaite, chto kogda vi v sessii SELECT count(*) pervyi raz eto vsegda dol'she chem vo 2-i ili v 3-i: SQL> Я это знаю. И для достоверности я выполнял каждый оператор по несколько раз подряд. ... |
|||
:
Нравится:
Не нравится:
|
|||
20.07.2004, 10:00 |
|
Почему так медленно SELECT COUNT(*)
|
|||
---|---|---|---|
#18+
olekСторонники count(1)/count(rowid) говорят, что в этом случае должно быть меньше рекурсивных вызовов, нежели при использовании count(*) Кому должно? Первый рекурсивный вызов что в случае count(1), что в случае count(*) - поиск not null индекса по этой таблице. И если такой есть - никаких других уже не нужно. А такой как правило есть. ... |
|||
:
Нравится:
Не нравится:
|
|||
20.07.2004, 10:55 |
|
Почему так медленно SELECT COUNT(*)
|
|||
---|---|---|---|
#18+
2 B. Извините, но мне показалось что фразой "(*) ili (1), or (8), ili chto ugodno - ne immet znachenia." вы пытались сказать что не имеет значение что стоит в count. Я показал что изменения столбцов в count меняет план с FTS на FFS, если есть PK и используется CBO. Если же вы пытались сказать что не имеет значения между * и литералом, то прошу прощения. Успехов. ... |
|||
:
Нравится:
Не нравится:
|
|||
20.07.2004, 11:07 |
|
Почему так медленно SELECT COUNT(*)
|
|||
---|---|---|---|
#18+
softwarerВот сцылка на "обоснование" преимуществ count(1)/count(rowid). Источник - (известная) книшка "Подготовка сертифицированных дба" (по тынцу - цитата из оригинального англоязычного издания). Ваше мнение? зы. я мнение автора книшки считаю не обоснованным. ... |
|||
:
Нравится:
Не нравится:
|
|||
20.07.2004, 11:09 |
|
Почему так медленно SELECT COUNT(*)
|
|||
---|---|---|---|
#18+
olekВаше мнение? Обоснованием могут быть trace-ы применительно к конкретной версии Oracle либо аналогичные данные. Необходимости разрешать звездочку по словарю данных я не вижу, то есть это место, которое может быть оптимизировано. Насколько я помню, в документации по восьмерке утверждалось, что писать count(*) больше незачем. А ораклоидам я склонен верить до тех пор, пока явно не убеждаюсь в обратном. Сейчас я сделал на 9.0.2 trace для select count(*). Запроса, который искал бы поля, я в файле не вижу. Объективности ради - запроса, который искал бы индекс тоже не вижу ;-) ... |
|||
:
Нравится:
Не нравится:
|
|||
20.07.2004, 11:55 |
|
Почему так медленно SELECT COUNT(*)
|
|||
---|---|---|---|
#18+
B.Eshe raz. (*), (1), (8), (6)...etc - eto uslovnie znachki dla count na vse zapisi... Не сходить ли почитать документацию? ... |
|||
:
Нравится:
Не нравится:
|
|||
20.07.2004, 12:14 |
|
Почему так медленно SELECT COUNT(*)
|
|||
---|---|---|---|
#18+
2 softwarer смотреть не sql трейс надо для того чтобы увидеть как селекается какой либо индекс . только CBO может использовать FFS поэтому и трассируй CBO alter session set events='10053 trace name context forever, level 1' и в трайсе будет видно какой CBO выбрал путь : индексный или FTS Успехов. ... |
|||
:
Нравится:
Не нравится:
|
|||
20.07.2004, 12:29 |
|
Почему так медленно SELECT COUNT(*)
|
|||
---|---|---|---|
#18+
Oracle newbieи в трайсе будет видно какой CBO выбрал путь : индексный или FTS Не. План запроса select count(*) и так виден :-) Вопрос был в том, какие рекурсивные запросы выполняются при этом - то есть не заставляет ли count(*) делать дополнительный ненужный select from col$. trace, который я снял, не дает однозначного ответа на этот вопрос. ... |
|||
:
Нравится:
Не нравится:
|
|||
20.07.2004, 12:54 |
|
Почему так медленно SELECT COUNT(*)
|
|||
---|---|---|---|
#18+
softwarer Oracle newbieи в трайсе будет видно какой CBO выбрал путь : индексный или FTS Не. План запроса select count(*) и так виден :-) Вопрос был в том, какие рекурсивные запросы выполняются при этом - то есть не заставляет ли count(*) делать дополнительный ненужный select from col$. trace, который я снял, не дает однозначного ответа на этот вопрос. Пришел мужик в секс-шоп купить надувную бабу. Продавец подобрал ему самую навороченную: из латекса, девственница с вибратором, в общем - полный фарш. Ушел мужик довольный. На следующий день приносит: - вот чек, упаковка примите назад - а что внешность не нравится? - да нет, очень нравится - девственница? - да - ну а в чем тогда дело? - НЕ ДАЛА! Честно, я не издеваюсь, просто я не понимаю, как можно там не найти однозначного ответа. В чем у тебя проблема? Fucker ... |
|||
:
Нравится:
Не нравится:
|
|||
20.07.2004, 16:20 |
|
Почему так медленно SELECT COUNT(*)
|
|||
---|---|---|---|
#18+
FuckerЧестно, я не издеваюсь, просто я не понимаю, как можно там не найти однозначного ответа. Хм. Мне удалось :-) FuckerВ чем у тебя проблема? Хм. При просмотре трейса я не нашел ни запроса, которым Oracle просматривал бы поля таблицы, ни запроса, которым он получил бы индекс, который можно использовать для ffs. Трейс приведу, буду признателен, если ткнете пальцем. Собственно, рекурсивный запрос там только один, для чего он нужен, я не слишком понимаю, и на основании чего оракл в итоге получил план - тоже. Код: 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.
... |
|||
:
Нравится:
Не нравится:
|
|||
20.07.2004, 16:56 |
|
Почему так медленно SELECT COUNT(*)
|
|||
---|---|---|---|
#18+
после того, как мне попался этот форум, утром на работу стало приходить ужасно интересно - открываешь форум и читаешь какие-то вопли в свой адрес. причем вопли очень "профессиональные". у вас проблемы? может, конечно, я просто не понимаю специфику росийского оракловского "community", которое иногда сильно смахивает на базар. еще раз. Direct-Path INSERT: http://download-west.oracle.com/docs/cd/B10501_01/server.920/a96524/c21dlins.htm#10629 LMT: http://asktom.oracle.com/pls/ask/f?p=4950:8:::::F4950_P8_DISPLAYID:733126913855 интересно было бы услышать от вас что-нибудь по существу ... |
|||
:
Нравится:
Не нравится:
|
|||
20.07.2004, 19:58 |
|
Почему так медленно SELECT COUNT(*)
|
|||
---|---|---|---|
#18+
softwarer FuckerЧестно, я не издеваюсь, просто я не понимаю, как можно там не найти однозначного ответа. Хм. Мне удалось :-) FuckerВ чем у тебя проблема? Хм. При просмотре трейса я не нашел ни запроса, которым Oracle просматривал бы поля таблицы, ни запроса, которым он получил бы индекс, который можно использовать для ffs. Трейс приведу, буду признателен, если ткнете пальцем. Собственно, рекурсивный запрос там только один, для чего он нужен, я не слишком понимаю, и на основании чего оракл в итоге получил план - тоже. Скорее всего это какой-то левый трейс другой сессии. Ведь каждое окошко PL/SQL Developer может работать в своей сессии. Такие эксперименты лучше делать человеческими инструментами, то бишь SQL*Plus'ом. Тем более, что он генерирует гораздо меньше "всякой левизны", затрудняющей анализ. Я не буду приводить целиком свой трейс, но вот несколько ключевых фрагментов с рекурсивными вызовами: Код: 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.
В таких случаях имеет смысл выдавать кроме всего прочего bind value, которые позволят получить те же результаты, что получил Oracle при выполнении тестов. Fucker ... |
|||
:
Нравится:
Не нравится:
|
|||
20.07.2004, 20:20 |
|
Почему так медленно SELECT COUNT(*)
|
|||
---|---|---|---|
#18+
FuckerСкорее всего это какой-то левый трейс другой сессии. Обижаете :-) Собственно, я открыл новую сессию и выполнил там три оператора, которые и есть в трейсе - alter session set sql_trace = true select count(*) from gkhstar.fc_payments alter session set sql_trace = false Остальное - обрамление, добавляемое девелопером (transaction_id и select 'x' from dual). FuckerТакие эксперименты лучше делать человеческими инструментами, то бишь SQL*Plus'ом. Тем более, что он генерирует гораздо меньше "всякой левизны", затрудняющей анализ. Хм. Не забывайте, что я делал это для себя - не предполагая публиковать трейс. Что было открыто - в том и делал. FuckerЯ не буду приводить целиком свой трейс, но вот несколько ключевых фрагментов с рекурсивными вызовами: В общем, мне надо углубляться в настройку вывода трейсов. ... |
|||
:
Нравится:
Не нравится:
|
|||
21.07.2004, 12:51 |
|
Почему так медленно SELECT COUNT(*)
|
|||
---|---|---|---|
#18+
B.после того, как мне попался этот форум, утром на работу стало приходить ужасно интересно - открываешь форум и читаешь какие-то вопли в свой адрес. причем вопли очень "профессиональные". у вас проблемы? может, конечно, я просто не понимаю специфику росийского оракловского "community", которое иногда сильно смахивает на базар. еще раз. Direct-Path INSERT: http://download-west.oracle.com/docs/cd/B10501_01/server.920/a96524/c21dlins.htm#10629 LMT: http://asktom.oracle.com/pls/ask/f?p=4950:8:::::F4950_P8_DISPLAYID:733126913855 интересно было бы услышать от вас что-нибудь по существу По существу: Каким боком к обсуждаемой здесь теме - select count(*)/count(1) - относятся эти ссылки? Причем здесь direct-path insert и LMT? В.(*) ili (1), or (8), ili chto ugodno - ne immet znachenia. В.(*), (1), (8), (6)...etc - eto uslovnie znachki dla count na vse zapisi... http://download-west.oracle.com/docs/cd/B10501_01/server.920/a96540/functions26a.htm#82699 Это не "значки", а выражения. Осторожней, пожалуйста, с советами, особенно категоричными. P.S. Я никогда не считал, что в последних версиях Oracle count(1) быстрее count(*), поэтому данный вопрос не обсуждаю. Каждый (как мне наивно кажется) способен проверить этот факт. ... |
|||
:
Нравится:
Не нравится:
|
|||
21.07.2004, 13:23 |
|
Почему так медленно SELECT COUNT(*)
|
|||
---|---|---|---|
#18+
Марленков, никаким! Это надо было мне запостить туда, где про RBS и где какие-то факеры почему-то вопят ужасно, словно я у них последний кусок хлеба изо рта вырываю... - кошмар, одной рукой делаю одно, другой другое, а сейчас вот убегаю на работу. Sorry за накладку. ... |
|||
:
Нравится:
Не нравится:
|
|||
21.07.2004, 16:56 |
|
Почему так медленно SELECT COUNT(*)
|
|||
---|---|---|---|
#18+
OffTopic: Кайт Юлий Цезарь ... |
|||
:
Нравится:
Не нравится:
|
|||
22.07.2004, 08:11 |
|
Почему так медленно SELECT COUNT(*)
|
|||
---|---|---|---|
#18+
собери статистику по таблице, будет быстрее работать ... |
|||
:
Нравится:
Не нравится:
|
|||
22.07.2004, 09:55 |
|
Почему так медленно SELECT COUNT(*)
|
|||
---|---|---|---|
#18+
момент 1 если нет PK -- то FULL TABLE SCAN от сбора статистики не работает быстрее. момент 2 . Если же PK есть то для использования FFS по PK нужно сделать так, чтобы работал CBO . Для этого необязательно собирать статистику, можно указать optimizer_goal для сессии или хинт указывающий optimizer approach (FIRST_ROWS,ALL_ROWS) Regards. ... |
|||
:
Нравится:
Не нравится:
|
|||
22.07.2004, 10:25 |
|
Почему так медленно SELECT COUNT(*)
|
|||
---|---|---|---|
#18+
Oracle newbieмомент 1 если нет PK -- то FULL TABLE SCAN от сбора статистики не работает быстрее. Regards. Необязательно PK, достаточно просто индекса по not null полю. Код: 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.
... |
|||
:
Нравится:
Не нравится:
|
|||
22.07.2004, 10:50 |
|
Почему так медленно SELECT COUNT(*)
|
|||
---|---|---|---|
#18+
Да, о NOT NULL я и не подумал. ... |
|||
:
Нравится:
Не нравится:
|
|||
22.07.2004, 11:04 |
|
Почему так медленно SELECT COUNT(*)
|
|||
---|---|---|---|
#18+
В.Марленков, никаким! Это надо было мне запостить туда, где про RBS и где какие-то факеры почему-то вопят ужасно, словно я у них последний кусок хлеба изо рта вырываю... - кошмар, одной рукой делаю одно, другой другое, а сейчас вот убегаю на работу. Sorry за накладку. А второй рукой ты этот последний кусок к себе в рот запихиваешь? Я его достаточно хорошо разжевал? Ты бы попросил, я б тебе купил пирожок (с котятами), а то бедняжка... голодный... на работу... бегом.... Fucker ... |
|||
:
Нравится:
Не нравится:
|
|||
22.07.2004, 11:11 |
|
Почему так медленно SELECT COUNT(*)
|
|||
---|---|---|---|
#18+
2 Fucker Я все понял! Понял! Понял! Fucker - американский зас л анец, посланый для развала оборонной мощи России ;-) ... |
|||
:
Нравится:
Не нравится:
|
|||
22.07.2004, 11:36 |
|
Почему так медленно SELECT COUNT(*)
|
|||
---|---|---|---|
#18+
Markelenkov2 Fucker Я все понял! Понял! Понял! Fucker - американский зас л анец, посланый для развала оборонной мощи России ;-) Вы меня обижаете ;-), в свое время я тоже немало сделал для укрепления этой самой мощи. А по поводу имени, ну что я могу сказать? Fucker - это ведь не только "распутник", "негодяй", "прохвост", "хрен", "говнюк", "дурачок" и "ёб%рь" но и "друг", "чувак", "мужик" и даже "красавец" Так что, наверно таким я и останусь. Ну, предположим, выберу я себе другое имя, а завтра оно еще кому-то не понравится... Видно так и помирать мне Fucker\'ом... Fucker PS.: И появится тогда killed Fucker ;-) ... |
|||
:
Нравится:
Не нравится:
|
|||
22.07.2004, 12:29 |
|
Почему так медленно SELECT COUNT(*)
|
|||
---|---|---|---|
#18+
Кстати, Пинк свою собачку так же назвала. Говорит, буду лежать на пляжу и звать: Hey, Fucker! Fucker!, все мужчины будут оборачиваться, а я им: Да не ты! Не ты! ... |
|||
:
Нравится:
Не нравится:
|
|||
22.07.2004, 12:37 |
|
Почему так медленно SELECT COUNT(*)
|
|||
---|---|---|---|
#18+
Fucker Markelenkov2 Fucker Я все понял! Понял! Понял! Fucker - американский зас л анец, посланый для развала оборонной мощи России ;-) Вы меня обижаете ;-), в свое время я тоже немало сделал для укрепления этой самой мощи. А по поводу имени, ну что я могу сказать? Fucker - это ведь не только "распутник", "негодяй", "прохвост", "хрен", "говнюк", "дурачок" и "ёб%рь" но и "друг", "чувак", "мужик" и даже "красавец" Так что, наверно таким я и останусь. Ну, предположим, выберу я себе другое имя, а завтра оно еще кому-то не понравится... Видно так и помирать мне Fucker\'ом... Fucker PS.: И появится тогда killed Fucker ;-) Имя-то мне нравицца ;-) Подпись - не нравицца. Лучше подписываться типа Fucker, 30306 Искать по форуму станет удобно, оборонная мощь государства укрепится ;-) ... |
|||
:
Нравится:
Не нравится:
|
|||
22.07.2004, 12:37 |
|
Почему так медленно SELECT COUNT(*)
|
|||
---|---|---|---|
#18+
по моему в молоко. Совсем разные стили ... |
|||
:
Нравится:
Не нравится:
|
|||
22.07.2004, 13:00 |
|
Почему так медленно SELECT COUNT(*)
|
|||
---|---|---|---|
#18+
MarkelenkovИмя-то мне нравицца ;-) Подпись - не нравицца. Лучше подписываться типа Fucker, 30306 А так низззя, это чужой номер. Нельзя обижать товарищей ;-) Fucker PS.: Это уже наверно третья попытка "снять маски". Как нас можно спутать, не понимаю, мы ведь совсем непохожи. Он усатый с щечками, а я свои усы уже лет десять как сбрил. И, кстати, 30306 оборонную мощь России не укреплял PPS.: Вот и killed подтверждает ;-) ... |
|||
:
Нравится:
Не нравится:
|
|||
22.07.2004, 14:23 |
|
Почему так медленно SELECT COUNT(*)
|
|||
---|---|---|---|
#18+
зато я укреплял красную кнопку целых секунды три держал ... |
|||
:
Нравится:
Не нравится:
|
|||
22.07.2004, 16:08 |
|
Почему так медленно SELECT COUNT(*)
|
|||
---|---|---|---|
#18+
FuckerА так низззя, это чужой номер. Нельзя обижать товарищей ;-) Ладно, не добиться мине щастья, не уговорить ;-) Бум обходиться без поиска... ... |
|||
:
Нравится:
Не нравится:
|
|||
22.07.2004, 16:20 |
|
Почему так медленно SELECT COUNT(*)
|
|||
---|---|---|---|
#18+
Fucker - это ведь не только "распутник", "негодяй", "прохвост", "хрен", "говнюк", "дурачок" и "ёбрь" но и "друг", "чувак", "мужик" и даже "красавец" Тут я уже не могу молчать, потому что ладно еще, когда ты ржал над тривиальными и вполне известными вещами (я уверена, что ты умный человек, любящий свою профессию и свои "skills" ты разовьешь), но ты затронул язык, а язык это святое. Я не знаю, кто тебе сказал, что твое имя Fucker имеет все эти значения, но они сказали тебе неправду, не верь им, потому что из перечисленных тобою значений Fucker имеет лишь два и они суть "ёбрь" и "говнюк" Если ты мне как обычно не веришь зайди вот сюда и проверь: http://dictionary.reference.com/ Можешь также сходить на сайт Oxford, у меня сейчас нет времени тебе искать этот сайт, сам найдешь. Ну ладно, побежала я опять на работу. Не обижайся, ладно? Всего тебе самого доброго. ... |
|||
:
Нравится:
Не нравится:
|
|||
22.07.2004, 18:39 |
|
Почему так медленно SELECT COUNT(*)
|
|||
---|---|---|---|
#18+
а по русски, "еб%рь" вполне может быть и "красавцем" . Хотя кто поймет этих женщин? Regards. ... |
|||
:
Нравится:
Не нравится:
|
|||
22.07.2004, 18:46 |
|
Почему так медленно SELECT COUNT(*)
|
|||
---|---|---|---|
#18+
B.Fucker - это ведь не только "распутник", "негодяй", "прохвост", "хрен", "говнюк", "дурачок" и "ёбрь" но и "друг", "чувак", "мужик" и даже "красавец" Тут я уже не могу молчать, потому что ладно еще, когда ты ржал над тривиальными и вполне известными вещами (я уверена, что ты умный человек, любящий свою профессию и свои "skills" ты разовьешь), но ты затронул язык, а язык это святое. Я не знаю, кто тебе сказал, что твое имя Fucker имеет все эти значения, но они сказали тебе неправду, не верь им, потому что из перечисленных тобою значений Fucker имеет лишь два и они суть "ёбрь" и "говнюк" Если ты мне как обычно не веришь зайди вот сюда и проверь: http://dictionary.reference.com/ Можешь также сходить на сайт Oxford, у меня сейчас нет времени тебе искать этот сайт, сам найдешь. Ну ладно, побежала я опять на работу. Не обижайся, ладно? Всего тебе самого доброго. Оказывается, В. - дама :-O Учтем-с, бум помяхше, потоньше, повежливше... P.S. Есть женщины в американских селеньях... Гы-ы-ы-ы ... |
|||
:
Нравится:
Не нравится:
|
|||
22.07.2004, 19:30 |
|
Почему так медленно SELECT COUNT(*)
|
|||
---|---|---|---|
#18+
B.Fucker - это ведь не только "распутник", "негодяй", "прохвост", "хрен", "говнюк", "дурачок" и "ёбрь" но и "друг", "чувак", "мужик" и даже "красавец" Тут я уже не могу молчать, потому что ладно еще, когда ты ржал над тривиальными и вполне известными вещами (я уверена, что ты умный человек, любящий свою профессию и свои "skills" ты разовьешь), но ты затронул язык, а язык это святое. Я не знаю, кто тебе сказал, что твое имя Fucker имеет все эти значения, но они сказали тебе неправду, не верь им, потому что из перечисленных тобою значений Fucker имеет лишь два и они суть "ёбрь" и "говнюк" Если ты мне как обычно не веришь зайди вот сюда и проверь: http://dictionary.reference.com/ Можешь также сходить на сайт Oxford, у меня сейчас нет времени тебе искать этот сайт, сам найдешь. Ну ладно, побежала я опять на работу. Не обижайся, ладно? Всего тебе самого доброго. Спасибо за пожелания, а на что мне обижаться? Я общался с существом, которое, как я предполагал, "остроконечного пола" (классическая фраза Бориса Виана), а после общения выснилось, что это не так. Одно из двух: - либо оно тщательно маскировалось, используя лингвистические уловки, не позволяющие определить пол собеседника; - либо оно решило изменить пол после очередного общения с Fucker'ом. 8-))) Мои "skills" и не только "skills" я и так постоянно развиваю. В одном из постов, обращенных мне, как-то прозвучало пожелание прочитать книги Т. Кайта и Oracle'вую документацию. Сейчас я все-таки решил сказать пару слов по этому поовду... Я не строю из себя супер-муперного крутого спеца во всем, что связано с Oracle. Я такой, какой я есть, что-то я знаю лучше, что-то хуже, но мои познания в некоторых основных областях позволяют мне без всяких проблем находить десятками недочеты и ошибки как в книгах об Oracle (у того же Тома, хотя уровень его книг на порядок выше всех остальных, с которыми я сталкивался, ошибок значительно меньше, нежели у других, но они все равно есть), так и в стандартной документации. В основном это связано с тем, что при переходе от версии к версии Oracle документацию как обычно оставляют "на потом". Иногда связано с умышленными (но не совсем корректными) попытками скрытия деталей функционирования Oracle... и т.д. и т.п. И в каждом из таких случаев я безо всяких проблем фактами и экспериментами доказать свою правоту. Было бы время... Так вот мне стало интересно, из чего конкретно вытекает такой вывод, что мне стоит почитать эти источники? Буду очень признателен, если получу точный, формальный ответ. Желательно без лишней пространной болтовни на тему космических кораблей, бороздящих просторы.... Fucker ... |
|||
:
Нравится:
Не нравится:
|
|||
22.07.2004, 21:04 |
|
Почему так медленно SELECT COUNT(*)
|
|||
---|---|---|---|
#18+
Спасибо за пожелания, а на что мне обижаться? Я общался с существом, которое, как я предполагал, "остроконечного пола" (классическая фраза Бориса Виана), а после общения выснилось, что это не так. Одно из двух: - либо оно тщательно маскировалось, используя лингвистические уловки, не позволяющие определить пол собеседника; - либо оно решило изменить пол после очередного общения с Fucker'ом. 8-))) Мои "skills" и не только "skills" я и так постоянно развиваю. В одном из постов, обращенных мне, как-то прозвучало пожелание прочитать книги Т. Кайта и Oracle'вую документацию. Сейчас я все-таки решил сказать пару слов по этому поовду... Я не строю из себя супер-муперного крутого спеца во всем, что связано с Oracle. Я такой, какой я есть, что-то я знаю лучше, что-то хуже, но мои познания в некоторых основных областях позволяют мне без всяких проблем находить десятками недочеты и ошибки как в книгах об Oracle (у того же Тома, хотя уровень его книг на порядок выше всех остальных, с которыми я сталкивался, ошибок значительно меньше, нежели у других, но они все равно есть), так и в стандартной документации. В основном это связано с тем, что при переходе от версии к версии Oracle документацию как обычно оставляют "на потом". Иногда связано с умышленными (но не совсем корректными) попытками скрытия деталей функционирования Oracle... и т.д. и т.п. И в каждом из таких случаев я безо всяких проблем фактами и экспериментами доказать свою правоту. Было бы время... Так вот мне стало интересно, из чего конкретно вытекает такой вывод, что мне стоит почитать эти источники? Буду очень признателен, если получу точный, формальный ответ. Желательно без лишней пространной болтовни на тему космических кораблей, бороздящих просторы.... Fucker, prosti, ti vse zhe nemnogo obidelsa. Vo-pervih, ya deistvitel'no soznatel'no "maskirovala" pol potomu chto mne kazalos' (i ya bila neprava v ETOM sluchae), chto russkie muzhiki k zhenshinam otnosatsa magko govora snishoditel'no. Potom mne stalo plevat' kak oni k nim otnosatsa. Vo-vtorih, ya uverena, chto ochen' mnogie veshi ti znaesh' gorazdo lutshe mena i voobshe ti gorazdo lutshe mena v tom, chto kasaetsa database, potomu chto ti DBA, a ya net, hota i staraus' uznavat' i ponimat' kak mozhno bol'she - chitau, bivau na konferentsiah, prosmatrivau forumi i posil'no staraus' reshat' tam raznie problemi, chitau vse s AskTom, experementiruu etc. Ya seichas ne mogu iskat' i razbirat' tvoi proshlie postingi naschet mena. No skazhu tebe takuu vesh. Vse, chto ya napisala po povodu LMT i pr. iz moei real'noi zhizni. Mne prihodilos' tunit' raznie applications i ya delala eto khorosho. Naprimer, na odnom proekte procedure ranilas' 40-45 chasov. Ya perepisala code i ona stala ranitsa 2 chasa. No tam vrema ot vremeni bili RBS problemi. Ya zastavila DBA (indusa, a on soprotivlalsa) pereiti na LMT i sdelat' eshe koe kakie veshi. Teper' etot code rabotaet 40 minut i nikakih problem s RBS, chto yavlaetsa sledstviem LMT (ya davala snosku ob etom). Esli ti chital (a ya znau, chto ti chital) eti knogi, obrati vnimamie na LMT. Povtorau, ne obizhaisa. Ya tozhe chitala i prodolzhau chitat' i perechitivat'. A mne interesno vot chto. Ti skazal, chto u Toma "ошибок значительно меньше, нежели у других, но они все равно есть". Esli est' ili budet vrema ne mog bi ti dat' primeri? ... |
|||
:
Нравится:
Не нравится:
|
|||
22.07.2004, 21:36 |
|
Почему так медленно SELECT COUNT(*)
|
|||
---|---|---|---|
#18+
B.Vse, chto ya napisala po povodu LMT i pr. iz moei real'noi zhizni. Mne prihodilos' tunit' raznie applications i ya delala eto khorosho. Naprimer, na odnom proekte procedure ranilas' 40-45 chasov. Ya perepisala code i ona stala ranitsa 2 chasa. No tam vrema ot vremeni bili RBS problemi. Ya zastavila DBA (indusa, a on soprotivlalsa) pereiti na LMT i sdelat' eshe koe kakie veshi. Teper' etot code rabotaet 40 minut i nikakih problem s RBS, chto yavlaetsa sledstviem LMT (ya davala snosku ob etom). Esli ti chital (a ya znau, chto ti chital) eti knogi, obrati vnimamie na LMT. Povtorau, ne obizhaisa. Ya tozhe chitala i prodolzhau chitat' i perechitivat'. A mne interesno vot chto. Ti skazal, chto u Toma "ошибок значительно меньше, нежели у других, но они все равно есть". Esli est' ili budet vrema ne mog bi ti dat' primeri? По поводу lmt & undo Так уж получилось, что как раз к этому пункту у меня было меньше всего претензий, ну да ладно... Я согласен с тем, что от перехода на lmt можно получить определенное увеличение производительности приложений. В процитированное вами статье было указано 6 преимуществ, получаемых от использования lmt. И преимущество №3 «No Rollback generated» не сможет решить всех проблем, если системой уже генерируется слишком много undo. В какой-то мере сократить, да, сократит, но, как я уже говорил, кардинально оно не решает все проблемы с undo . Ведь это всего-лишь пассивная попытка борьбы с симптомом, а не с самой болезнью. Наибольший выигрыш от влияния этого фактора обычно получается в самых «запущенных» случаях. Например, используются слишком маленькие экстенты и приложение делает много лишних операций изменения данных, приводящих с частым space transactions, или часто выполняется откат транзакций. Но и в этом случае переход на lmt не решит основных проблем, связанных с неэффективностью самого приложения. В таких случаях помимо перехода на lmt, если есть возможность, стоит пересмотреть дизайн приложения. В то же время, если табличные пространства и пользовательские объекты в них созданы с разумными параметрами хранения, выполняется эффективное приложение и undo не являются узким местом системы, то даже на dmt можно обеспечить высокую его производительность. Лично я ничего не имею против lmt, тем более, я сам давно использую его в работе. Простите за излишнюю резкость, допущенную во время общения с вами. Возможно я просто не люблю слишком пространных универсальных советов на все случаи жизни. ;-) Best Regards, Fucker, который не "говнюк" PS.: По поводу «чужих ошибок». Завтра, послезавтра постараюсь перечитать несколько глав и привести несколько примеров. Первый будет связан с использованием утилиты экспорт. ... |
|||
:
Нравится:
Не нравится:
|
|||
23.07.2004, 16:08 |
|
Почему так медленно SELECT COUNT(*)
|
|||
---|---|---|---|
#18+
2 В. Не могу похвастаться, что нахожу десятками ошибки у Тома (его сайт, кстати, редко читаю), но единичные случаи есть. Часть из них скорее всего связана с описками и опечатками, часть - с нежеланием углубляться в дебри и т.д. Ошибаются все, и это нормально. ... |
|||
:
Нравится:
Не нравится:
|
|||
23.07.2004, 17:32 |
|
Почему так медленно SELECT COUNT(*)
|
|||
---|---|---|---|
#18+
Спасибо за объяснения. Я начинаю потихоньку разбиратьтся с переводной терминологией, а то вначале очень трудно было понимать, о чем идет речь. Вообще мне нравится этот форум. Наши раньше тоже были ничего ничего , особенно этот: http://www.orafaq.com/msgboard/index.htm, но сейчас все меньше и меньше интересных вопросов. То ли все все поняли, то ли Оракл действительно на спад идет (надеюсь, что нет). В день появляется всего несколько вопросов, из которых редко бывают интересные. А здесь интересно. Вот это у меня не открывается, вылезает что-то другое: http://www.sql.ru/images/laugh.gif Попробую на работе открыть. Завтра, послезавтра постараюсь перечитать несколько глав и привести несколько примеров. Первый будет связан с использованием утилиты экспорт.[/quot] Если завтра у нас не будет дождя, который обещают, то я уеду на выходные за город, поэтому очень прошу на всякий случай или не публиковать это до понедельника, или в понедельник освежить, а то все затеряется. Всего доброго, В. ... |
|||
:
Нравится:
Не нравится:
|
|||
23.07.2004, 18:01 |
|
Почему так медленно SELECT COUNT(*)
|
|||
---|---|---|---|
#18+
Markelenkov2 В. Не могу похвастаться, что нахожу десятками ошибки у Тома (его сайт, кстати, редко читаю), но единичные случаи есть. Часть из них скорее всего связана с описками и опечатками, часть - с нежеланием углубляться в дебри и т.д. Ошибаются все, и это нормально. Поскольку я не DBA, то могу лишь сказать, что Том иногда "ошибается" в каком-нибудь маленьком синтаксисе, поскольку он все пишет на ходу, но обычно он быстренько делает Oops! И поправляется. Ну и помню как-то раз он очень красиво "перегнул" - написал как узнавать, есть ли запись в таблице без дорогого SELECT count(*), используя модель WHERE EXISTS(SELECT NULL FROM dual WHERE ...). Красиво, повторяю, получилось, но когда я его спросила на конференции не тот же самый результат в смысле "дороговизны" и скорости если SELECT count(*)....WHERE rownum<2, он засмеялся и сказал, что это то же самое. А вообще-то он гений. А какие ошибки вы заметили? ... |
|||
:
Нравится:
Не нравится:
|
|||
23.07.2004, 18:18 |
|
Почему так медленно SELECT COUNT(*)
|
|||
---|---|---|---|
#18+
В.А вообще-то он гений. Ну это уж чересчур! Он, конечно, гуру, но не гений, imho. Уверяю Вас, например, если бы у многих из тусующихся на этом форуме была возможность заниматься СУБД и Oracle в частности столько времени, сколько у Тома, да плюс его возможности, связанные с приближенностью к Oracle Corp. и прочие его преимущества, связанные с языком, страной проживания и т.д - думаю, конкуренцию Тому могли бы составить многие. В силу объективных обстоятельств мы поставлены в гораздо менее выгодные условия, чем тот же Том. В.А какие ошибки вы заметили? Я их не запоминаю. Например, помню, что в его книге (в русском переводе) "Expert One-on-One Oracle" он пишет, что размер ITL в блоке 23 байта. Страницу назвать по памяти не могу, искать лень (в русском переводе книга разбита на 2 тома). Помню это потому, что проверял. Может быть, опечатка. Видел это же число еще у нескольких авторов - гипноз? Дампы блоков и, например, Стив Адамс здесь и здесь с Кайтом не согласны. Кстати, Адамс на мой взгляд , будет покруче Кайта и я ему верю больше. При этом он, кстати, никогда не работал в Oracle Corp. Поэтому Адамс поближе к гениальности, imho. Хотя тоже, бывает, ошибается ;-) ... |
|||
:
Нравится:
Не нравится:
|
|||
23.07.2004, 20:21 |
|
Почему так медленно SELECT COUNT(*)
|
|||
---|---|---|---|
#18+
23 байта - это стандартная цифра из документации. Думаю, Том не делал дампы, чтобы ее проверить. В любом случае, у них у всех есть свои выходы на Oracle Corp., поскольку многие вещи нельзя трактовать однозначно без того, чтобы подглядеть код. Успехов, DBGroup Consulting ... |
|||
:
Нравится:
Не нравится:
|
|||
23.07.2004, 21:11 |
|
Почему так медленно SELECT COUNT(*)
|
|||
---|---|---|---|
#18+
Markelenkov[quot В.]А вообще-то он гений. Ну это уж чересчур! Он, конечно, гуру, но не гений, imho. Уверяю Вас, например, если бы у многих из тусующихся на этом форуме была возможность заниматься СУБД и Oracle в частности столько времени, сколько у Тома, да плюс его возможности, связанные с приближенностью к Oracle Corp. и прочие его преимущества, связанные с языком, страной проживания и т.д - думаю, конкуренцию Тому могли бы составить многие. В силу объективных обстоятельств мы поставлены в гораздо менее выгодные условия, чем тот же Том. Я на 1000% согласна, что в России много умных людей (гораздо больше, чем в Штатах, уверяю вас!), но насчет Тома вы меня не переубедите. Прежде, чем стать тем, кто он стал, Том несколько лет помирал на скучнейшем проекте делая maintenance и сходя с ума от тоски. Тогда он стал сам все изучать, участвовать в форумах, решать проблемы. Потом он, благодаря своим талантам, получил те возможности, которые у него есть сейчас. Но вместо того, чтобы, получая свою колоссальную зарплату, сидеть где-нибудь на Гаваях или в собственном бассейне, попивая коктейль и по conference calls рассылая директивы своим подчиненным, он продолжает делать то, что любит и может делать - работает, пишет книжки, исследует возможности Оракла, пишет новые feutures для него, работает на проектах, делает доклады на конференциях и плюс - помогает сотням, если не тысячам людей, пытающимся решить ту или иную проблему. Никого не игнорирует. Я сама несколько раз задавала ему вопросы и всегда получала немедленные ответы, даже в выходные, даже если эти вопросы были глупыми. А пару раз я ему задала очень глупые вопросы. Знаете, как бывает. когда что-то не идет и ты все время тыкаешься в одну и ту же дверь, а потом вдруг до тебя доходит как это сделать. Пару раз, повторяю, я его спросила что-то очень глупое (и тут же до меня дошло и мне стало стыдно, что я спросила), и он не посмеялся, не "послал", а нормально все объяснил, как он объясняет КАЖДОМУ, обращающемуся к нему. И ведь при этом у него жена и двое детей. А какие у него есть потрясающие решения! Как угодно, но я его считаю гением. Кстати, Адамс на мой взгляд , будет покруче Кайта и я ему верю больше. При этом он, кстати, никогда не работал в Oracle Corp. Стив Адамс тоже классный, но он, между прочим, консультирует за большие деньги. На одном из проектов, где я работала, к нему хотели обратиться, но оказалось, что это очень дорого и мой клиент отказался платить такие деньги. Между прочим, он и Том очень уважают друг друга. Вы говорите: "В силу объективных обстоятельств мы поставлены в гораздо менее выгодные условия, чем тот же Том". Что вы имеете в виду? Я так не думаю, потому что видя, как здесь в Штатах работают и как ценятся программисты, попадающие сюда из России, я думаю, что это совсем не так. У вас у всех потрясающее образование, причем бесплатное. Вы все на этом форуме, как я понимаю, имеете техническое образование, которое в России просто несравненно лучше, чем в Штатах (у меня тоже образование, но гуманитарное, и в Оракле я самоучка). У вас условия, когда вы должны из "г-на делать конфетку", изловчаться, приспосабливаться к тому, что есть. У вас отличные условия для развития. Всего вам доброго и хороших выходных. В. ... |
|||
:
Нравится:
Не нравится:
|
|||
24.07.2004, 06:32 |
|
Почему так медленно SELECT COUNT(*)
|
|||
---|---|---|---|
#18+
DBGroup Consulting23 байта - это стандартная цифра из документации. Думаю, Том не делал дампы, чтобы ее проверить. Я поискал в свое время эту цифру в документации (правда, только для версии 9.2), но нигде не нашел. Может быть, в более старых версиях об этом есть упоминание, я этого уже не помню. DBGroup ConsultingВ любом случае, у них у всех есть свои выходы на Oracle Corp., поскольку многие вещи нельзя трактовать однозначно без того, чтобы подглядеть код. У меня тоже сложилось такое же впечатление. ... |
|||
:
Нравится:
Не нравится:
|
|||
24.07.2004, 06:48 |
|
Почему так медленно SELECT COUNT(*)
|
|||
---|---|---|---|
#18+
В.Я на 1000% согласна, что в России много умных людей (гораздо больше, чем в Штатах, уверяю вас!), но насчет Тома вы меня не переубедите. А я и не ставлю целью кого-либо переубеждать. Просто я считаю, что Том - талант, но не гений ;-) Гении, на мой взгляд, - Бетховен, Пушкин, Эйнштейн, Ландау... Вот лет через 50-100 можно будет судить и о гениальности ныне живущих. В.Вы говорите: "В силу объективных обстоятельств мы поставлены в гораздо менее выгодные условия, чем тот же Том". Что вы имеете в виду? Я так не думаю, потому что видя, как здесь в Штатах работают и как ценятся программисты, попадающие сюда из России, я думаю, что это совсем не так. У вас у всех потрясающее образование, причем бесплатное. Вы все на этом форуме, как я понимаю, имеете техническое образование, которое в России просто несравненно лучше, чем в Штатах (у меня тоже образование, но гуманитарное, и в Оракле я самоучка). У вас условия, когда вы должны из "г-на делать конфетку", изловчаться, приспосабливаться к тому, что есть. У вас отличные условия для развития. На образование не жалуюсь, на кругозор тоже, на возраст - уже да ;-) Что я имею ввиду под объективными обстоятельствами? Например, наличие английского языка в качестве родного. Почти все общение в сфере IT идет на нем. Техническую литературу на английском я читаю в несколько раз медленнее, чем на русском. Прочую - на порядок и более. При этом не всегда понимаю на 100% смысл. Интернет на работе появился лет 5-6 назад, но доступ к нему весьма ограничен. Дома подключился меньше года назад - не все в Москве живут. Моей зарплаты недостаточно для оплаты посещений семинаров, курсов и т.д., покупки билетов на самолет, а предприятие за это не платит. Серьезной техники и серьезных задач под Oracle в России на порядки меньше, чем в тех же Штатах - страна бедная, ее жители тоже. Кроме Oracle приходится заниматься еще разными вещами - семью кормить-то надо? Лично у меня есть еще множество факторов, не способствующих повышению уровня моих знаний в Oracle, но это не суть важно. В.Всего вам доброго и хороших выходных. Спасибо, и Вам таких же вкусных шашлыков ;-) ... |
|||
:
Нравится:
Не нравится:
|
|||
24.07.2004, 07:10 |
|
Почему так медленно SELECT COUNT(*)
|
|||
---|---|---|---|
#18+
Markelenkov DBGroup Consulting23 байта - это стандартная цифра из документации. Думаю, Том не делал дампы, чтобы ее проверить. Я поискал в свое время эту цифру в документации (правда, только для версии 9.2), но нигде не нашел. Может быть, в более старых версиях об этом есть упоминание, я этого уже не помню. Oracle 9i Database Concepts Release 2 (9.2). Стр. 2-5 (или 119) в самом низу. ... |
|||
:
Нравится:
Не нравится:
|
|||
26.07.2004, 09:34 |
|
Почему так медленно SELECT COUNT(*)
|
|||
---|---|---|---|
#18+
2 Destroy Ага, спасибо, вижу. ... |
|||
:
Нравится:
Не нравится:
|
|||
26.07.2004, 14:18 |
|
Почему так медленно SELECT COUNT(*)
|
|||
---|---|---|---|
#18+
В.Вот это у меня не открывается, вылезает что-то другое: http://www.sql.ru/images/laugh.gif Надеюсь, что на сей раз вылезло то, что надо В. FuckerЗавтра, послезавтра постараюсь перечитать несколько глав и привести несколько примеров. Первый будет связан с использованием утилиты экспорт. Если завтра у нас не будет дождя, который обещают, то я уеду на выходные за город, поэтому очень прошу на всякий случай или не публиковать это до понедельника, или в понедельник освежить, а то все затеряется. В. автор Выявление повреждений Я использую утилиту EXP в качестве средства для выявления повреждений базы данных, физических или логических . Если с помощью утилиты EXP выполнить полное экспортирование базы данных, она проверит весь словарь данных и найдет в нем любую логическую несогласованность . Кроме того, она полностью просмотрит каждую таблицу в базе данных, читая все строки. Если имеется таблица со сбойным блоком, этот блок будет найден. Утилита не выявляет определенные типы логических повреждений, например индекс, указывающий на несуществующие строки, поскольку просматривает таблицы, но обнаружит наиболее существенные ошибки (индекс всегда можно пересоздать, а вот пересоздание таблицы иногда невозможно). Как разработчик, в некоторых отдельных случаях я мог бы воспользоваться утилитой exp с full=y для выявления повреждений прикладных данных. Но именно пользовательских данных, а не повреждений базы данных . Реально exp оставляет за бортом огромное количество различного рода «внутренних» повреждений базы данных (не буду сейчас в это углубляться, пока поверьте мне на слово, их огромное множество). То, что полный экспорт системы завершился без предупреждающих сообщений, еще не означает, что база данных находится в работоспособном состоянии. Это говорит только о том, что ваши данные пока еще доступны . Ну и кроме всего прочего, DBA обычно не раздает направо и налево exp_full_database. Особенно мне нравится, когда подобный экспорт часто идет в /dev/null Как DBA, я думаю, что утилита exp не самый подходящий инструмент для выявления повреждений базы данных. Это довольно медленное и ресурсоемкое решение, сильно осложняемое тем, что consistent=y иногда проблематично сделать на интенсивно обновляемых базах данных большого объема и вы в этом случае не застрахованы от ORA-01555, а consistent=n применим только к пассивно живущему трупу. Ну и наконец, самое главное - exp НЕ проверит весь словарь данных и НЕ найдет в нем любую логическую несогласованность . Утилита exp не экспортирует объекты словаря данных, принадлежащие пользователю sys. Да, экспорт при своей работе использует некоторую информацию из словаря данных, косвенно «проверяя» ее, вот и все. Это еще не говорит о целостности всего словаря. Справедливости ради отмечу, что существует довольно большое количество способов поиска поврежденных блоков. Если вы используете для резервирования RMAN, такие повреждения очень легко диагностируются в процессе копирования. Предохраняться надо ведь по любому, а диагностику ошибок вы получите в качестве бонуса. Можно использовать DBVERIFY, который умеет работать как с offline, так online файлами данных. Если у вас установлен db_block_checksum, то все дополнительные проверки теряют смысл, т.к. Oracle сам будет проверять целостность всех блоков. Правда платой за это может быть незначительное проседание в производительности. На уровне отдельных объектов можно использовать analyze table xyz validate structure cascade и dbms_repair… Fucker ... |
|||
:
Нравится:
Не нравится:
|
|||
27.07.2004, 10:26 |
|
Почему так медленно SELECT COUNT(*)
|
|||
---|---|---|---|
#18+
MarkelenkovЯ их не запоминаю. Например, помню, что в его книге (в русском переводе) "Expert One-on-One Oracle" он пишет, что размер ITL в блоке 23 байта. Страницу назвать по памяти не могу, искать лень (в русском переводе книга разбита на 2 тома). Помню это потому, что проверял. Может быть, опечатка. Видел это же число еще у нескольких авторов - гипноз? Кстати, Адамс на мой взгляд , будет покруче Кайта и я ему верю больше. При этом он, кстати, никогда не работал в Oracle Corp. Поэтому Адамс поближе к гениальности, imho. Хотя тоже, бывает, ошибается ;-) В качестве небольшой добавки к словам DBGroup Consulting: Справедливости ради все-таки стоит процитировать фрагмент документации http://download-west.oracle.com/docs/cd/B13789_01/server.101/b10743/logical.htm#sthref313 ConceptsIn data blocks allocated for the data segment of a table or cluster, or for the index segment of an index, free space can also hold transaction entries. A transaction entry is required in a block for each INSERT, UPDATE, DELETE, and SELECT...FOR UPDATE statement accessing one or more rows in the block. The space required for transaction entries is operating system dependent; however, transaction entries in most operating systems require approximately 23 bytes. Так что концепции честно признались, что это число приблизительное(approximately) и зависит от ОС. примерно 23 это ведь и 24 и 25, а может даже и 22 Fucker ... |
|||
:
Нравится:
Не нравится:
|
|||
27.07.2004, 14:30 |
|
Почему так медленно SELECT COUNT(*)
|
|||
---|---|---|---|
#18+
Так что концепции честно признались, что это число приблизительное(approximately) и зависит от ОС. примерно 23 это ведь и 24 и 25, а может даже и 22 В военное время значение числа Пи может достигать 4 или даже 5-ти! ... |
|||
:
Нравится:
Не нравится:
|
|||
27.07.2004, 16:28 |
|
Почему так медленно SELECT COUNT(*)
|
|||
---|---|---|---|
#18+
кстати rman тоже не все ловит. Повезло тут недавно убедится :)) ... |
|||
:
Нравится:
Не нравится:
|
|||
27.07.2004, 16:40 |
|
Почему так медленно SELECT COUNT(*)
|
|||
---|---|---|---|
#18+
FuckerЕсли у вас установлен db_block_checksum, то все дополнительные проверки теряют смысл, т.к. Oracle сам будет проверять целостность всех блоков Я бы не был так категоричен. Точнее, мне кажется, было бы сказать "всех читаемых и записываемых блоков во всех табличных пространствах". Для TS SYSTEM, как известно, это включено по умолчанию и регулируется другим параметром. Блок может уже давно скончаться, а Oracle узнает об этом только при его чтении :-( Fuckerпримерно 23 это ведь и 24 и 25, а может даже и 22 Хорошо, пусть будет ни вам, ни нам - 23.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
27.07.2004, 19:32 |
|
Почему так медленно SELECT COUNT(*)
|
|||
---|---|---|---|
#18+
Fucker В.Вот это у меня не открывается, вылезает что-то другое: http://www.sql.ru/images/laugh.gif Надеюсь, что на сей раз вылезло то, что надо В. FuckerЗавтра, послезавтра постараюсь перечитать несколько глав и привести несколько примеров. Первый будет связан с использованием утилиты экспорт. Если завтра у нас не будет дождя, который обещают, то я уеду на выходные за город, поэтому очень прошу на всякий случай или не публиковать это до понедельника, или в понедельник освежить, а то все затеряется. В. автор Выявление повреждений Я использую утилиту EXP в качестве средства для выявления повреждений базы данных, физических или логических . Если с помощью утилиты EXP выполнить полное экспортирование базы данных, она проверит весь словарь данных и найдет в нем любую логическую несогласованность . Кроме того, она полностью просмотрит каждую таблицу в базе данных, читая все строки. Если имеется таблица со сбойным блоком, этот блок будет найден. Утилита не выявляет определенные типы логических повреждений, например индекс, указывающий на несуществующие строки, поскольку просматривает таблицы, но обнаружит наиболее существенные ошибки (индекс всегда можно пересоздать, а вот пересоздание таблицы иногда невозможно). Как разработчик, в некоторых отдельных случаях я мог бы воспользоваться утилитой exp с full=y для выявления повреждений прикладных данных. Но именно пользовательских данных, а не повреждений базы данных . Реально exp оставляет за бортом огромное количество различного рода «внутренних» повреждений базы данных (не буду сейчас в это углубляться, пока поверьте мне на слово, их огромное множество). То, что полный экспорт системы завершился без предупреждающих сообщений, еще не означает, что база данных находится в работоспособном состоянии. Это говорит только о том, что ваши данные пока еще доступны . Ну и кроме всего прочего, DBA обычно не раздает направо и налево exp_full_database. Особенно мне нравится, когда подобный экспорт часто идет в /dev/null Как DBA, я думаю, что утилита exp не самый подходящий инструмент для выявления повреждений базы данных. Это довольно медленное и ресурсоемкое решение, сильно осложняемое тем, что consistent=y иногда проблематично сделать на интенсивно обновляемых базах данных большого объема и вы в этом случае не застрахованы от ORA-01555, а consistent=n применим только к пассивно живущему трупу. Ну и наконец, самое главное - exp НЕ проверит весь словарь данных и НЕ найдет в нем любую логическую несогласованность . Утилита exp не экспортирует объекты словаря данных, принадлежащие пользователю sys. Да, экспорт при своей работе использует некоторую информацию из словаря данных, косвенно «проверяя» ее, вот и все. Это еще не говорит о целостности всего словаря. Справедливости ради отмечу, что существует довольно большое количество способов поиска поврежденных блоков. Если вы используете для резервирования RMAN, такие повреждения очень легко диагностируются в процессе копирования. Предохраняться надо ведь по любому, а диагностику ошибок вы получите в качестве бонуса. Можно использовать DBVERIFY, который умеет работать как с offline, так online файлами данных. Если у вас установлен db_block_checksum, то все дополнительные проверки теряют смысл, т.к. Oracle сам будет проверять целостность всех блоков. Правда платой за это может быть незначительное проседание в производительности. На уровне отдельных объектов можно использовать analyze table xyz validate structure cascade и dbms_repair… Fucker Спасибо. Это все очень интересно. Я посмотрю вечером в книжке как это у Тома ... |
|||
:
Нравится:
Не нравится:
|
|||
27.07.2004, 20:09 |
|
Почему так медленно SELECT COUNT(*)
|
|||
---|---|---|---|
#18+
Markelenkov FuckerЕсли у вас установлен db_block_checksum, то все дополнительные проверки теряют смысл, т.к. Oracle сам будет проверять целостность всех блоков Я бы не был так категоричен. Точнее, мне кажется, было бы сказать "всех читаемых и записываемых блоков во всех табличных пространствах". Для TS SYSTEM, как известно, это включено по умолчанию и регулируется другим параметром. Блок может уже давно скончаться, а Oracle узнает об этом только при его чтении :-( Согласен, это мой недочет. Еще можно добавить и про проверку redo ;-) Fuckerпримерно 23 это ведь и 24 и 25, а может даже и 22 Хорошо, пусть будет ни вам, ни нам - 23.5 Хорошо, договорились killedкстати rman тоже не все ловит. Повезло тут недавно убедится :)) И на старуху бывает проруха ;-) RMAN'ом ты ведь после этого не перестал пользоваться Fucker ... |
|||
:
Нравится:
Не нравится:
|
|||
28.07.2004, 09:22 |
|
Почему так медленно SELECT COUNT(*)
|
|||
---|---|---|---|
#18+
Markelenkov FuckerЕсли у вас установлен db_block_checksum, то все дополнительные проверки теряют смысл, т.к. Oracle сам будет проверять целостность всех блоков Я бы не был так категоричен. Точнее, мне кажется, было бы сказать "всех читаемых и записываемых блоков во всех табличных пространствах". Для TS SYSTEM, как известно, это включено по умолчанию и регулируется другим параметром. Блок может уже давно скончаться, а Oracle узнает об этом только при его чтении :-( Пардон, в предыдущем послании моя фраза не туда влезла, поэтому повторю: Согласен, это мой недочет. Еще можно добавить и про проверку redo ;-) Fucker ... |
|||
:
Нравится:
Не нравится:
|
|||
28.07.2004, 10:59 |
|
Почему так медленно SELECT COUNT(*)
|
|||
---|---|---|---|
#18+
2 Fucker есть вопрос по поводу проверки redo знаю только вариант c alter system dump logfile Если подкините еще вариант, буду благодарен. Regards. ... |
|||
:
Нравится:
Не нравится:
|
|||
28.07.2004, 11:17 |
|
Почему так медленно SELECT COUNT(*)
|
|||
---|---|---|---|
#18+
Oracle newbie2 Fucker есть вопрос по поводу проверки redo знаю только вариант c alter system dump logfile Если подкините еще вариант, буду благодарен. Regards. Database ReferenceDB_BLOCK_CHECKSUM determines whether DBWn and the direct loader will calculate a checksum (a number calculated from all the bytes stored in the block) and store it in the cache header of every data block when writing it to disk. Checksums are verified when a block is read-only if this parameter is true and the last write of the block stored a checksum. In addition, Oracle gives every log block a checksum before writing it to the current log . Если не ошибаюсь, он начал влиять на работу с redo с тех пор, как в 8i log_block_cheksum стал obsolete Fucker ... |
|||
:
Нравится:
Не нравится:
|
|||
28.07.2004, 13:02 |
|
Почему так медленно SELECT COUNT(*)
|
|||
---|---|---|---|
#18+
2 В. Затронутая тема сподвигла на перечитывание книги Кайта "Expert One-on-One Oracle" в русском переводе с пометкой некоторых мест. Исходного варианта не имею, поэтому не исключены случаи неточного перевода. Перечитал сегодня том 1 по стр. 130. Глава 2, "Активный журнал повторного выполнения", стр. 98Если необходимо обеспечить максимально быстрое восстановление, придется использовать файлы журнала меньшего размера...Со словом "придется" категорически не согласен. Хотя далее в том же абзаце: "Для сокращения времени восстановления можно изменять и другие параметры базы данных, а не только уменьшать размер файлов журнала повторного выполнения." Глава 2, "Области PGA и UGA", стр. 101Размер области PGA/UGA определяют параметры уровня сеанса в файле init.ora: SORT_AREA_SIZE и SORT_AREA_RETAINED_SIZE. Здесь точнее было бы сказать "определяют в наибольшей степени". Глава 2, "DBWn - запись блоков базы данных", стр. 129...записи в активный журнал повторного выполнения можно пропустить , если в ходе обработки контрольной точки сервер Oracle уже записал измененные блоки на диск. Как это понимать? Глава 2, "Буфер журнала повторного выполнения", стр. 108, повторяет на стр. 129Данные не задерживаются в буфере журнала повторного выполнения надолго. Содержимое этого буфера сбрасывается на диск: - раз в три секунды - при фиксации транзакции - при заполнении буфера на треть или когда в нем оказывается 1 Мбайт данных журнала повторного выполнения Не упомянут случай, когда сброс данных из log_buffer в online redo инициирует DBWn. Возможно, это упрощение. Но, imho, излишнее. Тогда уж следовало сказать "обычно сбрасывается на диск". Естественно, есть много мест, где Кайт сознательно идет на упрощение изложения, что на 100% оправдано. Подобные (сомнительные в моем понимании) места в тексте есть и далее, но это ни коим образом не умоляет ни достоинств самого автора, ни достоинств его великолепной книги. ... |
|||
:
Нравится:
Не нравится:
|
|||
28.07.2004, 21:18 |
|
Почему так медленно SELECT COUNT(*)
|
|||
---|---|---|---|
#18+
Markelenkov2 В. Затронутая тема сподвигла на перечитывание книги Кайта "Expert One-on-One Oracle" в русском переводе с пометкой некоторых мест. Исходного варианта не имею, поэтому не исключены случаи неточного перевода. Перечитал сегодня том 1 по стр. 130. Глава 2, "Активный журнал повторного выполнения", стр. 98Если необходимо обеспечить максимально быстрое восстановление, придется использовать файлы журнала меньшего размера...Со словом "придется" категорически не согласен. Хотя далее в том же абзаце: "Для сокращения времени восстановления можно изменять и другие параметры базы данных, а не только уменьшать размер файлов журнала повторного выполнения." Глава 2, "Области PGA и UGA", стр. 101Размер области PGA/UGA определяют параметры уровня сеанса в файле init.ora: SORT_AREA_SIZE и SORT_AREA_RETAINED_SIZE. Здесь точнее было бы сказать "определяют в наибольшей степени". Глава 2, "DBWn - запись блоков базы данных", стр. 129...записи в активный журнал повторного выполнения можно пропустить , если в ходе обработки контрольной точки сервер Oracle уже записал измененные блоки на диск. Как это понимать? Глава 2, "Буфер журнала повторного выполнения", стр. 108, повторяет на стр. 129Данные не задерживаются в буфере журнала повторного выполнения надолго. Содержимое этого буфера сбрасывается на диск: - раз в три секунды - при фиксации транзакции - при заполнении буфера на треть или когда в нем оказывается 1 Мбайт данных журнала повторного выполнения Не упомянут случай, когда сброс данных из log_buffer в online redo инициирует DBWn. Возможно, это упрощение. Но, imho, излишнее. Тогда уж следовало сказать "обычно сбрасывается на диск". Естественно, есть много мест, где Кайт сознательно идет на упрощение изложения, что на 100% оправдано. Подобные (сомнительные в моем понимании) места в тексте есть и далее, но это ни коим образом не умоляет ни достоинств самого автора, ни достоинств его великолепной книги. Sorry, Ya vchera ne smotrela knizhku - rabotala do 11 vechera. Segodna ne znau kak budet, no ya obazatel'no v skorom vremeni posmotru i sravnu perevod. U mena takoe chuvstvo chto eto perevod. I eshe u mena minus: ya v osnovnom ne ponimau russkuu litaraturu po Oracle, mne trudno dogadivat'sa kakie termini chto oznachaut. ... |
|||
:
Нравится:
Не нравится:
|
|||
28.07.2004, 21:56 |
|
Почему так медленно SELECT COUNT(*)
|
|||
---|---|---|---|
#18+
Глава 2, "Активный журнал повторного выполнения", стр. 98Если необходимо обеспечить максимально быстрое восстановление, придется использовать файлы журнала меньшего размера...Со словом "придется" категорически не согласен. Хотя далее в том же абзаце: "Для сокращения времени восстановления можно изменять и другие параметры базы данных, а не только уменьшать размер файлов журнала повторного выполнения." Я не знаю, что такое Активный журнал повторного выполнения. Глава 2 называется "Архитектура". Я еще посмотрю, может, додумаюсь, что это за журнал, а пока буду писать, что понимаю. Ага, я теперь знаю, что это REDO BUFFER. Ну вот. Русский перевод неверный . Том пишет (простите, я перевожу на ходу и не редактирую, надуюсь, вы поймете): Грубо говоря, содержание REDO BUFFER вымывается: Каждые три секунды или Когда кто-то COMMIT, Когда он наполняется на одну треть или содержит 1 мег словленной REDO log информации. Поэтому иметь размер REDO BUFFER в порядке многих десятков Мег обычно означает расточительское использование хорошей памяти. Для того, чтобы использовать REDO BUFFER cache, например в 6 Мег, вам надо ранить очень долгий процесс который генерирует 2 мег REDO log каждые три секунды или меньше. Если в течение этого времени кто-то COMMIT, вы никогда не используете эти 2 мег места REDO log; оно будет постоянно вымываться. Глава 2, "Области PGA и UGA", стр. 101Размер области PGA/UGA определяют параметры уровня сеанса в файле init.ora: SORT_AREA_SIZE и SORT_AREA_RETAINED_SIZE. Здесь точнее было бы сказать "определяют в наибольшей степени". Вы правы, Том именно так и сказал, в русской версии неточный перевод: " One of the largest impacts on the size of your PGA/UGA will be in the init.ora on session-level parameters, SORT_SIZE and SORT_AREA_RETAINED_SIZE". Глава 2, "DBWn - запись блоков базы данных", стр. 129...записи в активный журнал повторного выполнения можно пропустить , если в ходе обработки контрольной точки сервер Oracle уже записал измененные блоки на диск. Как это понимать? Это надо спросить переводчика. Читаю и перерчитываю главку "DBWn - Database Block Writer" - и не вижу ничего, даже отдаленно напоминающего то, что вы цитируете. Вот опять для верности перечитала и НИЧЕГО ТАКОГО не увидела. Зато поняла, что такое "Активный журнал повторного выполнения" - это REDO BUFFER. Пойду к вашей первой цитате и посмотрю, что там. Глава 2, "Буфер журнала повторного выполнения", стр. 108, повторяет на стр. 129Данные не задерживаются в буфере журнала повторного выполнения надолго. Содержимое этого буфера сбрасывается на диск: - раз в три секунды - при фиксации транзакции - при заполнении буфера на треть или когда в нем оказывается 1 Мбайт данных журнала повторного выполнения Не упомянут случай, когда сброс данных из log_buffer в online redo инициирует DBWn. Возможно, это упрощение. Но, imho, излишнее. Тогда уж следовало сказать "обычно сбрасывается на диск". Это место я уже перевела в начале. Фраза "или когда в нем оказывается 1 Мбайт данных журнала повторного выполнения" у Тома звучит так: "When it gets one third full or contains 1 MB of catched redo log data". Вы правы, Том действительно сознательно идет на упрощение, так как он употребил выражение "In fact", которое можно перевести как "в общих чертах", "в общем", "грубо говоря", и пр. "In fact" означает генеральную идею, без подробностей. Насколько я поняла, перевод не слишком хороший. Наверное, кто-то наспех сделал. ... |
|||
:
Нравится:
Не нравится:
|
|||
29.07.2004, 04:28 |
|
Почему так медленно SELECT COUNT(*)
|
|||
---|---|---|---|
#18+
Я подробно ответила на твое сообщение, но когда я кликнула на Опубликовать, мне пришел ответ что-то вроде "У вас нет права публиковать сообщение на этом форуме". Я пошла назад, но моего текста уже не было. Не хочу все повторять, сил нет, но вкратце - твой анализ блестящ, наши DBA тебе в подметки не годятся и они бы не поняли почти ничего из того, что ты написал и что хорошо бы было обо всем этом спросить у Тома. ... |
|||
:
Нравится:
Не нравится:
|
|||
29.07.2004, 05:04 |
|
Почему так медленно SELECT COUNT(*)
|
|||
---|---|---|---|
#18+
В.Я не знаю, что такое Активный журнал повторного выполнения... ...Ага, я теперь знаю, что это REDO BUFFER. Ну вот. Русский перевод неверный. ...Зато поняла, что такое "Активный журнал повторного выполнения" - это REDO BUFFER. Похоже, Вы путаете log_buffer ( часть оперативной памяти для накопления redo-информации перед сбросом на диск в online redo files) и online redo (текущие, активные, имеющие статус ACTIVE в select status from v$log журнальные файлы или один файл , если online redo не дублируются). В.Это надо спросить переводчика. Читаю и перерчитываю главку "DBWn - Database Block Writer" - и не вижу ничего, даже отдаленно напоминающего то, что вы цитируете Постараюсь, когда приду домой, дать более точные координаты фразы про DBWn. Мне интересно увидеть исходный текст (in English) этого места. К сожалению, уезжаю на днях в отпуск, времени мало. На счет других, процитированных мной мест, - понятно. Это, видимо, некоторые погрешности перевода. В.Насколько я поняла, перевод не слишком хороший. Наверное, кто-то наспех сделал.Переводил В. Кравчук, даю ссылки: /topic/27157&pg=1 http://ln.com.ua/~openxs/projects/oracle http://ln.ua/~openxs/projects/oracle/expert.html Перевод достаточно хороший. Были некие дискуссии о терминологии, но это мелочи. А ошибки и опечатки бывают у всех. Тем более, автор перевода готов принять их список. Я, было, начал делать пометки опечаток карандашом, но потом устал и бросил. По поводу русских терминов. В основном они идут отсюда: http://www.rdtex.ru/docs/glossary/ Рекомендую. По поводу последней фразы - не надо преувеличивать мои заслуги. Я, например, Факеру в подметки не гожусь. Тогда на какую часть его подошвы пускать Ваших админов? ;-) Одна надежда, что Fucker босиком и летом, и зимой бегает :-) ... |
|||
:
Нравится:
Не нравится:
|
|||
29.07.2004, 14:22 |
|
Почему так медленно SELECT COUNT(*)
|
|||
---|---|---|---|
#18+
По поводу последней фразы - не надо преувеличивать мои заслуги. Я, например, Факеру в подметки не гожусь. Тогда на какую часть его подошвы пускать Ваших админов? ;-) Одна надежда, что Fucker босиком и летом, и зимой бегает :-)[/quot] Мой последний постинг был как раз ему (F-ру). Я ему подробно написала, но у меня постинг не прошел и исчез. Надо было его имя в обращении поставить, но у меня рука не поворачивается такие слова писать :) Вы тоже здорово во всем разбираетесь, между прочим, завидую. Мне было интересно сравнивать русский переовд с оригиналом. Если получится до отпуска (опять я вам тут завидую!), подкиньте еще что-нибудь интересное. ... |
|||
:
Нравится:
Не нравится:
|
|||
29.07.2004, 16:33 |
|
Почему так медленно SELECT COUNT(*)
|
|||
---|---|---|---|
#18+
В. Мой последний постинг был как раз ему (F-ру). Я ему подробно написала, но у меня постинг не прошел и исчез. Надо было его имя в обращении поставить, но у меня рука не поворачивается такие слова писать :) тогда зовите его ласково Фунтик ... |
|||
:
Нравится:
Не нравится:
|
|||
29.07.2004, 17:26 |
|
Почему так медленно SELECT COUNT(*)
|
|||
---|---|---|---|
#18+
Markelenkov...online redo (текущие, активные, имеющие статус ACTIVE в select status from v$log журнальные файлы или один файл, если online redo не дублируются). Бес попутал... Конечно же - online redo, это все журнальные файлы, которые отображаются в v$log, а текущие (current), или иначе иногда не совсем корректно называемые активные, имеют статус CURRENT в v$log. В.Мой последний постинг был как раз ему (F-ру). Ну тогда я спокоен... В.наши DBA тебе в подметки не годятся и они бы не поняли почти ничего из того, что ты написал А Вы им покажите, Fucker все очень правильно и доходчиво написал. Должны понять. ... |
|||
:
Нравится:
Не нравится:
|
|||
29.07.2004, 17:38 |
|
Почему так медленно SELECT COUNT(*)
|
|||
---|---|---|---|
#18+
2 В. Как и обещал, даю более точные координаты: Глава 2 (Архитектура), Процессы, Фоновые (Background) процессы, DBWn - запись блоков базы данных, самое последнее предложение перед "LGWR - запись журнала" (что в англ. варианте выглядит примерно как "LGWR - redo log writer"): Это верно даже несмотря на то, что сервер Oracle может выполнять больший объем ввода/вывода, чем надо (записывает в журнал и в файл данных), - записи в активный журнал повторного выполнения можно пропустить, если в ходе обработки контрольной точки сервер Oracle уже записал измененные блоки на диск. Очень хотелось бы, если не затруднит, увидеть оригинальный текст Кайта. Спасибо. ... |
|||
:
Нравится:
Не нравится:
|
|||
29.07.2004, 21:43 |
|
Почему так медленно SELECT COUNT(*)
|
|||
---|---|---|---|
#18+
Markelenkov2 В. Как и обещал, даю более точные координаты: Глава 2 (Архитектура), Процессы, Фоновые (Background) процессы, DBWn - запись блоков базы данных, самое последнее предложение перед "LGWR - запись журнала" (что в англ. варианте выглядит примерно как "LGWR - redo log writer"): Это верно даже несмотря на то, что сервер Oracle может выполнять больший объем ввода/вывода, чем надо (записывает в журнал и в файл данных), - записи в активный журнал повторного выполнения можно пропустить, если в ходе обработки контрольной точки сервер Oracle уже записал измененные блоки на диск. Очень хотелось бы, если не затруднит, увидеть оригинальный текст Кайта. Спасибо. Ne zatrudnit. Pridu domoi posmotru. ... |
|||
:
Нравится:
Не нравится:
|
|||
29.07.2004, 22:23 |
|
Почему так медленно SELECT COUNT(*)
|
|||
---|---|---|---|
#18+
B. Markelenkov2 В. Как и обещал, даю более точные координаты: Глава 2 (Архитектура), Процессы, Фоновые (Background) процессы, DBWn - запись блоков базы данных, самое последнее предложение перед "LGWR - запись журнала" (что в англ. варианте выглядит примерно как "LGWR - redo log writer"): [quot ]Это верно даже несмотря на то, что сервер Oracle может выполнять больший объем ввода/вывода, чем надо (записывает в журнал и в файл данных), - записи в активный журнал повторного выполнения можно пропустить, если в ходе обработки контрольной точки сервер Oracle уже записал измененные блоки на диск. Очень хотелось бы, если не затруднит, увидеть оригинальный текст Кайта. Спасибо. Главка называется "DBWn - Database Block Writer". Она действительно идет перед главкой "LGWR - Log Writer". Вот самый последний абзац: I would like to make one final point about DBWn. It will, almost by definition, write out blocks scattered all over disk - DBWn does lots of scattered writes. When you do an update, you'll be modifying index blocks that are stored here and there and data blocks that are randomly distributed on disk as well. LGWR, on the other hand, does lots of sequential writes to the redo log. This is an important distinction, and one of the reasons that Oracle has a redo log and a LGWR process. Scattered writes are significantly slower than sequential writes. By having the SGA buffer dirty blocks and the LGWR process do large sequential writes that can recreate these dirty buffers, we achieve an increase in performance. The fact that DBWn does its slow job in the background while LGWR does its faster job while the user waits, gives us overall better performance. This is true even though Oracle may technically be doing more I/O then it needs to (writes to the log and to the datafile) - the writes to the online redo log could be skipped if, during a commit, Oracle physically wrote the modified blocks out to disk instead. page 94 А, ну понятно. Если Оракл в течение commit физически записал измененные блоки на диск, то возможно, он и не запишет данные в online redo log. (Не "можно пропустить", как перевели в русском варианте, поэтому я вчера и не поняла, о чем шла речь). Сould be - означает не "можно", а "возможно", "вероятно", "может статься, что". Всего доброго ... |
|||
:
Нравится:
Не нравится:
|
|||
30.07.2004, 04:18 |
|
Почему так медленно SELECT COUNT(*)
|
|||
---|---|---|---|
#18+
Спасибо за ответ. Мне кажется, что Кайт здесь ошибается. Запись в online redo существенно необходима для обеспечения возможности восстановления как при сбое экземпляра (shutdown abort, сбой по питанию и т.п.), так и при сбое носителя. Поэтому отсутствие записи зафиксированных изменений и/или commit-маркера в online redo при последующем сбое носителя и отсутствии бэкапа табличного пространства (или, если быть точнее, конкретного датафайла(ов)) сделает невозможным восстановление базы даных без потерь информации. Именно поэтому после выполнения операций в режиме NOLOGGING (когда нет записи об операции в online redo, или она минимальна) Oracle настоятельно рекомендует выполнить backup соответствующего табл. пространства/пространств. Кроме того, если во время длительной транзакции, которая завершалась бы операцией ROLLBACK, грязные блоки записывались бы на диск (что в действительности и может происходить и обычно происходит), а соответствующая redo-информация не записывалась бы при этом в журналы (а в журнал попадает в том числе информация об изменениях в сегментах отката), то в случае сбоя экземпляра в файлы данных попали бы незафиксированные изменения , которые Oracle при очередном crash recovery не смог бы откатить (нет соотв. redo). Более того, Oracle никогда не записывает грязные блоки на диск до тех пор, пока redo-entries, "защищающие" эти блоки, не будут сброшены на диск в online redo процессом LGWR. Если мне не верите, вот ссылка: http://www.ixora.com.au/notes/rba.htm Кроме этого, стоит упомянуть, что, например, у табл. пространств, у всей базы данных можно установить опцию FORCE LOGGING. Кроме этого, журнальная информация жизненна необходима для режима STANDBY. Правда, существует скрытый параметр, отключающий генерацию redo, но как он сосуществует с опцией FORCE LOGGING я не исследовал. Таким образом, фраза Кайта "...the writes to the online redo log could be skipped if, during a commit, Oracle physically wrote the modified blocks out to disk instead." на мой взгляд, ошибочна, либо он имел ввиду нечто другое. На перевод в данном случае, как мне кажется, грешить нельзя. ... |
|||
:
Нравится:
Не нравится:
|
|||
30.07.2004, 09:14 |
|
Почему так медленно SELECT COUNT(*)
|
|||
---|---|---|---|
#18+
2 B. Я не знаю что Кайт имел ввиду этой фразой, но Ваша понимание этого меня заинтересовало. На самом деле Oracle работате так что ни одно ( nothing at all ) физическое изменение в БД не запишеться без предварительной записи в redo log file. Не в log buffer а именно в файл. По изменением БД я подразумеваю - запись блока на диск (будь то изменения сделанные в ходе изминения строки , или после commit cleanout или же изменения транзакционной таблицы в заголовке роллбек сегментов) . Отсюда вытекает 4-й пункт к существующим 3-м пунктам условий сброса log buffer на диск , которые декларируются многоми авторами Oracle литературы. 4-й пункт как раз и говорит о том , что запись в redo log file осуществляется когда процесс DBWR пытается записать грязные блоки на диск, и если они находяться в redo buffer и еще не записаны в redo log file, то нициируется сброс redo buffer на диск. Вот здесь это расписано более понятно. Посмотрите на 4-й пункт. http://www.ixora.com.au/notes/redo_write_triggers.htm ... |
|||
:
Нравится:
Не нравится:
|
|||
30.07.2004, 11:24 |
|
Почему так медленно SELECT COUNT(*)
|
|||
---|---|---|---|
#18+
Ага! Возникло подозрение, что Кайт в электронном виде таки существует :-))))))) ... |
|||
:
Нравится:
Не нравится:
|
|||
30.07.2004, 12:15 |
|
Почему так медленно SELECT COUNT(*)
|
|||
---|---|---|---|
#18+
igor2222Ага! Возникло подозрение, что Кайт в электронном виде таки существует :-))))))) На чем оно основано? ... |
|||
:
Нравится:
Не нравится:
|
|||
30.07.2004, 12:41 |
|
Почему так медленно SELECT COUNT(*)
|
|||
---|---|---|---|
#18+
Да цитаты из Кайта какие то большие приводятся. Неужели руками набирались? ... |
|||
:
Нравится:
Не нравится:
|
|||
30.07.2004, 13:09 |
|
Почему так медленно SELECT COUNT(*)
|
|||
---|---|---|---|
#18+
Маркеленкову и "Новичку" А что если я, с вашего разрешения, спрошу об этом Тома со ссылкой на вас? Можно? Интересно, что он ответит. P/S К сожалению, электронной версии нет кроме выдержек из первой главы. Просто я быстро печатаю. ... |
|||
:
Нравится:
Не нравится:
|
|||
30.07.2004, 16:48 |
|
Почему так медленно SELECT COUNT(*)
|
|||
---|---|---|---|
#18+
В.Маркеленкову и "Новичку" А что если я, с вашего разрешения, спрошу об этом Тома со ссылкой на вас? Можно? Интересно, что он ответит. Лично я не против, Виталий (newbie), думаю, тоже будет не против. Кстати, чайником он только прикидывается, если Вы еще не заметили. Про утилиту exp тоже можно было бы спросить, но про возможность сослаться на Фунтика надо у него же и спрашивать. Правда, попутно возникает два вопроса: 1. Умеет ли он читать по-русски? Или Вы ему переведете нас? ;-) 2. Неужели никто на asktom его об этом до сих пор не спрашивал? Ведь книга в английском варианте вышла гораздо раньше, да и англоговорящих спецов по Oracle гораздо больше. Кстати, я заметил, что многие просто боятся спорить с Кайтом. ... |
|||
:
Нравится:
Не нравится:
|
|||
30.07.2004, 17:13 |
|
Почему так медленно SELECT COUNT(*)
|
|||
---|---|---|---|
#18+
2 B. Думаю можно конечно. Но я хотел бы повторить,судя по напечатанным отрывкам, я не могу делать выводы, о чем писал Томас Кайт . Вечером могу посмотреть в оригинале. То что у него не упомянут случай с DBWR это помню. Пост же мой предназначаслся именно вам, глядя на то что складывается некое непонимание механизма рекавери. Не может Oracle записать данные в datafile до того как они будут записаны в online redo logs Ибо тогда рушиться вся теория о восстановлении с redo logs и откате незакоммиченных изминений при crash recovery(если инстанс упал) Не претендуя на точность (вывеска на заборе - "осторожно, злой Fucker!" ) 1. блок данных изменился и был записан в log buffer 2. Этот блок был изменен много времени раньше( указатель на его заголовок помещен в checkpoint queue) и пришло время ему быть записанным на диск by DBWR (checkpoint). Но перед этим DBWR должен убедится что блок не находиться в log buffer и его самое последнее изменения записано в redo log file 3. DBWR отложит этот блок в deferred chekpoint queue и оповестит LGWR о том что надо бы записать этот блок с log buffer на диск. Вот тут и произойдет сброс redo buffer на диск то бишь в current redo log Regards. ... |
|||
:
Нравится:
Не нравится:
|
|||
30.07.2004, 17:57 |
|
Почему так медленно SELECT COUNT(*)
|
|||
---|---|---|---|
#18+
Пока не появился "злой Фунтик", чуть уточню Oracle newbie1. блок данных изменился и был записан в log buffer Правильнее было бы сказать "и вектор его изменений был записан в log buffer". 2 В., all Можно еще добавить, что кроме ситуации с checkpoint (переключение журналов, alter system checkpoint, события FAST_START..., log_checkpoint_interval/time,...) DBWR может попросить LGWR сбросить log buffer в current redo еще, например, в случаях, когда: - серверный процесс после просмотра _db_block_max_scan_pct % LRU-списка не может получить free block и просит DBWR сбросить грязные блоки на диск - когда число грязных блоков в LRU-списке достигает _db_large_dirty_queue - выполняется команда alter tablespace xxx begin backup - выполняется shutdown (кроме shutdown abort) - по-моему, еще в случае, когда оптимизатор распараллеливает операции чтения над сегментом, все его грязные блоки должны быть тоже сброшены на диск - наверняка есть еще ситуации, которые я сейчас не вспомнил, но это не суть важно. В общем, всегда, когда DBWR должен сбросить грязный блок на диск, он должен удостовериться, что redo-вектор(а) самых последних изменений этого блока сброшен(ы) процессом LGWR на диск. То есть, LGWR всегда пишет в redo все изменения (естественно, которые попали в log buffer, и опять же таки, только вектор изменений, а не сам блок) любого блока до того, как DBWR запишет в файл данных сам измененный блок. ... |
|||
:
Нравится:
Не нравится:
|
|||
30.07.2004, 19:44 |
|
Почему так медленно SELECT COUNT(*)
|
|||
---|---|---|---|
#18+
Markelenkov В.Маркеленкову и "Новичку" А что если я, с вашего разрешения, спрошу об этом Тома со ссылкой на вас? Можно? Интересно, что он ответит. Лично я не против, Виталий (newbie), думаю, тоже будет не против. Кстати, чайником он только прикидывается, если Вы еще не заметили. Про утилиту exp тоже можно было бы спросить, но про возможность сослаться на Фунтика надо у него же и спрашивать. Правда, попутно возникает два вопроса: 1. Умеет ли он читать по-русски? Или Вы ему переведете нас? ;-) 2. Неужели никто на asktom его об этом до сих пор не спрашивал? Ведь книга в английском варианте вышла гораздо раньше, да и англоговорящих спецов по Oracle гораздо больше. Кстати, я заметил, что многие просто боятся спорить с Кайтом. по-руски он не умет, но я переведу. что "новичек" не чайник это ясно, поэтому я его ник и поставила в кавычки. на asktom я смотрела (не утверждаю, что очень внимательно), но дискуссии на эту тему не нашла. чтобы тому и мне было легче, нельзя ли вам с Виталием и с Фунтиком сформулировать вопросы\возражения кратко и в виде 1. 2. 3 ...? том любит умные вопросы и не очень любит глупые, хотя отвечает на все. думаю, ему будет интересно узнать, что его книги читают и обсуждают руские гуру и что в россии есть оракуловские гуру. ... |
|||
:
Нравится:
Не нравится:
|
|||
30.07.2004, 20:04 |
|
Почему так медленно SELECT COUNT(*)
|
|||
---|---|---|---|
#18+
К сожалению, мне уже некогда, есть дела, которые надо сделать перед отъездом. Жена уже пилит, гонит от компа... Поэтому без меня. А я с удовольствием потом почитаю ответы Тома, если он ответит и Вы дадите ссылочку. ... |
|||
:
Нравится:
Не нравится:
|
|||
30.07.2004, 20:32 |
|
Почему так медленно SELECT COUNT(*)
|
|||
---|---|---|---|
#18+
Uvazhaemyi Markelenkov (esli vi eshe ne v otpuske) , Zdes' ya ne soglasna. Vi govorite: Кроме того, если во время длительной транзакции, которая завершалась бы операцией ROLLBACK, грязные блоки записывались бы на диск (что в действительности и может происходить и обычно происходит), а соответствующая redo-информация не записывалась бы при этом в журналы (а в журнал попадает в том числе информация об изменениях в сегментах отката), то в случае сбоя экземпляра в файлы данных попали бы незафиксированные изменения , которые Oracle при очередном crash recovery не смог бы откатить (нет соотв. redo). Tom skazal, cho bloki mogut zapisivat'sa na disk minua redo log tol'ko esli COMMIT. ... |
|||
:
Нравится:
Не нравится:
|
|||
30.07.2004, 23:33 |
|
Почему так медленно SELECT COUNT(*)
|
|||
---|---|---|---|
#18+
B.Tom skazal, cho bloki mogut zapisivat'sa na disk minua redo log tol'ko esli COMMIT. Возможно это просто неточное его высказывание или неправильная интерпретация оного. Oracle не может знать что будет с транзакцией - commit или rollback. Никто не сможет предугадать что захочет сделать юзер, так что имхо в любых случаях сначала пишуться изменения в redo log. Возможно имелся в виду тот факт что САМА операция отката не вызывает запись в redo log см. Note в конце Advantages of the Fast COMMIT The fast commit mechanism ensures data recovery by writing changes to the redo log buffer instead of the data files. It has the following advantages: • Sequential writes to the log files are faster than writing to different blocks in the data file. • Only the minimal information that is necessary to record changes is written to the log files, whereas writing to the data files would require whole blocks of data to be written. • If multiple transactions request to commit at the same time, the instance piggybacks redo log records into a single write. • Unless the redo log buffer is particularly full, only one synchronous write is required per transaction. If piggybacking occurs, there can be less than one synchronous write per transaction. • Because the redo log buffer may be flushed before the COMMIT, the size of the transaction does not affect the amount of time needed for an actual COMMIT operation. Note: Rolling back a transaction does not trigger LGWR to write to disk. The Oracle server always rolls back uncommitted changes when recovering from failures. If there is a failure after a rollback, before the rollback entries are recorded on disk, the absence of a commit record is sufficient to ensure that the changes made by the transaction are rolled back. ... |
|||
:
Нравится:
Не нравится:
|
|||
31.07.2004, 00:03 |
|
Почему так медленно SELECT COUNT(*)
|
|||
---|---|---|---|
#18+
Решила обрисовать пару конкретных ситуаций по этому поводу. Поправьте или дополните плиз если где то есть ошибки или упущенные моменты. Ситуация 1: Сбой во время изменений данных - идет транзакция - Oracle сбросил некоторые грязные незакомиченные данные из оперативной памяти в дата файлы - изменение данных разумется в свою очередь вызвало изменение в сегментах отката, в них записались старые версии данных - часть изменных данных в сегментах отката сидит в оперативной памяти и еще не было сброшено на диск Происходит сбой. Что мы имеем: - в датафайлах сидят незакомиченные данные которые нужно откатить - сегменты отката не содержат всю необходимую информацию для отмены незакомиченных изменений, потому что часть их сидела в оперативной памяти и была потеряна при сбое - в redo журнале записаны все изменения данных и сегметов отката до момента последнего сброса log buffer на диск Что поисходит при старте - Оракл накатывает ВСЕ изменения из redo - как закомиченные так и незакомиченные - как на блоки данных так и на блоки сегментов отката. Теперь сегменты отката восстановлены до того состояния, когда вся информация для отмены незакомиченных изменений имеется. - Используя сегменты отката Oracle откатывает незакомиченные изменения. Ситуация 2: Сбой во время отката - идет транзакция - Oracle сбросил некоторые грязные незакомиченные данные из оперативной памяти в дата файлы - изменение данных разумется в свою очередь вызвало изменение в сегментах отката, в них записались старые версии данных - часть изменных данных в сегментах отката сидит в оперативной памяти и еще не было сброшено на диск - пользователь решил сделать rollback - в redolog разумеется не была записана commit record - пошел откат Происходит сбой во время операции отката. Что мы имеем: - в датафайлах сидят незакомиченные данные которые нужно откатить - сегменты отката НЕ содержат всю необходимую информацию для отмены незакомиченных изменений, потому что часть их сидела в оперативной памяти и была потеряна при сбое - в redo журнале записаны все изменения данных и сегметов отката до момента последнего сброса log buffer на диск Что поисходит при старте: - Oracle накатывает ВСЕ изменения из redo - как закомиченные так и незакомиченные - как на блоки данных так и на блоки сегментов отката. Теперь сегменты отката восстановлены до того состояния, когда вся информация для отмены незакомиченных изменений имеется. - откат продолжается дальше ... |
|||
:
Нравится:
Не нравится:
|
|||
31.07.2004, 00:53 |
|
Почему так медленно SELECT COUNT(*)
|
|||
---|---|---|---|
#18+
ViolinaРешила обрисовать пару конкретных ситуаций по этому поводу. Поправьте или дополните плиз если где то есть ошибки или упущенные моменты. Ситуация 1: Сбой во время изменений данных - идет транзакция - Oracle сбросил некоторые грязные незакомиченные данные из оперативной памяти в дата файлы - изменение данных разумется в свою очередь вызвало изменение в сегментах отката, в них записались старые версии данных - часть изменных данных в сегментах отката сидит в оперативной памяти и еще не было сброшено на диск Происходит сбой. Что мы имеем: - в датафайлах сидят незакомиченные данные которые нужно откатить - сегменты отката не содержат всю необходимую информацию для отмены незакомиченных изменений, потому что часть их сидела в оперативной памяти и была потеряна при сбое - в redo журнале записаны все изменения данных и сегметов отката до момента последнего сброса log buffer на диск Что поисходит при старте - Оракл накатывает ВСЕ изменения из redo - как закомиченные так и незакомиченные - как на блоки данных так и на блоки сегментов отката. Теперь сегменты отката восстановлены до того состояния, когда вся информация для отмены незакомиченных изменений имеется. - Используя сегменты отката Oracle откатывает незакомиченные изменения. Ситуация 2: Сбой во время отката - идет транзакция - Oracle сбросил некоторые грязные незакомиченные данные из оперативной памяти в дата файлы - изменение данных разумется в свою очередь вызвало изменение в сегментах отката, в них записались старые версии данных - часть изменных данных в сегментах отката сидит в оперативной памяти и еще не было сброшено на диск - пользователь решил сделать rollback - в redolog разумеется не была записана commit record - пошел откат Происходит сбой во время операции отката. Что мы имеем: - в датафайлах сидят незакомиченные данные которые нужно откатить - сегменты отката НЕ содержат всю необходимую информацию для отмены незакомиченных изменений, потому что часть их сидела в оперативной памяти и была потеряна при сбое - в redo журнале записаны все изменения данных и сегметов отката до момента последнего сброса log buffer на диск Что поисходит при старте: - Oracle накатывает ВСЕ изменения из redo - как закомиченные так и незакомиченные - как на блоки данных так и на блоки сегментов отката. Теперь сегменты отката восстановлены до того состояния, когда вся информация для отмены незакомиченных изменений имеется. - откат продолжается дальше Violin и Марленков и Виталий ("Новичок") и все остальные! Мы просто не понимаем юмора! Мы русские все воспринимаем смертельно-серьезно. Я спросила сегодня Тома об этом и он ответил буквально следующее: "Я говорил гипотетически и, наверное, что-то потерялось в переводе. Я говорил ( с подтекстом в скобках) , что записи в online redo log (теоретически) могли бы быть пропущены если бы во время commit Оракл вместо этого бы записывал измененные блоки на диск (но, поскольку это никогда не происходит, это чисто гипотетическое утверждение). ЕСЛИ БЫ Оракл записывал изменения на диск во время commit, redo logs были бы излишни. НО Оракл использует redo logs -- улучшая обращение IO чтобы улучшить performance. Читайте в конце дискуссии (кстати, оттуда вы узнаете, что меня зовут Вера) http://asktom.oracle.com/pls/ask/f?p=4950:8:383290::NO::F4950_P8_DISPLAYID,F4950_P8_CRITERIA:8145042756282, Однако, в одном я была права, переведя высказывание Тома как "если бы", возможно" и пр. ... |
|||
:
Нравится:
Не нравится:
|
|||
31.07.2004, 07:01 |
|
Почему так медленно SELECT COUNT(*)
|
|||
---|---|---|---|
#18+
B.Uvazhaemyi Markelenkov (esli vi eshe ne v otpuske) , Zdes' ya ne soglasna. Vi govorite: Кроме того, если во время длительной транзакции, которая завершалась бы операцией ROLLBACK, грязные блоки записывались бы на диск (что в действительности и может происходить и обычно происходит), а соответствующая redo-информация не записывалась бы при этом в журналы (а в журнал попадает в том числе информация об изменениях в сегментах отката), то в случае сбоя экземпляра в файлы данных попали бы незафиксированные изменения , которые Oracle при очередном crash recovery не смог бы откатить (нет соотв. redo). Tom skazal, cho bloki mogut zapisivat'sa na disk minua redo log tol'ko esli COMMIT. Сегодня я пока еще дома, но развернуто отвечать не буду. Готов и сейчас на 100% подписаться под этим своим высказыванием. Можно только более подробно расшифровать фразу "(нет соотв. redo)": (нет соответствующей redo-информации в журнальных файлах, которая позволила бы воостановить сегменты отката на момент сбоя для того, чтобы откатить все незакоммитченные изменения в блоках данных, которые перед сбоем были физически записаны на диски процессом DBWR). Кроме того, в случае, если бы действительно "...the writes to the online redo log could be skipped if, during a commit, Oracle physically wrote the modified blocks out to disk instead.", то в базе данных могли бы оказаться несогласованные (no consistent) данные, т.е. только часть изменений в блоках могла бы попасть на диск, а часть (из тех грязных блоков, которые DBWR еще не успел записать на диски) - пропасть. Причем все вышесказанное может случиться и в случае завершения транзакции операцией COMMIT. Еще один, немного смешной "довод": как процесс LGWR может узнать, записал(и) ли процесс(ы) DBWn все грязные блоки, связанные с транзакцией, на диск, чтобы не записывать redo-информацию в журналы? Потребуется или изобретать для этого или способ общения LGWR с процессами DBWn, или LGWR должен будет сам (один) копаться в списках LRU (обычно в нескольких). В обоих случаях - это огромный объем кода и неимоверные тормоза в производительности. Кроме всего, несколько удивляет фраза Тома "during a commit". Как процитировала выше Violina, Oracle использует алгоритм так называемого fast commit, который, в принципе, используя алгоритм delayed commit clearnout, может во время выполнения commit совсем не производить окончательных модификаций в измененных ранее текущей транзакцией блоках данных. В этом случае серверный процесс помещает в redo-блок в log buffer только маркер COMMIT и выдает сигнал клиентскому приложению, что транзакция завершена. Другими словами, обычно выполнение самой операции COMMIT занимает ничтожно малое время, поэтому, на мой взгляд , фраза "during a commit" выглядит несколько странно. Ну вот, ответ получился все-таки достатчно развернутый :-) P.S. Не хочется верить, что такой специалист, гуру, как Том Кайт, не понимает таких основ. Наверняка он хотел той своей фразой в книге сказать что-то другое. Вот и интересно выяснить - что же? Ха-ха-ха!!! Писал ответ, нажал кнопку предварительного просмотра и увидел Ваш последний пост, Вера. Действительно, смешно! Вся наша дискуссия показала необходимость особой точности формулировок. Если бы в тексте присутствовала фраза "theoretically", "hypothetically", то все изначально было бы понятно., т.к. даже в английском варианте фраза трактуется совсем не так, как имел ввиду Том. Неудивительно, что перевод окончательно исказил весь смысл. Пусть Том пометит себе, что это место в книге следует уточнить. Ну а на счет утилиты exp тоже было бы интересно разобраться. Спасибо за ссылку, может быть успею сегодня почитать. ... |
|||
:
Нравится:
Не нравится:
|
|||
31.07.2004, 08:00 |
|
Почему так медленно SELECT COUNT(*)
|
|||
---|---|---|---|
#18+
2 В. Все, прочитал внизу ветки http://asktom.oracle.com/pls/ask/f?p=4950:8:383290::NO::F4950_P8_DISPLAYID,F4950_P8_CRITERIA:8145042756282 В этом разрезе вся моя критика по поводу "during commit" тоже лишена смысла. Если бы в книге была бы фраза именно в виде ".... the writes to the online redo log (in theory) could be skipped if, during a commit, Oracle physically wrote the modified blocks out to disk instead. (but since it doesn't work that way, that is just a hypothetical)", то все было бы сразу ясно. Спасибо за информацию. ... |
|||
:
Нравится:
Не нравится:
|
|||
31.07.2004, 08:07 |
|
Почему так медленно SELECT COUNT(*)
|
|||
---|---|---|---|
#18+
Markelenkov2 В. Все, прочитал внизу ветки http://asktom.oracle.com/pls/ask/f?p=4950:8:383290::NO::F4950_P8_DISPLAYID,F4950_P8_CRITERIA:8145042756282 В этом разрезе вся моя критика по поводу "during commit" тоже лишена смысла. Если бы в книге была бы фраза именно в виде ".... the writes to the online redo log (in theory) could be skipped if, during a commit, Oracle physically wrote the modified blocks out to disk instead. (but since it doesn't work that way, that is just a hypothetical)", то все было бы сразу ясно. Спасибо за информацию. Марленков!!! Это все действительно смешно! Мы сейчас сидим с друзьями и время от времени я подхожу к комрьютеру и проверяю "мессиджи" и умираю от смеха! Показала фразу Тома другу (он крутой компьютерщик, но американец) и он сразу же сказал, что обсуждаемая нами фраза означает "если ба да кабы", если бы Оракла делал то-то и то-то, то то-то и то-то было бы не нужно, и опять затряслась от смеха. Но это действительно тонкости языка. Уж на что я его хорошо знаю, но даже я не поняла до конца смысл, хотя догадалась насчет "если бы". Но все рано не поняла, дура. Надо бы и про экспорт спросить. Однако правда здорово, что Том - несмотря на вечер и пятницу (я ему вечером написала) - сразу ответил? Счастливого отдыха! ... |
|||
:
Нравится:
Не нравится:
|
|||
31.07.2004, 08:27 |
|
Почему так медленно SELECT COUNT(*)
|
|||
---|---|---|---|
#18+
Привет Мои два копейка: 1. сорри, всю неделю был занят по самое нехочу. Пропустил такую интересную дискусию. Даже прочитать времени не было. *_млинк_* 2. 2 "Fucker" тынц Пару моментов. a) dbv не может проверять файлы >2Gb. b) exp отдельно взятой схемы SYS в /dev/null чуток может помочь, но не затрагивает индексов по базовым таблицам словаря данных. c) RMAN хреново тестирует (совсем не) только что импортнутые TTS. Надо их переводить в RW, потом опять в RO. Вся инфа на основе 8.1.7.4 и 9.2.0.5. До 10g-ки шаловливые ручки пока не дотянулись в желаемой степени. 3. 2 "killed" "кстати rman тоже не все ловит. Повезло тут недавно убедится :))". Ясень пень, что только FTS и FFIS по всем объектам могут убедить тебя в исправности всех заЮзаных блоков БД. Остаются еще rollback\'и... Из известных методов, к сожалению, тока dump\'ы блоков rollback :-(. Ну и BOOTSTRAP$ - видимо, тока dump всех его блоков. 4. 2 "Markelenkov" тынц "Если необходимо обеспечить максимально быстрое восстановление, придется использовать файлы журнала меньшего размера... " Есть одна такая фишка в Oracle (уверен про 8i- :-() ). Может быть 9i/10g уже переделали... Короче. После наката очередного redo (online или archived) выполняется интервальная контрольная точка . A la 7.3./"ALTER SYSTEM CHECKPOINT". Т.е. ВСЕ модифицированные буферы сбрасываются на диск. При этом БД закрыта, следовательно накат не может быть продолжен, пока эта контрольная точка не завершится. Собственно, из доков не следует (DBGroup Consulting может меня поправить), но этот факт сильно мешал накату на standby у одного из крупных операторов сотовой связи. Standby просто отставал от production. Помогло уменьшение кеша буферов на standby. (Аппаратура: на production - Sun 15K, процесоров 32+, Oracle8i 64-bit. Standby поскромнее. Вроде как Sun 6500. Не однопроцессорный, ясень пень. Остальные подробности не помню). Так что я не совсем понял, что имел ввиду Том Кайт (разве что высказывание относилось к Oracle7). При супер большом кеше буферов уменьшение размера redo log\'ов может дать обратный эффект... 5. 2 "Violina" - как всегда, точна (не наезд, все по-серьезному). Остальное, вроде как, соответствует моему пониманию (если ничего не упустил). PS. Ребятки, вы хоть понимаете, что уже накропали неплохую статью для Oramag? Недавно мне довелось побеседовать с Анатолием Бачиным (главред Oramag/ru). Он серьезно жалуется на отсутствие хороших материалов для публикаций. Слабо вам самоорганизоваться и заделать этот пробой? Про recovery должно получиться неплохо... Всего -- Andrei Kriushin (Oracle8/8i/9i OCP DBA), RDTEX J.S.C. Disclaimer: Opinions are of my own and not ... |
|||
:
Нравится:
Не нравится:
|
|||
31.07.2004, 19:19 |
|
Почему так медленно SELECT COUNT(*)
|
|||
---|---|---|---|
#18+
Привет Сории, забыл пункт 6. 2 "B." - Зарегистрировались бы ;-) Неужели такой ник уже занят? - В соавторы идите... Всего -- Andrei Kriushin (Oracle8/8i/9i OCP DBA), RDTEX J.S.C. Disclaimer: Opinions are of my own and not necessar(-il)y... ... |
|||
:
Нравится:
Не нравится:
|
|||
31.07.2004, 19:21 |
|
Почему так медленно SELECT COUNT(*)
|
|||
---|---|---|---|
#18+
АазПривет Мои два копейка: 3. 2 "killed" "кстати rman тоже не все ловит. Повезло тут недавно убедится :))". Ясень пень, что только FTS и FFIS по всем объектам могут убедить тебя в исправности всех заЮзаных блоков БД. -- Andrei Kriushin (Oracle8/8i/9i OCP DBA), RDTEX J.S.C. Disclaimer: Opinions are of my own and not Это как раз были неиспользованные блоки после удаления сегмента, которые rman по умолчанию не проверяет ... |
|||
:
Нравится:
Не нравится:
|
|||
31.07.2004, 20:21 |
|
Почему так медленно SELECT COUNT(*)
|
|||
---|---|---|---|
#18+
АазПривет Мои два копейка: 1. сорри, всю неделю был занят по самое нехочу. Пропустил такую интересную дискусию. Даже прочитать времени не было. *_млинк_* Как там Аксапта, еле дышит? Молоко то дает? ... |
|||
:
Нравится:
Не нравится:
|
|||
31.07.2004, 20:24 |
|
Почему так медленно SELECT COUNT(*)
|
|||
---|---|---|---|
#18+
АазПривет Сории, забыл пункт 6. 2 "B." - Зарегистрировались бы ;-) Неужели такой ник уже занят? - В соавторы идите... Всего -- Andrei Kriushin (Oracle8/8i/9i OCP DBA), RDTEX J.S.C. Disclaimer: Opinions are of my own and not necessar(-il)y... Ладно, я зарегестрируюсь, но в соавторы вряд ли сгожусь, не DBA ведь я и до здешних ассов мне ну очень далеко. ... |
|||
:
Нравится:
Не нравится:
|
|||
02.08.2004, 04:39 |
|
Почему так медленно SELECT COUNT(*)
|
|||
---|---|---|---|
#18+
Да, дискуссия получилась длинная… В танном топике прозвучало несколько фамилий известных специалистов. Мне кажется, все-таки стоит дать некоторые комментарии. Стива Адамса я бы назвал экстремалом в достижении рекордной производительности Oracle-систем. Достаточно хорошо зная детали функционирования Oracle он настраивает систему на достижение максимальной производительности исходя из ее целей и имеющихся возможностей. Его аудитория состоит в основном из профессиональных DBA, которых интересуют самые тонкие моменты в функционировании их баз данных. Том Кайт все-таки более «попсовый автор», его аудитория – разработчики от начального до среднего уровня, которых обычно мало интересует, в какой момент времени DBWR сбрасывает на диск грязные буфера или сколько байт занимает одна строчка в ITL-таблице. Тем более охват его книг довольно широк и без определенных упрощений в данном случае тяжело обойтись. Детально описать затронутые темы в одной книге просто нереально, если конечно, автор не захочет сам попасть в книгу Гинесса. Рама Велпури – известен среди DBA как специалист в области backup & recovery. К сожалению, русскоязычный перевод его с Адколи книги не поддается никакой критике, а англоязычного издания у меня нет. Анализом приведенных в книге скриптов я не занимался (т.к. обычно использую свои собственные), но общие сценарии восстановления (во всяком случае те, на которые я обратил внимания) вроде описаны корректно. Книгу эту я читал очень бегло, поэтому мог не обратить внимание на серьезные ляпы. По поводу redo & commit уже практически все сказали Markelenkov с Ааз, Oracle newbie и Violina. Хотя, если вы настаиваете, «Фунтик» или кто-нибудь из DBGroup Consulting постарается поискать блох в этом опусе. Обещать точно не могу, уж больно много вы написали. Ребята сейчас все очень заняты, а я читаю медленно, практически по слогам, писать же вообще не могу По поводу exp, rman, dbv, db_block_checksum и др . Почему в этот список попал rman? Только потому что он регулярно запускается для своих целей и кроме всего прочего может ловить критические повреждения БД. Например, не далее, как в прошедшую пятницу при выполнении стандартного резервирования получаю: RMAN-00571: =========================================================== RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS =============== RMAN-00571: =========================================================== RMAN-03015: error occurred in stored script backup_al_all_disk RMAN-03006: non-retryable error occurred during execution of command: backup RMAN-07004: unhandled exception during command execution on channel d11 RMAN-10035: exception raised in RPC: ORA-19599: block number 24432 is corrupt in archived log F :\ORACLE\ORADATA\TWR\ARCHIVE\4474.ARC RMAN-10031: ORA-19583 occurred during call to DBMS_BACKUP_RESTORE.BACKUPPIECECREATE Ради интереса чуть позже проверяю этот файлик с помощью alter system, естественно получаю те же яйца: ORA-00368: checksum error in redo log block ORA-00353: log corruption near block 24432 change 26653313 time 07/15/2004 18:38:46 ORA-00334: archived log: 'F:\ORACLE\ORADATA\TWR\ARCHIVE\4474.ARC' Я не предлагаю вам rman в качестве панацеи от всех бед, я только говорю, что у него есть одна неплохая дополнительная особенность, которой иногда не грех воспользоваться. Если ваше приложение критично к ошибкам, установите кроме всего прочего db_block_checksum, время от времени запускайте dbv, почаще анализируйте alert.log (желательно, если это будет делать агент) и спите спокойно. Ааз2. 2 "Fucker" тынц Пару моментов. a) dbv не может проверять файлы >2Gb. Справедливости ради стоит заметить, что болезнью 31-го бита болели многие утилиты. Лень сейчас уточнять, но вроде это было много раньше. На металинке было много нот на эту тему тему, найти это не составит особых проблем. Вот свеженький пример проверки на 8i четырехгигового файла: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19.
Аазb) exp отдельно взятой схемы SYS в /dev/null чуток может помочь, но не затрагивает индексов по базовым таблицам словаря данных. Ню-ню… Экспорт отдельно взятой схемы sys не только «не затрагивает индексов по базовым таблицам словаря данных», он не затрагивает и сами базовые таблицы словаря . Точнее, затрагивает некоторое их количество косвенным образом во время своей работы. В этом несложно убедиться по отсутствию такой вот строчки в log’е, при выполнении экспорта sys’овской схемы: . about to export SYS's tables via Conventional Path ... нет там такого, как и последующего списка экпортируемых таблиц. Например у его брата system’а такая строчка есть: . about to export SYSTEM's tables via Conventional Path ... А если подходить серьезно, можно оттрасировать эти две сессии , а потом сравнить, что и как в них делается… или реально открыть выходные файлы и посмотреть, что же реально экспортируется для sys’а. Аазc) RMAN хреново тестирует (совсем не) только что импортнутые TTS. Надо их переводить в RW, потом опять в RO. Вся инфа на основе 8.1.7.4 и 9.2.0.5. До 10g-ки шаловливые ручки пока не дотянулись в желаемой степени. Насчет tts ничего не могу сказать, я их не так часто использовал, надо пробовать… АазPS. Ребятки, вы хоть понимаете, что уже накропали неплохую статью для Oramag? Недавно мне довелось побеседовать с Анатолием Бачиным (главред Oramag/ru). Он серьезно жалуется на отсутствие хороших материалов для публикаций. Слабо вам самоорганизоваться и заделать этот пробой? Про recovery должно получиться неплохо... Сколько я его знаю, он всегда на это жаловался. В последнее время все меньше появляется там что-то интересненькое. Все больше лажи всякого рода, после прочтения которой которой так и тянет на использование нецензурных выражений. Почему-то сразу вспомнилось, как Володя Бегун высказывал свое мнение по поводу одной из таких статей, потом Павел Лузанов о другой. Самое интересное, что им так и не удалось доказать что-то авторам. Так что, если всерьез соберетесь что-то писать, постарайтесь выдержать соответствующий уровень, чтобы потом не краснеть и оправдываться. Fucker PS.: Почему я так «накинулся» на exp? Просто до сих пор некоторые товарищи строят всю свою политику резервирования (как показало данное обсуждение и не только резервирования) только на нем. Хотя с ростом объемов применимость утилиты экспорта значительно снижается. Я уж молчу о периодически появляющихся багах вроде Note:199416.1 ALERT: Client Program May Give Incorrect Query Results (EXP Can Produce Dump File with Corrupted Data) Note: Oracle recommends that customers do not rely solely on EXP as a backup mechanism - customers are advised to always implement a proper physical backup strategy for databases. ... |
|||
:
Нравится:
Не нравится:
|
|||
02.08.2004, 17:54 |
|
Почему так медленно SELECT COUNT(*)
|
|||
---|---|---|---|
#18+
Да уж, знал ли Johnny Bombardir какую кашу заваривает :-) ... |
|||
:
Нравится:
Не нравится:
|
|||
04.08.2004, 11:28 |
|
Почему так медленно SELECT COUNT(*)
|
|||
---|---|---|---|
#18+
Всегда!!!!!Да уж, знал ли Johnny Bombardir какую кашу заваривает :-)Причем из топора ... |
|||
:
Нравится:
Не нравится:
|
|||
04.08.2004, 12:11 |
|
Почему так медленно SELECT COUNT(*)
|
|||
---|---|---|---|
#18+
oracle count как не крути работает медленно чем например в mysql ... |
|||
:
Нравится:
Не нравится:
|
|||
22.12.2011, 13:15 |
|
Почему так медленно SELECT COUNT(*)
|
|||
---|---|---|---|
#18+
ArmenAoracle count как не крути работает медленно чем например в mysql"Тонкий" троллинг с семилетней выдержкой. ... |
|||
:
Нравится:
Не нравится:
|
|||
22.12.2011, 13:20 |
|
Почему так медленно SELECT COUNT(*)
|
|||
---|---|---|---|
#18+
ArmenA, И уж тем более медленнее, чем подсчет строк в текстовом файле. ... |
|||
:
Нравится:
Не нравится:
|
|||
22.12.2011, 13:44 |
|
|
start [/forum/topic.php?all=1&fid=52&tid=1905960]: |
0ms |
get settings: |
10ms |
get forum list: |
14ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
360ms |
get topic data: |
13ms |
get forum data: |
3ms |
get page messages: |
163ms |
get tp. blocked users: |
2ms |
others: | 13ms |
total: | 586ms |
0 / 0 |