powered by simpleCommunicator - 2.0.39     © 2025 Programmizd 02
Форумы / Oracle [игнор отключен] [закрыт для гостей] / Почему так медленно SELECT COUNT(*)
133 сообщений из 133, показаны все 6 страниц
Почему так медленно SELECT COUNT(*)
    #32608406
Johnny Bombardir
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
У меня есть таблица TempTbl, в которую я загружаю около 600тыс. записей.

И запрос SELECT count(*) FROM TempTbl; длится около 10 сек. Почему так?
...
Рейтинг: 0 / 0
Почему так медленно SELECT COUNT(*)
    #32608427
Фотография stdio
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
А почему Вы считаете, что должно быть быстрее?
_______________
Alex
There are three kinds of people: those who can count and those who can't
...
Рейтинг: 0 / 0
Почему так медленно SELECT COUNT(*)
    #32608433
Александр К
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Попробуй SELECT COUNT(1)

Удачи.
...
Рейтинг: 0 / 0
Почему так медленно SELECT COUNT(*)
    #32608551
olek
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Александр КПопробуй SELECT COUNT(1)

Удачи.Миф
/topic/92459&hl=#675568
...
Рейтинг: 0 / 0
Почему так медленно SELECT COUNT(*)
    #32608576
Фотография killed
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
stdioА почему Вы считаете, что должно быть быстрее?
_______________
Alex
There are three kinds of people: those who can count and those who can't

Не, ну реально должно быть 7 секунд :))
...
Рейтинг: 0 / 0
Почему так медленно SELECT COUNT(*)
    #32608585
Johnny Bombardir
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Александр КПопробуй SELECT COUNT(1)
Удачи.

Нет, не помогло.
...
Рейтинг: 0 / 0
Почему так медленно SELECT COUNT(*)
    #32608614
olek
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Причиной может быть, например, высокий уровень hwm
/topic/95726&hl=
/topic/101861&hl=
...
Рейтинг: 0 / 0
Почему так медленно SELECT COUNT(*)
    #32608615
ujin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Johnny BombardirНет, не помогло.

По-моему SELECT COUNT(ROWID) - наилучший вариант.
...
Рейтинг: 0 / 0
Почему так медленно SELECT COUNT(*)
    #32608625
Alexander Dubrovsky
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
olek Александр КПопробуй SELECT COUNT(1)

Удачи.Миф
/topic/92459&hl=#675568
Не миф. Практика.
...
Рейтинг: 0 / 0
Почему так медленно SELECT COUNT(*)
    #32608659
olek
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Alexander DubrovskyНе миф. Практика.Было бы интересно разобраться в этом вопросе. Не могли бы Вы выложить тест, который бы это подтверждал?
О том того, что у count(1) или count(rowid) нет преимуществ, говорит тред на asktom, ссылка на которые приведена.
мне не удалось найти такой "хитрый" пример, который бы подтверждал недостатки count(*). Если у Вас есть - приведите, пожалуйста.
...
Рейтинг: 0 / 0
Почему так медленно SELECT COUNT(*)
    #32608747
Johnny Bombardir
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
В таблице 632581 записей, ,Процессор 800 МГц

count(*) - 14,860
count(1) - 15,015 сек
count(rowid) - 14,891 сек

Причем показания варьируются от запуска к запуску +/- 0,3-0,5
...
Рейтинг: 0 / 0
Почему так медленно SELECT COUNT(*)
    #32608763
Ora-мучитель
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
А так пробовали

count(log(2,4))
...
Рейтинг: 0 / 0
Почему так медленно SELECT COUNT(*)
    #32608775
Фотография denm
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
sum(1) еще попробуйте :)
...
Рейтинг: 0 / 0
Почему так медленно SELECT COUNT(*)
    #32608786
Ora-мучитель
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
2 denm

Нет, так точно быстрее не будет, надо

sum(2)/2
...
Рейтинг: 0 / 0
Почему так медленно SELECT COUNT(*)
    #32608807
Alexander Dubrovsky
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Ora-мучитель2 denm

Нет, так точно быстрее не будет, надо

sum(2)/2
На ноль дели, на ноль :)
...
Рейтинг: 0 / 0
Почему так медленно SELECT COUNT(*)
    #32608841
Ora-мучитель
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
2 Alexander Dubrovsky

Поделил на ноль.

ORA-01476: делитель равен нулю

Мне кажется на ноль делить нельзя ?!
...
Рейтинг: 0 / 0
Почему так медленно SELECT COUNT(*)
    #32608874
Destroy
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Ора-мучитель, ты ведь шутил, правда?
Как шутил сегодня Эш+ в топике про модуль.

Или может оракл корпу стоит задуматься о включении в доку "Math Concepts"?
...
Рейтинг: 0 / 0
Почему так медленно SELECT COUNT(*)
    #32608900
Ora-мучитель
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Кстати в топике "про модуль" тоже очевидные ошибки.
По-моему каждый знает, что "модуль" - функция унарная и работает так

MOD(-5) = MOD(5) = 5

А на счет деления на ноль, я "серьезно поделил".
Буду ждать атаки Fuckera.
...
Рейтинг: 0 / 0
Почему так медленно SELECT COUNT(*)
    #32608917
Destroy
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Ну, если быть занудой, то тот модуль, о котором ты говоришь пишется в математике как |-5|, а само слово "mod" встречается в алгебре только в смысле 30 mod 7 = 2 =)))
...
Рейтинг: 0 / 0
Почему так медленно SELECT COUNT(*)
    #32608930
Ora-мучитель
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Все! Я опозорен !
...
Рейтинг: 0 / 0
Почему так медленно SELECT COUNT(*)
    #32608962
Alexander Dubrovsky
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Ora-мучительВсе! Я опозорен !
лол
...
Рейтинг: 0 / 0
Почему так медленно SELECT COUNT(*)
    #32609205
Фотография slim
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Johnny BombardirУ меня есть таблица TempTbl, в которую я загружаю около 600тыс. записей.
И запрос SELECT count(*) FROM TempTbl; длится около 10 сек. Почему так?

Попробуй собрать статистику по таблице.
...
Рейтинг: 0 / 0
Почему так медленно SELECT COUNT(*)
    #32609324
aars
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
1.Долго по сравнению с чем?
2.Что значит "гружу данные", вроде разговор про запрос идет?
3.'Temp' - обычная таблица?
4. план выполнения (лучше трассировка) о чем говорит.
5. Если сразу после загрузки (изменения) данных сделать запрос, затрагивающий измененные данные, то часть вычислительных ресурсов уйдет на "очистку" блоков (строк, которые были ранее блокированы, информация об этом еще сидит в заголовке) (у Кайта есть кое что про это на стр 250).
...
Рейтинг: 0 / 0
Почему так медленно SELECT COUNT(*)
    #32609427
В.
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
В.
Гость
Ваша таблица должна быть надлежащим образом проиндексирована и проанализирована, тогда ваш count(*) будет быстрее. Но вообще count(*) - это не обчень быстрая операция. Что касается count(1), то это миф.
Посмотрите, какие у вас индексы и если их нет, то создайте на ключвые колонки, а потом проанализируйте таблицу
ANALYZE TABLE table_name COMPUTE STATISTICS FOR TABLE FOR ALL INDEXES FOR ALL INDEXED COLUMNS;
...
Рейтинг: 0 / 0
Почему так медленно SELECT COUNT(*)
    #32610052
sinoptic
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
DestroyНу, если быть занудой, то тот модуль, о котором ты говоришь пишется в математике как |-5|, а само слово "mod" встречается в алгебре только в смысле 30 mod 7 = 2 =)))
В дополнение: в математике пишется |-5|, а на языках как правило ABS(-5).
...
Рейтинг: 0 / 0
Почему так медленно SELECT COUNT(*)
    #32610082
Alexander Dubrovsky
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
olek Alexander DubrovskyНе миф. Практика.Было бы интересно разобраться в этом вопросе. Не могли бы Вы выложить тест, который бы это подтверждал?
О том того, что у count(1) или count(rowid) нет преимуществ, говорит тред на asktom, ссылка на которые приведена.
мне не удалось найти такой "хитрый" пример, который бы подтверждал недостатки count(*). Если у Вас есть - приведите, пожалуйста.

Ща на 9.2 создал большую таблицу - одинаково.
На 8.1.7 пробовали как-то - было быстрее count(1) или count(rowid).
...
Рейтинг: 0 / 0
Почему так медленно SELECT COUNT(*)
    #32610095
olek
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Судя по тестам автора топика, count(*) - самый быстрый:)
...
Рейтинг: 0 / 0
Почему так медленно SELECT COUNT(*)
    #32611478
B.
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
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> 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>
...
Рейтинг: 0 / 0
Почему так медленно SELECT COUNT(*)
    #32611484
Фотография Ааз
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
B.prostite chto pishu latinitsei - ya na rabote.
Помогает для работающих
...
Рейтинг: 0 / 0
Почему так медленно SELECT COUNT(*)
    #32611494
Фотография Markelenkov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
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.
SQL> connect scott/tiger
Connected.
SQL> select count(*) from emp;

  COUNT(*)
 ----------
 
         14 

SQL> select count(comm) from emp;

COUNT(COMM)
 -----------
 
           4 

SQL> select count(null) from emp;

COUNT(NULL)
 -----------
 
           0 

SQL> 


2 Fucker

Похоже труд был напрасен...
...
Рейтинг: 0 / 0
Почему так медленно SELECT COUNT(*)
    #32611551
B.
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
B.
Гость
Cпасибо,
это здорово,но немного непривычно. Попробую привыкнуть
...
Рейтинг: 0 / 0
Почему так медленно SELECT COUNT(*)
    #32611556
B.
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
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.
...
Рейтинг: 0 / 0
Почему так медленно SELECT COUNT(*)
    #32611560
Фотография Markelenkov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
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.

Все, что я хотел показать в своем примере - это реакция на выделенное мной Ваше категоричное высказывание.
...
Рейтинг: 0 / 0
Почему так медленно SELECT COUNT(*)
    #32611580
Oracle newbie
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
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.
SQL> desc t1;
 Name                                      Null?    Type
  ----------------------------------------- -------- ----------------------------
 
 ID                                        NOT NULL NUMBER
 S1                                                 VARCHAR2( 4000 )

SQL> set autot trace exp
SQL> select  /*+ FIRST_ROWS*/  count(s1) from t1;

Execution Plan
 ----------------------------------------------------------
 
    0       SELECT STATEMENT Optimizer=HINT: FIRST_ROWS (Cost= 207  Card= 1 
           Bytes= 2002 )

    1      0    SORT (AGGREGATE)
    2      1      TABLE ACCESS (FULL) OF 'T1' (Cost= 207  Card= 174224  Bytes=
           348796448 )




SQL>  select  /*+ FIRST_ROWS*/  count( 1 ) from t1;

Execution Plan
 ----------------------------------------------------------
 
    0       SELECT STATEMENT Optimizer=HINT: FIRST_ROWS (Cost= 4  Card= 1 )
    1      0    SORT (AGGREGATE)
    2      1      INDEX (FAST FULL SCAN) OF 'T1_UNIQ' (UNIQUE) (Cost= 4  Car
          d= 174224 )




SQL>  
.

Как видите я поменял всего лишь названия столбцов в count, но сделал возможным индексный доступ. Будьте осторожны с категоричными высказываниями.

Успехов.
...
Рейтинг: 0 / 0
Почему так медленно SELECT COUNT(*)
    #32611603
B.
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
B.
Гость
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.
...
Рейтинг: 0 / 0
Почему так медленно SELECT COUNT(*)
    #32611773
Калина
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
сижу, меряю, пока все одинаково , в рамках погрешности дла рабочего сервера!
...
Рейтинг: 0 / 0
Почему так медленно SELECT COUNT(*)
    #32611791
olek
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Калинасижу, меряю, пока все одинаково , в рамках погрешности дла рабочего сервера!Вы tkprof'ом сравните: что там различается?
Сторонники count(1)/count(rowid) говорят, что в этом случае должно быть меньше рекурсивных вызовов, нежели при использовании count(*)
Еще интересно было бы узнать, сколько времени (в процентном отношении) тратиться на рекурсивные вызовы и разбор в целом.
...
Рейтинг: 0 / 0
Почему так медленно SELECT COUNT(*)
    #32611805
Alexander Dubrovsky
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
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>

Я это знаю. И для достоверности я выполнял каждый оператор по несколько раз подряд.
...
Рейтинг: 0 / 0
Почему так медленно SELECT COUNT(*)
    #32611927
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
olekСторонники count(1)/count(rowid) говорят, что в этом случае должно быть меньше рекурсивных вызовов, нежели при использовании count(*)
Кому должно? Первый рекурсивный вызов что в случае count(1), что в случае count(*) - поиск not null индекса по этой таблице. И если такой есть - никаких других уже не нужно. А такой как правило есть.
...
Рейтинг: 0 / 0
Почему так медленно SELECT COUNT(*)
    #32611967
Oracle newbie
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
2 B.
Извините, но мне показалось что фразой
"(*) ili (1), or (8), ili chto ugodno - ne immet znachenia." вы пытались сказать что не имеет значение что стоит в count. Я показал что изменения столбцов в count меняет план с FTS на FFS, если есть PK и используется CBO.
Если же вы пытались сказать что не имеет значения между * и литералом, то прошу прощения.

Успехов.
...
Рейтинг: 0 / 0
Почему так медленно SELECT COUNT(*)
    #32611972
olek
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
softwarerВот сцылка на "обоснование" преимуществ count(1)/count(rowid). Источник - (известная) книшка "Подготовка сертифицированных дба" (по тынцу - цитата из оригинального англоязычного издания).
Ваше мнение?

зы. я мнение автора книшки считаю не обоснованным.
...
Рейтинг: 0 / 0
Почему так медленно SELECT COUNT(*)
    #32612122
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
olekВаше мнение?
Обоснованием могут быть trace-ы применительно к конкретной версии Oracle либо аналогичные данные. Необходимости разрешать звездочку по словарю данных я не вижу, то есть это место, которое может быть оптимизировано.

Насколько я помню, в документации по восьмерке утверждалось, что писать count(*) больше незачем. А ораклоидам я склонен верить до тех пор, пока явно не убеждаюсь в обратном.

Сейчас я сделал на 9.0.2 trace для select count(*). Запроса, который искал бы поля, я в файле не вижу. Объективности ради - запроса, который искал бы индекс тоже не вижу ;-)
...
Рейтинг: 0 / 0
Почему так медленно SELECT COUNT(*)
    #32612201
Фотография Markelenkov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
B.Eshe raz.

(*), (1), (8), (6)...etc - eto uslovnie znachki dla count na vse zapisi...

Не сходить ли почитать документацию?
...
Рейтинг: 0 / 0
Почему так медленно SELECT COUNT(*)
    #32612263
Oracle newbie
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
2 softwarer
смотреть не sql трейс надо для того чтобы увидеть как селекается какой либо индекс . только CBO может использовать FFS поэтому и трассируй CBO
alter session set events='10053 trace name context forever, level 1'
и в трайсе будет видно какой CBO выбрал путь : индексный или FTS

Успехов.
...
Рейтинг: 0 / 0
Почему так медленно SELECT COUNT(*)
    #32612358
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Oracle newbieи в трайсе будет видно какой CBO выбрал путь : индексный или FTS
Не. План запроса select count(*) и так виден :-) Вопрос был в том, какие рекурсивные запросы выполняются при этом - то есть не заставляет ли count(*) делать дополнительный ненужный select from col$. trace, который я снял, не дает однозначного ответа на этот вопрос.
...
Рейтинг: 0 / 0
Почему так медленно SELECT COUNT(*)
    #32613127
Фотография Fucker
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
softwarer Oracle newbieи в трайсе будет видно какой CBO выбрал путь : индексный или FTS
Не. План запроса select count(*) и так виден :-) Вопрос был в том, какие рекурсивные запросы выполняются при этом - то есть не заставляет ли count(*) делать дополнительный ненужный select from col$. trace, который я снял, не дает однозначного ответа на этот вопрос.

Пришел мужик в секс-шоп купить надувную бабу. Продавец подобрал ему самую навороченную:
из латекса, девственница с вибратором, в общем - полный фарш. Ушел мужик довольный.

На следующий день приносит:
- вот чек, упаковка примите назад
- а что внешность не нравится?
- да нет, очень нравится
- девственница?
- да
- ну а в чем тогда дело?
- НЕ ДАЛА!




Честно, я не издеваюсь, просто я не понимаю, как можно там не найти однозначного ответа.

В чем у тебя проблема?


Fucker
...
Рейтинг: 0 / 0
Почему так медленно SELECT COUNT(*)
    #32613251
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
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.
/u5/oracle/9.2.0/admin/OLAP/udump/olap_ora_880.trc
Oracle9i Enterprise Edition Release 9.2.0.4.0 - 64bit Production

*** SESSION ID:(46.106) 2004-07-20 11:44:09.473
APPNAME mod='PL/SQL Developer' mh=1190136663 act='Command Window - New' ah=254318129
=====================
PARSING IN CURSOR #1 len=36 dep=0 uid=0 oct=42 lid=0 tim=7116418302 hv=659427939 ad='90cadd80'
alter session set sql_trace = true
END OF STMT
EXEC #1:c=0,e=187,p=0,cr=0,cu=0,mis=1,r=0,dep=0,og=4,tim=7116406214
=====================
PARSING IN CURSOR #2 len=61 dep=0 uid=0 oct=47 lid=0 tim=7116426547 hv=2707513792 ad='8c884a38'
begin :id := sys.dbms_transaction.local_transaction_id; end;
END OF STMT
PARSE #2:c=0,e=358,p=0,cr=0,cu=0,mis=0,r=0,dep=0,og=4,tim=7116426541
EXEC #2:c=0,e=160,p=0,cr=0,cu=0,mis=0,r=1,dep=0,og=4,tim=7116426882
=====================
PARSING IN CURSOR #2 len=61 dep=0 uid=0 oct=47 lid=0 tim=7116432221 hv=2707513792 ad='8c884a38'
begin :id := sys.dbms_transaction.local_transaction_id; end;
END OF STMT
PARSE #2:c=0,e=152,p=0,cr=0,cu=0,mis=0,r=0,dep=0,og=4,tim=7116432216
EXEC #2:c=0,e=91,p=0,cr=0,cu=0,mis=0,r=1,dep=0,og=4,tim=7116432409
*** 2004-07-20 11:44:21.043
=====================
PARSING IN CURSOR #3 len=21 dep=0 uid=0 oct=3 lid=0 tim=7127705487 hv=3293499221 ad='8c8a3f80'
select 'x' from dual
END OF STMT
PARSE #3:c=0,e=171,p=0,cr=0,cu=0,mis=0,r=0,dep=0,og=4,tim=7127705472
EXEC #3:c=0,e=115,p=0,cr=0,cu=0,mis=0,r=0,dep=0,og=4,tim=7127705826
FETCH #3:c=0,e=159,p=0,cr=3,cu=0,mis=0,r=1,dep=0,og=4,tim=7127706678
STAT #3 id=1 cnt=1 pid=0 pos=1 obj=222 op='TABLE ACCESS FULL DUAL (cr=3 r=0 w=0 time=131 us)'
=====================
PARSING IN CURSOR #3 len=40 dep=1 uid=0 oct=3 lid=0 tim=7127716828 hv=3360804353 ad='8d809900'
select default$ from col$ where rowid=:1
END OF STMT
PARSE #3:c=0,e=801,p=0,cr=0,cu=0,mis=1,r=0,dep=1,og=0,tim=7127716820
EXEC #3:c=0,e=579,p=0,cr=0,cu=0,mis=0,r=0,dep=1,og=4,tim=7127717652
FETCH #3:c=0,e=66,p=0,cr=2,cu=0,mis=0,r=1,dep=1,og=4,tim=7127717782
STAT #3 id=1 cnt=1 pid=0 pos=1 obj=21 op='TABLE ACCESS BY USER ROWID COL$ (cr=1 r=0 w=0 time=42 us)'
=====================
PARSING IN CURSOR #1 len=42 dep=0 uid=0 oct=3 lid=0 tim=7127720513 hv=2750412614 ad='90cacd10'
select count(*) from gkhstar.fc_payments
END OF STMT
PARSE #1:c=0,e=5504,p=0,cr=2,cu=0,mis=1,r=0,dep=0,og=4,tim=7127720505
EXEC #1:c=0,e=71,p=0,cr=0,cu=0,mis=0,r=0,dep=0,og=4,tim=7127720702
FETCH #1:c=1560000,e=1645815,p=3544,cr=3555,cu=0,mis=0,r=1,dep=0,og=4,tim=7129367252
=====================
PARSING IN CURSOR #2 len=61 dep=0 uid=0 oct=47 lid=0 tim=7129382574 hv=2707513792 ad='8c884a38'
begin :id := sys.dbms_transaction.local_transaction_id; end;
END OF STMT
PARSE #2:c=0,e=447,p=0,cr=0,cu=0,mis=0,r=0,dep=0,og=4,tim=7129382567
EXEC #2:c=0,e=296,p=0,cr=0,cu=0,mis=0,r=1,dep=0,og=4,tim=7129383079
=====================
PARSING IN CURSOR #2 len=61 dep=0 uid=0 oct=47 lid=0 tim=7129388483 hv=2707513792 ad='8c884a38'
begin :id := sys.dbms_transaction.local_transaction_id; end;
END OF STMT
PARSE #2:c=0,e=148,p=0,cr=0,cu=0,mis=0,r=0,dep=0,og=4,tim=7129388478
EXEC #2:c=0,e=101,p=0,cr=0,cu=0,mis=0,r=1,dep=0,og=4,tim=7129388684
=====================
PARSING IN CURSOR #3 len=21 dep=0 uid=0 oct=3 lid=0 tim=7134797204 hv=3293499221 ad='8c8a3f80'
select 'x' from dual
END OF STMT
PARSE #3:c=0,e=191,p=0,cr=0,cu=0,mis=0,r=0,dep=0,og=4,tim=7134797187
EXEC #3:c=0,e=65,p=0,cr=0,cu=0,mis=0,r=0,dep=0,og=4,tim=7134797443
FETCH #3:c=0,e=203,p=0,cr=3,cu=0,mis=0,r=1,dep=0,og=4,tim=7134798460
STAT #1 id=1 cnt=1 pid=0 pos=1 obj=0 op='SORT AGGREGATE (cr=3555 r=3544 w=0 time=1645744 us)'
STAT #1 id=2 cnt=1689085 pid=1 pos=1 obj=101728 op='INDEX FAST FULL SCAN ACT_PMNT_FK_I (cr=3555 r=3544 w=0 time=1231510 us)'
STAT #3 id=1 cnt=1 pid=0 pos=1 obj=222 op='TABLE ACCESS FULL DUAL (cr=3 r=0 w=0 time=173 us)'
=====================
PARSING IN CURSOR #1 len=37 dep=0 uid=0 oct=42 lid=0 tim=7134807115 hv=3676133329 ad='90a79a68'
alter session set sql_trace = false
END OF STMT
PARSE #1:c=0,e=562,p=0,cr=0,cu=0,mis=1,r=0,dep=0,og=4,tim=7134807109
EXEC #1:c=0,e=115,p=0,cr=0,cu=0,mis=0,r=0,dep=0,og=4,tim=7134807325
...
Рейтинг: 0 / 0
Почему так медленно SELECT COUNT(*)
    #32613644
B.
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
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

интересно было бы услышать от вас что-нибудь по существу
...
Рейтинг: 0 / 0
Почему так медленно SELECT COUNT(*)
    #32613666
Фотография Fucker
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
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.
select 

ts#,file#,block#,nvl(bobj#, 0 ),nvl(tab#, 0 ),intcols,nvl(clucols, 0 ),audit$,flags,pctfree$,pctused$,initrans,maxtrans,rowcnt,blkcnt,empcnt,avgspc,

chncnt,avgrln,analyzetime, samplesize,cols,property,nvl(degree, 1 ),nvl(instances, 1 ),avgspc_flb,flbcnt,kernelcols,nvl(trigflag, 

 0 ),nvl(spare1, 0 ),nvl(spare2, 0 ),spare4,nvl(spare3, 0 ) from tab$ where obj#=: 1 
value= 30413 

select i.obj#,i.ts#,i.file#,i.block#,i.intcols,i.type#,i.flags, i.property,i.pctfree$,i.initrans,i.maxtrans,i.blevel,i.leafcnt,i.distkey, 

i.lblkkey,i.dblkkey,i.clufac,i.cols,i.analyzetime,i.samplesize,i.dataobj#, 

nvl(i.degree, 1 ),nvl(i.instances, 1 ),i.rowcnt,mod(i.pctthres$, 256 ),i.indmethod#,i.trunccnt,nvl(c.unicols, 0 ),nvl(c.deferrable#+c.valid#, 0 ), 

nvl(i.spare1,i.intcols),i.spare4,spare2,decode(i.pctthres$,null,null, mod(trunc(i.pctthres$/ 256 ), 256 )) from ind$ i, (select enabled, min(cols) 

unicols, min(to_number(bitand(defer, 1 ))) deferrable#, min(to_number(bitand(defer, 4 ))) valid# from cdef$ where obj#=: 1  and enabled >  1  group by 

enabled) c where i.obj#=c.enabled(+) and i.bo#=: 1 
value= 30413 

select pos#,intcol#,col#,spare1 from icol$ where obj#=: 1 
value= 30414 

select 

name,intcol#,segcol#,type#,length,nvl(precision#, 0 ),decode(type#, 2 ,nvl(scale,- 127  /*MAXSB1MINAL*/ ), 178 ,scale, 179 ,scale, 180 ,scale, 181 ,scale, 182 ,

scale, 183 ,scale, 231 ,scale, 0 ),null$,fixedstorage,nvl(deflength, 0 ),default$,rowid,col#,property, charsetid,charsetform,spare1,spare2 from col$ 

where obj#=: 1  order by intcol#
value= 30413 

select 

name,intcol#,segcol#,type#,length,nvl(precision#, 0 ),decode(type#, 2 ,nvl(scale,- 127  /*MAXSB1MINAL*/ ), 178 ,scale, 179 ,scale, 180 ,scale, 181 ,scale, 182 ,

scale, 183 ,scale, 231 ,scale, 0 ),null$,fixedstorage,nvl(deflength, 0 ),default$,rowid,col#,property, charsetid,charsetform,spare1,spare2 from col$ 

where obj#=: 1  order by intcol#
value= 30413 

select con#,obj#,rcon#,enabled,nvl(defer, 0 ) from cdef$ where robj#=: 1 
value= 30413 

select con#,type#,condlength,intcols,robj#,rcon#,match#,refact,nvl(enabled, 0 ),rowid,cols,nvl(defer, 0 ),mtime,nvl(spare1, 0 ) from cdef$ where 

obj#=: 1 
value= 30413 

select intcol#,nvl(pos#, 0 ),col# from ccol$ where con#=: 1 
value= 7452 

В таких случаях имеет смысл выдавать кроме всего прочего bind value, которые позволят получить те же результаты, что получил Oracle при
выполнении тестов.




Fucker
...
Рейтинг: 0 / 0
Почему так медленно SELECT COUNT(*)
    #32614502
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
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Я не буду приводить целиком свой трейс, но вот несколько ключевых фрагментов с рекурсивными вызовами:
В общем, мне надо углубляться в настройку вывода трейсов.
...
Рейтинг: 0 / 0
Почему так медленно SELECT COUNT(*)
    #32614621
Фотография Markelenkov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
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(*), поэтому данный вопрос не обсуждаю. Каждый (как мне наивно кажется) способен проверить этот факт.
...
Рейтинг: 0 / 0
Почему так медленно SELECT COUNT(*)
    #32615341
В.
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
В.
Гость
Марленков, никаким! Это надо было мне запостить туда, где про RBS и где какие-то факеры почему-то вопят ужасно, словно я у них последний кусок хлеба изо рта вырываю... - кошмар, одной рукой делаю одно, другой другое, а сейчас вот убегаю на работу. Sorry за накладку.
...
Рейтинг: 0 / 0
Почему так медленно SELECT COUNT(*)
    #32615999
Фотография Gluk (Kazan)
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
OffTopic:
Кайт Юлий Цезарь
...
Рейтинг: 0 / 0
Почему так медленно SELECT COUNT(*)
    #32616154
bokarev
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
собери статистику по таблице, будет быстрее работать
...
Рейтинг: 0 / 0
Почему так медленно SELECT COUNT(*)
    #32616240
Oracle newbie
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
момент 1
если нет PK -- то FULL TABLE SCAN от сбора статистики не работает быстрее.

момент 2 . Если же PK есть то для использования FFS по PK нужно сделать так, чтобы работал CBO .
Для этого необязательно собирать статистику, можно указать optimizer_goal для сессии или хинт указывающий optimizer approach (FIRST_ROWS,ALL_ROWS)

Regards.
...
Рейтинг: 0 / 0
Почему так медленно SELECT COUNT(*)
    #32616320
Фотография Я и ёжик
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
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.
Connected to:
Oracle8i Enterprise Edition Release  8 . 1 . 7 . 4 . 0  - Production
With the Partitioning option
JServer Release  8 . 1 . 7 . 4 . 0  - Production

SQL> drop table test;

Table dropped.

SQL> create table test as select * from all_objects;

Table created.

SQL>  alter table test modify object_id not null;
 alter table test modify object_id not null
                         *
ERROR at line  1 :
ORA- 01442 : column to be modified to NOT NULL is already NOT NULL

 -- просто  индекс PK не объявлен
 
SQL>   create index test_i on test( object_id);

Index created.


SQL> set autotrace traceonly exp;
SQL>  select count(*) from test;

Execution Plan
 ----------------------------------------------------------
 
    0       SELECT STATEMENT Optimizer=CHOOSE
    1      0    SORT (AGGREGATE)
    2      1      TABLE ACCESS (FULL) OF 'TEST'



SQL> analyze table test compute statistics for table;

Table analyzed.

SQL>  select count(*) from test;

Execution Plan
 ----------------------------------------------------------
 
    0       SELECT STATEMENT Optimizer=CHOOSE (Cost= 4  Card= 1 )
    1      0    SORT (AGGREGATE)
    2      1      INDEX (FAST FULL SCAN) OF 'TEST_I' (NON-UNIQUE) (Cost= 4 
          Card= 25729 )

...
Рейтинг: 0 / 0
Почему так медленно SELECT COUNT(*)
    #32616370
Oracle newbie
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Да, о NOT NULL я и не подумал.
...
Рейтинг: 0 / 0
Почему так медленно SELECT COUNT(*)
    #32616392
Фотография Fucker
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
В.Марленков, никаким! Это надо было мне запостить туда, где про RBS и где какие-то факеры почему-то вопят ужасно, словно я у них последний кусок хлеба изо рта вырываю... - кошмар, одной рукой делаю одно, другой другое, а сейчас вот убегаю на работу. Sorry за накладку.

А второй рукой ты этот последний кусок к себе в рот запихиваешь? Я его достаточно хорошо разжевал?

Ты бы попросил, я б тебе купил пирожок (с котятами), а то бедняжка... голодный... на работу... бегом....



Fucker
...
Рейтинг: 0 / 0
Почему так медленно SELECT COUNT(*)
    #32616492
Фотография Markelenkov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
2 Fucker

Я все понял! Понял! Понял! Fucker - американский зас л анец, посланый для развала оборонной мощи России ;-)
...
Рейтинг: 0 / 0
Почему так медленно SELECT COUNT(*)
    #32616660
Фотография Fucker
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Markelenkov2 Fucker

Я все понял! Понял! Понял! Fucker - американский зас л анец, посланый для развала оборонной мощи России ;-)

Вы меня обижаете ;-), в свое время я тоже немало сделал для укрепления этой самой мощи.


А по поводу имени, ну что я могу сказать?

Fucker - это ведь не только "распутник", "негодяй", "прохвост", "хрен", "говнюк", "дурачок" и "ёб%рь"
но и "друг", "чувак", "мужик" и даже "красавец"


Так что, наверно таким я и останусь. Ну, предположим, выберу я себе другое имя, а завтра оно еще кому-то не понравится...

Видно так и помирать мне Fucker\'ом...


Fucker

PS.: И появится тогда killed Fucker ;-)
...
Рейтинг: 0 / 0
Почему так медленно SELECT COUNT(*)
    #32616679
Destroy
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Кстати, Пинк свою собачку так же назвала. Говорит, буду лежать на пляжу и звать: Hey, Fucker! Fucker!, все мужчины будут оборачиваться, а я им: Да не ты! Не ты!
...
Рейтинг: 0 / 0
Почему так медленно SELECT COUNT(*)
    #32616681
Фотография Markelenkov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Fucker Markelenkov2 Fucker

Я все понял! Понял! Понял! Fucker - американский зас л анец, посланый для развала оборонной мощи России ;-)

Вы меня обижаете ;-), в свое время я тоже немало сделал для укрепления этой самой мощи.


А по поводу имени, ну что я могу сказать?

Fucker - это ведь не только "распутник", "негодяй", "прохвост", "хрен", "говнюк", "дурачок" и "ёб%рь"
но и "друг", "чувак", "мужик" и даже "красавец"


Так что, наверно таким я и останусь. Ну, предположим, выберу я себе другое имя, а завтра оно еще кому-то не понравится...

Видно так и помирать мне Fucker\'ом...


Fucker

PS.: И появится тогда killed Fucker ;-)
Имя-то мне нравицца ;-)
Подпись - не нравицца. Лучше подписываться типа

Fucker, 30306

Искать по форуму станет удобно, оборонная мощь государства укрепится ;-)
...
Рейтинг: 0 / 0
Почему так медленно SELECT COUNT(*)
    #32616759
Фотография killed
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
по моему в молоко. Совсем разные стили
...
Рейтинг: 0 / 0
Почему так медленно SELECT COUNT(*)
    #32616953
Фотография Fucker
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
MarkelenkovИмя-то мне нравицца ;-)
Подпись - не нравицца. Лучше подписываться типа

Fucker, 30306

А так низззя, это чужой номер. Нельзя обижать товарищей ;-)


Fucker

PS.: Это уже наверно третья попытка "снять маски". Как нас можно спутать, не понимаю, мы ведь совсем непохожи. Он усатый с щечками, а я свои усы уже лет десять как сбрил. И, кстати, 30306 оборонную мощь России не укреплял


PPS.: Вот и killed подтверждает ;-)
...
Рейтинг: 0 / 0
Почему так медленно SELECT COUNT(*)
    #32617287
Фотография killed
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
зато я укреплял красную кнопку целых секунды три держал
...
Рейтинг: 0 / 0
Почему так медленно SELECT COUNT(*)
    #32617325
Фотография Markelenkov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
FuckerА так низззя, это чужой номер. Нельзя обижать товарищей ;-)
Ладно, не добиться мине щастья, не уговорить ;-)
Бум обходиться без поиска...
...
Рейтинг: 0 / 0
Почему так медленно SELECT COUNT(*)
    #32617692
B.
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
B.
Гость
Fucker - это ведь не только "распутник", "негодяй", "прохвост", "хрен", "говнюк", "дурачок" и "ёбрь"
но и "друг", "чувак", "мужик" и даже "красавец"

Тут я уже не могу молчать, потому что ладно еще, когда ты ржал над тривиальными и вполне известными вещами (я уверена, что ты умный человек, любящий свою профессию и свои "skills" ты разовьешь), но ты затронул язык, а язык это святое. Я не знаю, кто тебе сказал, что твое имя Fucker имеет все эти значения, но они сказали тебе неправду, не верь им, потому что из перечисленных тобою значений Fucker имеет лишь два и они суть "ёбрь" и "говнюк" Если ты мне как обычно не веришь зайди вот сюда и проверь: http://dictionary.reference.com/ Можешь также сходить на сайт Oxford, у меня сейчас нет времени тебе искать этот сайт, сам найдешь.
Ну ладно, побежала я опять на работу.
Не обижайся, ладно?
Всего тебе самого доброго.
...
Рейтинг: 0 / 0
Почему так медленно SELECT COUNT(*)
    #32617702
Oracle newbie
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
а по русски, "еб%рь" вполне может быть и "красавцем" . Хотя кто поймет этих женщин?

Regards.
...
Рейтинг: 0 / 0
Почему так медленно SELECT COUNT(*)
    #32617738
Фотография Markelenkov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
B.Fucker - это ведь не только "распутник", "негодяй", "прохвост", "хрен", "говнюк", "дурачок" и "ёбрь"
но и "друг", "чувак", "мужик" и даже "красавец"

Тут я уже не могу молчать, потому что ладно еще, когда ты ржал над тривиальными и вполне известными вещами (я уверена, что ты умный человек, любящий свою профессию и свои "skills" ты разовьешь), но ты затронул язык, а язык это святое. Я не знаю, кто тебе сказал, что твое имя Fucker имеет все эти значения, но они сказали тебе неправду, не верь им, потому что из перечисленных тобою значений Fucker имеет лишь два и они суть "ёбрь" и "говнюк" Если ты мне как обычно не веришь зайди вот сюда и проверь: http://dictionary.reference.com/ Можешь также сходить на сайт Oxford, у меня сейчас нет времени тебе искать этот сайт, сам найдешь.
Ну ладно, побежала я опять на работу.
Не обижайся, ладно?
Всего тебе самого доброго.
Оказывается, В. - дама :-O
Учтем-с, бум помяхше, потоньше, повежливше...

P.S. Есть женщины в американских селеньях... Гы-ы-ы-ы
...
Рейтинг: 0 / 0
Почему так медленно SELECT COUNT(*)
    #32617802
Фотография Fucker
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
B.Fucker - это ведь не только "распутник", "негодяй", "прохвост", "хрен", "говнюк", "дурачок" и "ёбрь"
но и "друг", "чувак", "мужик" и даже "красавец"

Тут я уже не могу молчать, потому что ладно еще, когда ты ржал над тривиальными и вполне известными вещами (я уверена, что ты умный человек, любящий свою профессию и свои "skills" ты разовьешь), но ты затронул язык, а язык это святое. Я не знаю, кто тебе сказал, что твое имя Fucker имеет все эти значения, но они сказали тебе неправду, не верь им, потому что из перечисленных тобою значений Fucker имеет лишь два и они суть "ёбрь" и "говнюк" Если ты мне как обычно не веришь зайди вот сюда и проверь: http://dictionary.reference.com/ Можешь также сходить на сайт Oxford, у меня сейчас нет времени тебе искать этот сайт, сам найдешь.
Ну ладно, побежала я опять на работу.
Не обижайся, ладно?
Всего тебе самого доброго.

Спасибо за пожелания, а на что мне обижаться? Я общался с существом, которое, как я предполагал, "остроконечного пола" (классическая фраза Бориса Виана), а после общения выснилось, что это не так.

Одно из двух:
- либо оно тщательно маскировалось, используя лингвистические уловки, не позволяющие определить пол собеседника;
- либо оно решило изменить пол после очередного общения с Fucker'ом. 8-)))

Мои "skills" и не только "skills" я и так постоянно развиваю. В одном из постов, обращенных мне, как-то прозвучало пожелание прочитать книги Т. Кайта и Oracle'вую документацию. Сейчас я все-таки решил сказать пару слов по этому поовду...

Я не строю из себя супер-муперного крутого спеца во всем, что связано с Oracle. Я такой, какой я есть, что-то я знаю лучше, что-то хуже, но мои познания в некоторых основных областях позволяют мне без всяких проблем находить десятками недочеты и ошибки как в книгах об Oracle (у того же Тома, хотя уровень его книг на порядок выше всех остальных, с которыми я сталкивался, ошибок значительно меньше, нежели у других, но они все равно есть), так и в стандартной документации. В основном это связано с тем, что при переходе от версии к версии Oracle документацию как обычно оставляют "на потом". Иногда связано с умышленными (но не совсем корректными) попытками скрытия деталей функционирования Oracle... и т.д. и т.п.

И в каждом из таких случаев я безо всяких проблем фактами и экспериментами доказать свою правоту. Было бы время...

Так вот мне стало интересно, из чего конкретно вытекает такой вывод, что мне стоит почитать эти источники? Буду очень признателен, если получу точный, формальный ответ.

Желательно без лишней пространной болтовни на тему космических кораблей, бороздящих просторы....


Fucker
...
Рейтинг: 0 / 0
Почему так медленно SELECT COUNT(*)
    #32617817
B.
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
B.
Гость
Спасибо за пожелания, а на что мне обижаться? Я общался с существом, которое, как я предполагал, "остроконечного пола" (классическая фраза Бориса Виана), а после общения выснилось, что это не так.

Одно из двух:
- либо оно тщательно маскировалось, используя лингвистические уловки, не позволяющие определить пол собеседника;
- либо оно решило изменить пол после очередного общения с 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?
...
Рейтинг: 0 / 0
Почему так медленно SELECT COUNT(*)
    #32619220
Фотография Fucker
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
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.: По поводу «чужих ошибок».
Завтра, послезавтра постараюсь перечитать несколько глав и привести несколько примеров. Первый будет связан с использованием утилиты экспорт.
...
Рейтинг: 0 / 0
Почему так медленно SELECT COUNT(*)
    #32619409
Фотография Markelenkov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
2 В.

Не могу похвастаться, что нахожу десятками ошибки у Тома (его сайт, кстати, редко читаю), но единичные случаи есть. Часть из них скорее всего связана с описками и опечатками, часть - с нежеланием углубляться в дебри и т.д.

Ошибаются все, и это нормально.
...
Рейтинг: 0 / 0
Почему так медленно SELECT COUNT(*)
    #32619458
В.
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
В.
Гость
Спасибо за объяснения. Я начинаю потихоньку разбиратьтся с переводной терминологией, а то вначале очень трудно было понимать, о чем идет речь. Вообще мне нравится этот форум. Наши раньше тоже были ничего ничего , особенно этот: http://www.orafaq.com/msgboard/index.htm, но сейчас все меньше и меньше интересных вопросов. То ли все все поняли, то ли Оракл действительно на спад идет (надеюсь, что нет). В день появляется всего несколько вопросов, из которых редко бывают интересные. А здесь интересно.

Вот это у меня не открывается, вылезает что-то другое:
http://www.sql.ru/images/laugh.gif

Попробую на работе открыть.

Завтра, послезавтра постараюсь перечитать несколько глав и привести несколько примеров. Первый будет связан с использованием утилиты экспорт.[/quot]

Если завтра у нас не будет дождя, который обещают, то я уеду на выходные за город, поэтому очень прошу на всякий случай или не публиковать это до понедельника, или в понедельник освежить, а то все затеряется.

Всего доброго,
В.
...
Рейтинг: 0 / 0
Почему так медленно SELECT COUNT(*)
    #32619490
В.
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
В.
Гость
Markelenkov2 В.

Не могу похвастаться, что нахожу десятками ошибки у Тома (его сайт, кстати, редко читаю), но единичные случаи есть. Часть из них скорее всего связана с описками и опечатками, часть - с нежеланием углубляться в дебри и т.д.

Ошибаются все, и это нормально.

Поскольку я не DBA, то могу лишь сказать, что Том иногда "ошибается" в каком-нибудь маленьком синтаксисе, поскольку он все пишет на ходу, но обычно он быстренько делает Oops! И поправляется. Ну и помню как-то раз он очень красиво "перегнул" - написал как узнавать, есть ли запись в таблице без дорогого SELECT count(*), используя модель WHERE EXISTS(SELECT NULL FROM dual WHERE ...). Красиво, повторяю, получилось, но когда я его спросила на конференции не тот же самый результат в смысле "дороговизны" и скорости если SELECT count(*)....WHERE rownum<2, он засмеялся и сказал, что это то же самое. А вообще-то он гений.
А какие ошибки вы заметили?
...
Рейтинг: 0 / 0
Почему так медленно SELECT COUNT(*)
    #32619615
Фотография Markelenkov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
В.А вообще-то он гений.
Ну это уж чересчур! Он, конечно, гуру, но не гений, imho. Уверяю Вас, например, если бы у многих из тусующихся на этом форуме была возможность заниматься СУБД и Oracle в частности столько времени, сколько у Тома, да плюс его возможности, связанные с приближенностью к Oracle Corp. и прочие его преимущества, связанные с языком, страной проживания и т.д - думаю, конкуренцию Тому могли бы составить многие. В силу объективных обстоятельств мы поставлены в гораздо менее выгодные условия, чем тот же Том.


В.А какие ошибки вы заметили?
Я их не запоминаю. Например, помню, что в его книге (в русском переводе) "Expert One-on-One Oracle" он пишет, что размер ITL в блоке 23 байта. Страницу назвать по памяти не могу, искать лень (в русском переводе книга разбита на 2 тома). Помню это потому, что проверял. Может быть, опечатка. Видел это же число еще у нескольких авторов - гипноз?

Дампы блоков и, например, Стив Адамс здесь и здесь с Кайтом не согласны.

Кстати, Адамс на мой взгляд , будет покруче Кайта и я ему верю больше. При этом он, кстати, никогда не работал в Oracle Corp.

Поэтому Адамс поближе к гениальности, imho. Хотя тоже, бывает, ошибается ;-)
...
Рейтинг: 0 / 0
Почему так медленно SELECT COUNT(*)
    #32619654
DBGroup Consulting
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
23 байта - это стандартная цифра из документации. Думаю, Том не делал дампы, чтобы ее проверить. В любом случае, у них у всех есть свои выходы на Oracle Corp., поскольку многие вещи нельзя трактовать однозначно без того, чтобы подглядеть код.

Успехов,
DBGroup Consulting
...
Рейтинг: 0 / 0
Почему так медленно SELECT COUNT(*)
    #32619799
В.
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
В.
Гость
Markelenkov[quot В.]А вообще-то он гений.
Ну это уж чересчур! Он, конечно, гуру, но не гений, imho. Уверяю Вас, например, если бы у многих из тусующихся на этом форуме была возможность заниматься СУБД и Oracle в частности столько времени, сколько у Тома, да плюс его возможности, связанные с приближенностью к Oracle Corp. и прочие его преимущества, связанные с языком, страной проживания и т.д - думаю, конкуренцию Тому могли бы составить многие. В силу объективных обстоятельств мы поставлены в гораздо менее выгодные условия, чем тот же Том.

Я на 1000% согласна, что в России много умных людей (гораздо больше, чем в Штатах, уверяю вас!), но насчет Тома вы меня не переубедите. Прежде, чем стать тем, кто он стал, Том несколько лет помирал на скучнейшем проекте делая maintenance и сходя с ума от тоски. Тогда он стал сам все изучать, участвовать в форумах, решать проблемы. Потом он, благодаря своим талантам, получил те возможности, которые у него есть сейчас. Но вместо того, чтобы, получая свою колоссальную зарплату, сидеть где-нибудь на Гаваях или в собственном бассейне, попивая коктейль и по conference calls рассылая директивы своим подчиненным, он продолжает делать то, что любит и может делать - работает, пишет книжки, исследует возможности Оракла, пишет новые feutures для него, работает на проектах, делает доклады на конференциях и плюс - помогает сотням, если не тысячам людей, пытающимся решить ту или иную проблему. Никого не игнорирует. Я сама несколько раз задавала ему вопросы и всегда получала немедленные ответы, даже в выходные, даже если эти вопросы были глупыми. А пару раз я ему задала очень глупые вопросы. Знаете, как бывает. когда что-то не идет и ты все время тыкаешься в одну и ту же дверь, а потом вдруг до тебя доходит как это сделать. Пару раз, повторяю, я его спросила что-то очень глупое (и тут же до меня дошло и мне стало стыдно, что я спросила), и он не посмеялся, не "послал", а нормально все объяснил, как он объясняет КАЖДОМУ, обращающемуся к нему. И ведь при этом у него жена и двое детей. А какие у него есть потрясающие решения! Как угодно, но я его считаю гением.

Кстати, Адамс на мой взгляд , будет покруче Кайта и я ему верю больше. При этом он, кстати, никогда не работал в Oracle Corp.

Стив Адамс тоже классный, но он, между прочим, консультирует за большие деньги. На одном из проектов, где я работала, к нему хотели обратиться, но оказалось, что это очень дорого и мой клиент отказался платить такие деньги.
Между прочим, он и Том очень уважают друг друга.

Вы говорите: "В силу объективных обстоятельств мы поставлены в гораздо менее выгодные условия, чем тот же Том". Что вы имеете в виду? Я так не думаю, потому что видя, как здесь в Штатах работают и как ценятся программисты, попадающие сюда из России, я думаю, что это совсем не так. У вас у всех потрясающее образование, причем бесплатное. Вы все на этом форуме, как я понимаю, имеете техническое образование, которое в России просто несравненно лучше, чем в Штатах (у меня тоже образование, но гуманитарное, и в Оракле я самоучка). У вас условия, когда вы должны из "г-на делать конфетку", изловчаться, приспосабливаться к тому, что есть. У вас отличные условия для развития.

Всего вам доброго и хороших выходных.

В.
...
Рейтинг: 0 / 0
Почему так медленно SELECT COUNT(*)
    #32619802
Фотография Markelenkov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
DBGroup Consulting23 байта - это стандартная цифра из документации. Думаю, Том не делал дампы, чтобы ее проверить.
Я поискал в свое время эту цифру в документации (правда, только для версии 9.2), но нигде не нашел. Может быть, в более старых версиях об этом есть упоминание, я этого уже не помню.

DBGroup ConsultingВ любом случае, у них у всех есть свои выходы на Oracle Corp., поскольку многие вещи нельзя трактовать однозначно без того, чтобы подглядеть код.
У меня тоже сложилось такое же впечатление.
...
Рейтинг: 0 / 0
Почему так медленно SELECT COUNT(*)
    #32619806
Фотография Markelenkov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
В.Я на 1000% согласна, что в России много умных людей (гораздо больше, чем в Штатах, уверяю вас!), но насчет Тома вы меня не переубедите.
А я и не ставлю целью кого-либо переубеждать. Просто я считаю, что Том - талант, но не гений ;-) Гении, на мой взгляд, - Бетховен, Пушкин, Эйнштейн, Ландау... Вот лет через 50-100 можно будет судить и о гениальности ныне живущих.

В.Вы говорите: "В силу объективных обстоятельств мы поставлены в гораздо менее выгодные условия, чем тот же Том". Что вы имеете в виду? Я так не думаю, потому что видя, как здесь в Штатах работают и как ценятся программисты, попадающие сюда из России, я думаю, что это совсем не так. У вас у всех потрясающее образование, причем бесплатное. Вы все на этом форуме, как я понимаю, имеете техническое образование, которое в России просто несравненно лучше, чем в Штатах (у меня тоже образование, но гуманитарное, и в Оракле я самоучка). У вас условия, когда вы должны из "г-на делать конфетку", изловчаться, приспосабливаться к тому, что есть. У вас отличные условия для развития.

На образование не жалуюсь, на кругозор тоже, на возраст - уже да ;-)

Что я имею ввиду под объективными обстоятельствами? Например, наличие английского языка в качестве родного. Почти все общение в сфере IT идет на нем. Техническую литературу на английском я читаю в несколько раз медленнее, чем на русском. Прочую - на порядок и более. При этом не всегда понимаю на 100% смысл. Интернет на работе появился лет 5-6 назад, но доступ к нему весьма ограничен. Дома подключился меньше года назад - не все в Москве живут. Моей зарплаты недостаточно для оплаты посещений семинаров, курсов и т.д., покупки билетов на самолет, а предприятие за это не платит. Серьезной техники и серьезных задач под Oracle в России на порядки меньше, чем в тех же Штатах - страна бедная, ее жители тоже. Кроме Oracle приходится заниматься еще разными вещами - семью кормить-то надо? Лично у меня есть еще множество факторов, не способствующих повышению уровня моих знаний в Oracle, но это не суть важно.

В.Всего вам доброго и хороших выходных.
Спасибо, и Вам таких же вкусных шашлыков ;-)
...
Рейтинг: 0 / 0
Почему так медленно SELECT COUNT(*)
    #32620595
Destroy
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Markelenkov DBGroup Consulting23 байта - это стандартная цифра из документации. Думаю, Том не делал дампы, чтобы ее проверить.
Я поискал в свое время эту цифру в документации (правда, только для версии 9.2), но нигде не нашел. Может быть, в более старых версиях об этом есть упоминание, я этого уже не помню.


Oracle 9i Database Concepts Release 2 (9.2). Стр. 2-5 (или 119) в самом низу.
...
Рейтинг: 0 / 0
Почему так медленно SELECT COUNT(*)
    #32621250
Фотография Markelenkov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
2 Destroy

Ага, спасибо, вижу.
...
Рейтинг: 0 / 0
Почему так медленно SELECT COUNT(*)
    #32622521
Фотография 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
...
Рейтинг: 0 / 0
Почему так медленно SELECT COUNT(*)
    #32623372
Фотография Fucker
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
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
...
Рейтинг: 0 / 0
Почему так медленно SELECT COUNT(*)
    #32623780
Фотография Гость-16
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Так что концепции честно признались, что это число приблизительное(approximately) и зависит от ОС.

примерно 23 это ведь и 24 и 25, а может даже и 22


В военное время значение числа Пи может достигать 4 или даже 5-ти!
...
Рейтинг: 0 / 0
Почему так медленно SELECT COUNT(*)
    #32623824
Фотография killed
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
кстати rman тоже не все ловит. Повезло тут недавно убедится :))
...
Рейтинг: 0 / 0
Почему так медленно SELECT COUNT(*)
    #32624159
Фотография Markelenkov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
FuckerЕсли у вас установлен db_block_checksum, то все дополнительные проверки теряют смысл, т.к. Oracle сам будет проверять целостность всех блоков
Я бы не был так категоричен. Точнее, мне кажется, было бы сказать "всех читаемых и записываемых блоков во всех табличных пространствах". Для TS SYSTEM, как известно, это включено по умолчанию и регулируется другим параметром. Блок может уже давно скончаться, а Oracle узнает об этом только при его чтении :-(

Fuckerпримерно 23 это ведь и 24 и 25, а может даже и 22
Хорошо, пусть будет ни вам, ни нам - 23.5
...
Рейтинг: 0 / 0
Почему так медленно SELECT COUNT(*)
    #32624189
B.
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
B.
Гость
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

Спасибо. Это все очень интересно. Я посмотрю вечером в книжке как это у Тома
...
Рейтинг: 0 / 0
Почему так медленно SELECT COUNT(*)
    #32624493
Фотография Fucker
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Markelenkov FuckerЕсли у вас установлен db_block_checksum, то все дополнительные проверки теряют смысл, т.к. Oracle сам будет проверять целостность всех блоков
Я бы не был так категоричен. Точнее, мне кажется, было бы сказать "всех читаемых и записываемых блоков во всех табличных пространствах". Для TS SYSTEM, как известно, это включено по умолчанию и регулируется другим параметром. Блок может уже давно скончаться, а Oracle узнает об этом только при его чтении :-(

Согласен, это мой недочет.
Еще можно добавить и про проверку redo ;-)

Fuckerпримерно 23 это ведь и 24 и 25, а может даже и 22
Хорошо, пусть будет ни вам, ни нам - 23.5


Хорошо, договорились


killedкстати rman тоже не все ловит. Повезло тут недавно убедится :))

И на старуху бывает проруха ;-)
RMAN'ом ты ведь после этого не перестал пользоваться



Fucker
...
Рейтинг: 0 / 0
Почему так медленно SELECT COUNT(*)
    #32624648
Фотография Fucker
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Markelenkov FuckerЕсли у вас установлен db_block_checksum, то все дополнительные проверки теряют смысл, т.к. Oracle сам будет проверять целостность всех блоков
Я бы не был так категоричен. Точнее, мне кажется, было бы сказать "всех читаемых и записываемых блоков во всех табличных пространствах". Для TS SYSTEM, как известно, это включено по умолчанию и регулируется другим параметром. Блок может уже давно скончаться, а Oracle узнает об этом только при его чтении :-(

Пардон, в предыдущем послании моя фраза не туда влезла, поэтому повторю:

Согласен, это мой недочет.
Еще можно добавить и про проверку redo ;-)


Fucker
...
Рейтинг: 0 / 0
Почему так медленно SELECT COUNT(*)
    #32624692
Oracle newbie
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
2 Fucker
есть вопрос по поводу проверки redo
знаю только вариант c alter system dump logfile
Если подкините еще вариант, буду благодарен.

Regards.
...
Рейтинг: 0 / 0
Почему так медленно SELECT COUNT(*)
    #32625005
Фотография Fucker
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
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
...
Рейтинг: 0 / 0
Почему так медленно SELECT COUNT(*)
    #32626199
Фотография Markelenkov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
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% оправдано.

Подобные (сомнительные в моем понимании) места в тексте есть и далее, но это ни коим образом не умоляет ни достоинств самого автора, ни достоинств его великолепной книги.
...
Рейтинг: 0 / 0
Почему так медленно SELECT COUNT(*)
    #32626221
B.
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
B.
Гость
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.
...
Рейтинг: 0 / 0
Почему так медленно SELECT COUNT(*)
    #32626305
В.
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
В.
Гость
Глава 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" означает генеральную идею, без подробностей.

Насколько я поняла, перевод не слишком хороший. Наверное, кто-то наспех сделал.
...
Рейтинг: 0 / 0
Почему так медленно SELECT COUNT(*)
    #32626308
В.
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
В.
Гость
Я подробно ответила на твое сообщение, но когда я кликнула на Опубликовать, мне пришел ответ что-то вроде "У вас нет права публиковать сообщение на этом форуме". Я пошла назад, но моего текста уже не было.
Не хочу все повторять, сил нет, но вкратце - твой анализ блестящ, наши DBA тебе в подметки не годятся и они бы не поняли почти ничего из того, что ты написал и что хорошо бы было обо всем этом спросить у Тома.
...
Рейтинг: 0 / 0
Почему так медленно SELECT COUNT(*)
    #32627245
Фотография Markelenkov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
В.Я не знаю, что такое Активный журнал повторного выполнения...
...Ага, я теперь знаю, что это 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 босиком и летом, и зимой бегает :-)
...
Рейтинг: 0 / 0
Почему так медленно SELECT COUNT(*)
    #32627661
В.
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
В.
Гость
По поводу последней фразы - не надо преувеличивать мои заслуги. Я, например, Факеру в подметки не гожусь. Тогда на какую часть его подошвы пускать Ваших админов? ;-) Одна надежда, что Fucker босиком и летом, и зимой бегает :-)[/quot]

Мой последний постинг был как раз ему (F-ру). Я ему подробно написала, но у меня постинг не прошел и исчез. Надо было его имя в обращении поставить, но у меня рука не поворачивается такие слова писать :)

Вы тоже здорово во всем разбираетесь, между прочим, завидую.

Мне было интересно сравнивать русский переовд с оригиналом. Если получится до отпуска (опять я вам тут завидую!), подкиньте еще что-нибудь интересное.
...
Рейтинг: 0 / 0
Почему так медленно SELECT COUNT(*)
    #32627813
Фотография killed
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
В.
Мой последний постинг был как раз ему (F-ру). Я ему подробно написала, но у меня постинг не прошел и исчез. Надо было его имя в обращении поставить, но у меня рука не поворачивается такие слова писать :)


тогда зовите его ласково Фунтик
...
Рейтинг: 0 / 0
Почему так медленно SELECT COUNT(*)
    #32627849
Фотография Markelenkov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Markelenkov...online redo (текущие, активные, имеющие статус ACTIVE в select status from v$log журнальные файлы или один файл, если online redo не дублируются).
Бес попутал... Конечно же - online redo, это все журнальные файлы, которые отображаются в v$log, а текущие (current), или иначе иногда не совсем корректно называемые активные, имеют статус CURRENT в v$log.

В.Мой последний постинг был как раз ему (F-ру).
Ну тогда я спокоен...


В.наши DBA тебе в подметки не годятся и они бы не поняли почти ничего из того, что ты написал
А Вы им покажите, Fucker все очень правильно и доходчиво написал. Должны понять.
...
Рейтинг: 0 / 0
Почему так медленно SELECT COUNT(*)
    #32628194
Фотография Markelenkov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
2 В.

Как и обещал, даю более точные координаты: Глава 2 (Архитектура), Процессы, Фоновые (Background) процессы, DBWn - запись блоков базы данных, самое последнее предложение перед "LGWR - запись журнала" (что в англ. варианте выглядит примерно как "LGWR - redo log writer"):

Это верно даже несмотря на то, что сервер Oracle может выполнять больший объем ввода/вывода, чем надо (записывает в журнал и в файл данных), - записи в активный журнал повторного выполнения можно пропустить, если в ходе обработки контрольной точки сервер Oracle уже записал измененные блоки на диск.

Очень хотелось бы, если не затруднит, увидеть оригинальный текст Кайта.
Спасибо.
...
Рейтинг: 0 / 0
Почему так медленно SELECT COUNT(*)
    #32628217
B.
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
B.
Гость
Markelenkov2 В.

Как и обещал, даю более точные координаты: Глава 2 (Архитектура), Процессы, Фоновые (Background) процессы, DBWn - запись блоков базы данных, самое последнее предложение перед "LGWR - запись журнала" (что в англ. варианте выглядит примерно как "LGWR - redo log writer"):

Это верно даже несмотря на то, что сервер Oracle может выполнять больший объем ввода/вывода, чем надо (записывает в журнал и в файл данных), - записи в активный журнал повторного выполнения можно пропустить, если в ходе обработки контрольной точки сервер Oracle уже записал измененные блоки на диск.

Очень хотелось бы, если не затруднит, увидеть оригинальный текст Кайта.
Спасибо.

Ne zatrudnit. Pridu domoi posmotru.
...
Рейтинг: 0 / 0
Почему так медленно SELECT COUNT(*)
    #32628306
В.
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
В.
Гость
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 - означает не "можно", а "возможно", "вероятно", "может статься, что".

Всего доброго
...
Рейтинг: 0 / 0
Почему так медленно SELECT COUNT(*)
    #32628496
Фотография Markelenkov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Спасибо за ответ.
Мне кажется, что Кайт здесь ошибается.

Запись в 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." на мой взгляд, ошибочна, либо он имел ввиду нечто другое. На перевод в данном случае, как мне кажется, грешить нельзя.
...
Рейтинг: 0 / 0
Почему так медленно SELECT COUNT(*)
    #32628840
Oracle newbie
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
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
...
Рейтинг: 0 / 0
Почему так медленно SELECT COUNT(*)
    #32629069
igor2222
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Ага! Возникло подозрение, что Кайт в электронном виде таки существует :-)))))))
...
Рейтинг: 0 / 0
Почему так медленно SELECT COUNT(*)
    #32629148
Фотография Markelenkov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
igor2222Ага! Возникло подозрение, что Кайт в электронном виде таки существует :-)))))))
На чем оно основано?
...
Рейтинг: 0 / 0
Почему так медленно SELECT COUNT(*)
    #32629251
igor2222
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Да цитаты из Кайта какие то большие приводятся. Неужели руками набирались?
...
Рейтинг: 0 / 0
Почему так медленно SELECT COUNT(*)
    #32629909
В.
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
В.
Гость
Маркеленкову и "Новичку"

А что если я, с вашего разрешения, спрошу об этом Тома со ссылкой на вас? Можно? Интересно, что он ответит.

P/S К сожалению, электронной версии нет кроме выдержек из первой главы. Просто я быстро печатаю.
...
Рейтинг: 0 / 0
Почему так медленно SELECT COUNT(*)
    #32629962
Фотография Markelenkov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
В.Маркеленкову и "Новичку"

А что если я, с вашего разрешения, спрошу об этом Тома со ссылкой на вас? Можно? Интересно, что он ответит.
Лично я не против, Виталий (newbie), думаю, тоже будет не против. Кстати, чайником он только прикидывается, если Вы еще не заметили. Про утилиту exp тоже можно было бы спросить, но про возможность сослаться на Фунтика
надо у него же и спрашивать.

Правда, попутно возникает два вопроса:

1. Умеет ли он читать по-русски?
Или Вы ему переведете нас? ;-)
2. Неужели никто на asktom его об этом до сих пор не спрашивал? Ведь книга в английском варианте вышла гораздо раньше, да и англоговорящих спецов по Oracle гораздо больше. Кстати, я заметил, что многие просто боятся спорить с Кайтом.
...
Рейтинг: 0 / 0
Почему так медленно SELECT COUNT(*)
    #32630063
Oracle newbie
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
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.
...
Рейтинг: 0 / 0
Почему так медленно SELECT COUNT(*)
    #32630177
Фотография Markelenkov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Пока не появился "злой Фунтик", чуть уточню
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 запишет в файл данных сам измененный блок.
...
Рейтинг: 0 / 0
Почему так медленно SELECT COUNT(*)
    #32630186
B.
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
B.
Гость
Markelenkov В.Маркеленкову и "Новичку"

А что если я, с вашего разрешения, спрошу об этом Тома со ссылкой на вас? Можно? Интересно, что он ответит.
Лично я не против, Виталий (newbie), думаю, тоже будет не против. Кстати, чайником он только прикидывается, если Вы еще не заметили. Про утилиту exp тоже можно было бы спросить, но про возможность сослаться на Фунтика
надо у него же и спрашивать.

Правда, попутно возникает два вопроса:

1. Умеет ли он читать по-русски?
Или Вы ему переведете нас? ;-)
2. Неужели никто на asktom его об этом до сих пор не спрашивал? Ведь книга в английском варианте вышла гораздо раньше, да и англоговорящих спецов по Oracle гораздо больше. Кстати, я заметил, что многие просто боятся спорить с Кайтом.

по-руски он не умет, но я переведу. что "новичек" не чайник это ясно, поэтому я его ник и поставила в кавычки. на asktom я смотрела (не утверждаю, что очень внимательно), но дискуссии на эту тему не нашла.
чтобы тому и мне было легче, нельзя ли вам с Виталием и с Фунтиком сформулировать вопросы\возражения кратко и в виде 1. 2. 3 ...?
том любит умные вопросы и не очень любит глупые, хотя отвечает на все. думаю, ему будет интересно узнать, что его книги читают и обсуждают руские гуру и что в россии есть оракуловские гуру.
...
Рейтинг: 0 / 0
Почему так медленно SELECT COUNT(*)
    #32630202
Фотография Markelenkov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
К сожалению, мне уже некогда, есть дела, которые надо сделать перед отъездом. Жена уже пилит, гонит от компа... Поэтому без меня. А я с удовольствием потом почитаю ответы Тома, если он ответит и Вы дадите ссылочку.
...
Рейтинг: 0 / 0
Почему так медленно SELECT COUNT(*)
    #32630263
B.
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
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.
...
Рейтинг: 0 / 0
Почему так медленно SELECT COUNT(*)
    #32630271
Violina
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
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.
...
Рейтинг: 0 / 0
Почему так медленно SELECT COUNT(*)
    #32630279
Violina
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Решила обрисовать пару конкретных ситуаций по этому поводу. Поправьте или дополните плиз если где то есть ошибки или упущенные моменты.

Ситуация 1: Сбой во время изменений данных

- идет транзакция
- Oracle сбросил некоторые грязные незакомиченные данные из оперативной памяти в дата файлы
- изменение данных разумется в свою очередь вызвало изменение в сегментах отката, в них записались старые версии данных
- часть изменных данных в сегментах отката сидит в оперативной памяти и еще не было сброшено на диск

Происходит сбой. Что мы имеем:

- в датафайлах сидят незакомиченные данные которые нужно откатить
- сегменты отката не содержат всю необходимую информацию для отмены незакомиченных изменений, потому что часть их сидела в оперативной памяти и была потеряна при сбое
- в redo журнале записаны все изменения данных и сегметов отката до момента последнего сброса log buffer на диск

Что поисходит при старте

- Оракл накатывает ВСЕ изменения из redo - как закомиченные так и незакомиченные - как на блоки данных так и на блоки сегментов отката. Теперь сегменты отката восстановлены до того состояния, когда вся информация для отмены незакомиченных изменений имеется.

- Используя сегменты отката Oracle откатывает незакомиченные изменения.

Ситуация 2: Сбой во время отката

- идет транзакция
- Oracle сбросил некоторые грязные незакомиченные данные из оперативной памяти в дата файлы
- изменение данных разумется в свою очередь вызвало изменение в сегментах отката, в них записались старые версии данных
- часть изменных данных в сегментах отката сидит в оперативной памяти и еще не было сброшено на диск
- пользователь решил сделать rollback
- в redolog разумеется не была записана commit record
- пошел откат

Происходит сбой во время операции отката. Что мы имеем:

- в датафайлах сидят незакомиченные данные которые нужно откатить
- сегменты отката НЕ содержат всю необходимую информацию для отмены незакомиченных изменений, потому что часть их сидела в оперативной памяти и была потеряна при сбое
- в redo журнале записаны все изменения данных и сегметов отката до момента последнего сброса log buffer на диск

Что поисходит при старте:

- Oracle накатывает ВСЕ изменения из redo - как закомиченные так и незакомиченные - как на блоки данных так и на блоки сегментов отката. Теперь сегменты отката восстановлены до того состояния, когда вся информация для отмены незакомиченных изменений имеется.
- откат продолжается дальше
...
Рейтинг: 0 / 0
Почему так медленно SELECT COUNT(*)
    #32630304
В.
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
В.
Гость
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,

Однако, в одном я была права, переведя высказывание Тома как "если бы", возможно" и пр.
...
Рейтинг: 0 / 0
Почему так медленно SELECT COUNT(*)
    #32630307
Фотография Markelenkov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
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 тоже было бы интересно разобраться. Спасибо за ссылку, может быть успею сегодня почитать.
...
Рейтинг: 0 / 0
Почему так медленно SELECT COUNT(*)
    #32630308
Фотография Markelenkov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
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)", то все было бы сразу ясно.

Спасибо за информацию.
...
Рейтинг: 0 / 0
Почему так медленно SELECT COUNT(*)
    #32630309
В.
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
В.
Гость
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)", то все было бы сразу ясно.

Спасибо за информацию.

Марленков!!!
Это все действительно смешно! Мы сейчас сидим с друзьями и время от времени я подхожу к комрьютеру и проверяю "мессиджи" и умираю от смеха!
Показала фразу Тома другу (он крутой компьютерщик, но американец) и он сразу же сказал, что обсуждаемая нами фраза означает "если ба да кабы", если бы Оракла делал то-то и то-то, то то-то и то-то было бы не нужно, и опять затряслась от смеха. Но это действительно тонкости языка. Уж на что я его хорошо знаю, но даже я не поняла до конца смысл, хотя догадалась насчет "если бы". Но все рано не поняла, дура.
Надо бы и про экспорт спросить.
Однако правда здорово, что Том - несмотря на вечер и пятницу (я ему вечером написала) - сразу ответил?
Счастливого отдыха!
...
Рейтинг: 0 / 0
Почему так медленно SELECT COUNT(*)
    #32630458
Фотография Ааз
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Привет
Мои два копейка:

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
...
Рейтинг: 0 / 0
Почему так медленно SELECT COUNT(*)
    #32630459
Фотография Ааз
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Привет
Сории, забыл пункт

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...
...
Рейтинг: 0 / 0
Почему так медленно SELECT COUNT(*)
    #32630468
Фотография killed
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
АазПривет
Мои два копейка:

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 по умолчанию не проверяет
...
Рейтинг: 0 / 0
Почему так медленно SELECT COUNT(*)
    #32630470
Фотография killed
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
АазПривет
Мои два копейка:

1. сорри, всю неделю был занят по самое нехочу. Пропустил такую интересную дискусию. Даже прочитать времени не было. *_млинк_*



Как там Аксапта, еле дышит? Молоко то дает?
...
Рейтинг: 0 / 0
Почему так медленно SELECT COUNT(*)
    #32630715
В.
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
В.
Гость
АазПривет
Сории, забыл пункт

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 ведь я и до здешних ассов мне ну очень далеко.
...
Рейтинг: 0 / 0
Почему так медленно SELECT COUNT(*)
    #32631991
Фотография Fucker
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Да, дискуссия получилась длинная…

В танном топике прозвучало несколько фамилий известных специалистов. Мне кажется, все-таки стоит дать некоторые комментарии.

Стива Адамса я бы назвал экстремалом в достижении рекордной производительности 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.
C:\oracle\oradata\TEST>dbv file=XYZ4GB.DBF blocksize= 8192 

DBVERIFY: Release  8 . 1 . 7 . 4 . 1  - Production on Mon Aug  2   15 : 36 : 53   2004 

(c) Copyright  2000  Oracle Corporation.  All rights reserved.

DBVERIFY - Verification starting : FILE = XYZ4GB.DBF


DBVERIFY - Verification complete

Total Pages Examined         :  524288 
Total Pages Processed (Data) :  243453 
Total Pages Failing   (Data) :  0 
Total Pages Processed (Index):  142690 
Total Pages Failing   (Index):  0 
Total Pages Processed (Other):  1499 
Total Pages Empty            :  136646 
Total Pages Marked Corrupt   :  0 
Total Pages Influx           :  0  

Ааз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.
...
Рейтинг: 0 / 0
Почему так медленно SELECT COUNT(*)
    #32634627
Всегда!!!!!
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Да уж, знал ли Johnny Bombardir какую кашу заваривает :-)
...
Рейтинг: 0 / 0
Почему так медленно SELECT COUNT(*)
    #32634759
olek
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Всегда!!!!!Да уж, знал ли Johnny Bombardir какую кашу заваривает :-)Причем из топора
...
Рейтинг: 0 / 0
Период между сообщениями больше года.
Почему так медленно SELECT COUNT(*)
    #37588785
ArmenA
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
oracle count как не крути работает медленно чем например в mysql
...
Рейтинг: 0 / 0
Почему так медленно SELECT COUNT(*)
    #37588795
Фотография AmKad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ArmenAoracle count как не крути работает медленно чем например в mysql"Тонкий" троллинг с семилетней выдержкой.
...
Рейтинг: 0 / 0
Почему так медленно SELECT COUNT(*)
    #37588884
Фотография dbms_photoshop
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ArmenA,
И уж тем более медленнее, чем подсчет строк в текстовом файле.
...
Рейтинг: 0 / 0
Почему так медленно SELECT COUNT(*)
    #37589103
Фотография Gluk (Kazan)
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Некто: count(1) лучше чем count(*)
Все хором: Чем лучше, ЧЕМ???
Некто: чем count(*)

Зачот по эксгумации темы 2004 года розлива
...
Рейтинг: 0 / 0
133 сообщений из 133, показаны все 6 страниц
Форумы / Oracle [игнор отключен] [закрыт для гостей] / Почему так медленно SELECT COUNT(*)
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]