powered by simpleCommunicator - 2.0.39     © 2025 Programmizd 02
Форумы / Oracle [игнор отключен] [закрыт для гостей] / Почему так медленно SELECT COUNT(*)
25 сообщений из 133, страница 4 из 6
Почему так медленно 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
25 сообщений из 133, страница 4 из 6
Форумы / Oracle [игнор отключен] [закрыт для гостей] / Почему так медленно SELECT COUNT(*)
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


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