|
Почему так медленно SELECT COUNT(*)
|
|||
---|---|---|---|
#18+
В.А вообще-то он гений. Ну это уж чересчур! Он, конечно, гуру, но не гений, imho. Уверяю Вас, например, если бы у многих из тусующихся на этом форуме была возможность заниматься СУБД и Oracle в частности столько времени, сколько у Тома, да плюс его возможности, связанные с приближенностью к Oracle Corp. и прочие его преимущества, связанные с языком, страной проживания и т.д - думаю, конкуренцию Тому могли бы составить многие. В силу объективных обстоятельств мы поставлены в гораздо менее выгодные условия, чем тот же Том. В.А какие ошибки вы заметили? Я их не запоминаю. Например, помню, что в его книге (в русском переводе) "Expert One-on-One Oracle" он пишет, что размер ITL в блоке 23 байта. Страницу назвать по памяти не могу, искать лень (в русском переводе книга разбита на 2 тома). Помню это потому, что проверял. Может быть, опечатка. Видел это же число еще у нескольких авторов - гипноз? Дампы блоков и, например, Стив Адамс здесь и здесь с Кайтом не согласны. Кстати, Адамс на мой взгляд , будет покруче Кайта и я ему верю больше. При этом он, кстати, никогда не работал в Oracle Corp. Поэтому Адамс поближе к гениальности, imho. Хотя тоже, бывает, ошибается ;-) ... |
|||
:
Нравится:
Не нравится:
|
|||
23.07.2004, 20:21 |
|
Почему так медленно SELECT COUNT(*)
|
|||
---|---|---|---|
#18+
23 байта - это стандартная цифра из документации. Думаю, Том не делал дампы, чтобы ее проверить. В любом случае, у них у всех есть свои выходы на Oracle Corp., поскольку многие вещи нельзя трактовать однозначно без того, чтобы подглядеть код. Успехов, DBGroup Consulting ... |
|||
:
Нравится:
Не нравится:
|
|||
23.07.2004, 21:11 |
|
Почему так медленно SELECT COUNT(*)
|
|||
---|---|---|---|
#18+
Markelenkov[quot В.]А вообще-то он гений. Ну это уж чересчур! Он, конечно, гуру, но не гений, imho. Уверяю Вас, например, если бы у многих из тусующихся на этом форуме была возможность заниматься СУБД и Oracle в частности столько времени, сколько у Тома, да плюс его возможности, связанные с приближенностью к Oracle Corp. и прочие его преимущества, связанные с языком, страной проживания и т.д - думаю, конкуренцию Тому могли бы составить многие. В силу объективных обстоятельств мы поставлены в гораздо менее выгодные условия, чем тот же Том. Я на 1000% согласна, что в России много умных людей (гораздо больше, чем в Штатах, уверяю вас!), но насчет Тома вы меня не переубедите. Прежде, чем стать тем, кто он стал, Том несколько лет помирал на скучнейшем проекте делая maintenance и сходя с ума от тоски. Тогда он стал сам все изучать, участвовать в форумах, решать проблемы. Потом он, благодаря своим талантам, получил те возможности, которые у него есть сейчас. Но вместо того, чтобы, получая свою колоссальную зарплату, сидеть где-нибудь на Гаваях или в собственном бассейне, попивая коктейль и по conference calls рассылая директивы своим подчиненным, он продолжает делать то, что любит и может делать - работает, пишет книжки, исследует возможности Оракла, пишет новые feutures для него, работает на проектах, делает доклады на конференциях и плюс - помогает сотням, если не тысячам людей, пытающимся решить ту или иную проблему. Никого не игнорирует. Я сама несколько раз задавала ему вопросы и всегда получала немедленные ответы, даже в выходные, даже если эти вопросы были глупыми. А пару раз я ему задала очень глупые вопросы. Знаете, как бывает. когда что-то не идет и ты все время тыкаешься в одну и ту же дверь, а потом вдруг до тебя доходит как это сделать. Пару раз, повторяю, я его спросила что-то очень глупое (и тут же до меня дошло и мне стало стыдно, что я спросила), и он не посмеялся, не "послал", а нормально все объяснил, как он объясняет КАЖДОМУ, обращающемуся к нему. И ведь при этом у него жена и двое детей. А какие у него есть потрясающие решения! Как угодно, но я его считаю гением. Кстати, Адамс на мой взгляд , будет покруче Кайта и я ему верю больше. При этом он, кстати, никогда не работал в Oracle Corp. Стив Адамс тоже классный, но он, между прочим, консультирует за большие деньги. На одном из проектов, где я работала, к нему хотели обратиться, но оказалось, что это очень дорого и мой клиент отказался платить такие деньги. Между прочим, он и Том очень уважают друг друга. Вы говорите: "В силу объективных обстоятельств мы поставлены в гораздо менее выгодные условия, чем тот же Том". Что вы имеете в виду? Я так не думаю, потому что видя, как здесь в Штатах работают и как ценятся программисты, попадающие сюда из России, я думаю, что это совсем не так. У вас у всех потрясающее образование, причем бесплатное. Вы все на этом форуме, как я понимаю, имеете техническое образование, которое в России просто несравненно лучше, чем в Штатах (у меня тоже образование, но гуманитарное, и в Оракле я самоучка). У вас условия, когда вы должны из "г-на делать конфетку", изловчаться, приспосабливаться к тому, что есть. У вас отличные условия для развития. Всего вам доброго и хороших выходных. В. ... |
|||
:
Нравится:
Не нравится:
|
|||
24.07.2004, 06:32 |
|
Почему так медленно SELECT COUNT(*)
|
|||
---|---|---|---|
#18+
DBGroup Consulting23 байта - это стандартная цифра из документации. Думаю, Том не делал дампы, чтобы ее проверить. Я поискал в свое время эту цифру в документации (правда, только для версии 9.2), но нигде не нашел. Может быть, в более старых версиях об этом есть упоминание, я этого уже не помню. DBGroup ConsultingВ любом случае, у них у всех есть свои выходы на Oracle Corp., поскольку многие вещи нельзя трактовать однозначно без того, чтобы подглядеть код. У меня тоже сложилось такое же впечатление. ... |
|||
:
Нравится:
Не нравится:
|
|||
24.07.2004, 06:48 |
|
Почему так медленно SELECT COUNT(*)
|
|||
---|---|---|---|
#18+
В.Я на 1000% согласна, что в России много умных людей (гораздо больше, чем в Штатах, уверяю вас!), но насчет Тома вы меня не переубедите. А я и не ставлю целью кого-либо переубеждать. Просто я считаю, что Том - талант, но не гений ;-) Гении, на мой взгляд, - Бетховен, Пушкин, Эйнштейн, Ландау... Вот лет через 50-100 можно будет судить и о гениальности ныне живущих. В.Вы говорите: "В силу объективных обстоятельств мы поставлены в гораздо менее выгодные условия, чем тот же Том". Что вы имеете в виду? Я так не думаю, потому что видя, как здесь в Штатах работают и как ценятся программисты, попадающие сюда из России, я думаю, что это совсем не так. У вас у всех потрясающее образование, причем бесплатное. Вы все на этом форуме, как я понимаю, имеете техническое образование, которое в России просто несравненно лучше, чем в Штатах (у меня тоже образование, но гуманитарное, и в Оракле я самоучка). У вас условия, когда вы должны из "г-на делать конфетку", изловчаться, приспосабливаться к тому, что есть. У вас отличные условия для развития. На образование не жалуюсь, на кругозор тоже, на возраст - уже да ;-) Что я имею ввиду под объективными обстоятельствами? Например, наличие английского языка в качестве родного. Почти все общение в сфере IT идет на нем. Техническую литературу на английском я читаю в несколько раз медленнее, чем на русском. Прочую - на порядок и более. При этом не всегда понимаю на 100% смысл. Интернет на работе появился лет 5-6 назад, но доступ к нему весьма ограничен. Дома подключился меньше года назад - не все в Москве живут. Моей зарплаты недостаточно для оплаты посещений семинаров, курсов и т.д., покупки билетов на самолет, а предприятие за это не платит. Серьезной техники и серьезных задач под Oracle в России на порядки меньше, чем в тех же Штатах - страна бедная, ее жители тоже. Кроме Oracle приходится заниматься еще разными вещами - семью кормить-то надо? Лично у меня есть еще множество факторов, не способствующих повышению уровня моих знаний в Oracle, но это не суть важно. В.Всего вам доброго и хороших выходных. Спасибо, и Вам таких же вкусных шашлыков ;-) ... |
|||
:
Нравится:
Не нравится:
|
|||
24.07.2004, 07:10 |
|
Почему так медленно SELECT COUNT(*)
|
|||
---|---|---|---|
#18+
Markelenkov DBGroup Consulting23 байта - это стандартная цифра из документации. Думаю, Том не делал дампы, чтобы ее проверить. Я поискал в свое время эту цифру в документации (правда, только для версии 9.2), но нигде не нашел. Может быть, в более старых версиях об этом есть упоминание, я этого уже не помню. Oracle 9i Database Concepts Release 2 (9.2). Стр. 2-5 (или 119) в самом низу. ... |
|||
:
Нравится:
Не нравится:
|
|||
26.07.2004, 09:34 |
|
Почему так медленно SELECT COUNT(*)
|
|||
---|---|---|---|
#18+
2 Destroy Ага, спасибо, вижу. ... |
|||
:
Нравится:
Не нравится:
|
|||
26.07.2004, 14:18 |
|
Почему так медленно SELECT COUNT(*)
|
|||
---|---|---|---|
#18+
В.Вот это у меня не открывается, вылезает что-то другое: http://www.sql.ru/images/laugh.gif Надеюсь, что на сей раз вылезло то, что надо В. FuckerЗавтра, послезавтра постараюсь перечитать несколько глав и привести несколько примеров. Первый будет связан с использованием утилиты экспорт. Если завтра у нас не будет дождя, который обещают, то я уеду на выходные за город, поэтому очень прошу на всякий случай или не публиковать это до понедельника, или в понедельник освежить, а то все затеряется. В. автор Выявление повреждений Я использую утилиту EXP в качестве средства для выявления повреждений базы данных, физических или логических . Если с помощью утилиты EXP выполнить полное экспортирование базы данных, она проверит весь словарь данных и найдет в нем любую логическую несогласованность . Кроме того, она полностью просмотрит каждую таблицу в базе данных, читая все строки. Если имеется таблица со сбойным блоком, этот блок будет найден. Утилита не выявляет определенные типы логических повреждений, например индекс, указывающий на несуществующие строки, поскольку просматривает таблицы, но обнаружит наиболее существенные ошибки (индекс всегда можно пересоздать, а вот пересоздание таблицы иногда невозможно). Как разработчик, в некоторых отдельных случаях я мог бы воспользоваться утилитой exp с full=y для выявления повреждений прикладных данных. Но именно пользовательских данных, а не повреждений базы данных . Реально exp оставляет за бортом огромное количество различного рода «внутренних» повреждений базы данных (не буду сейчас в это углубляться, пока поверьте мне на слово, их огромное множество). То, что полный экспорт системы завершился без предупреждающих сообщений, еще не означает, что база данных находится в работоспособном состоянии. Это говорит только о том, что ваши данные пока еще доступны . Ну и кроме всего прочего, DBA обычно не раздает направо и налево exp_full_database. Особенно мне нравится, когда подобный экспорт часто идет в /dev/null Как DBA, я думаю, что утилита exp не самый подходящий инструмент для выявления повреждений базы данных. Это довольно медленное и ресурсоемкое решение, сильно осложняемое тем, что consistent=y иногда проблематично сделать на интенсивно обновляемых базах данных большого объема и вы в этом случае не застрахованы от ORA-01555, а consistent=n применим только к пассивно живущему трупу. Ну и наконец, самое главное - exp НЕ проверит весь словарь данных и НЕ найдет в нем любую логическую несогласованность . Утилита exp не экспортирует объекты словаря данных, принадлежащие пользователю sys. Да, экспорт при своей работе использует некоторую информацию из словаря данных, косвенно «проверяя» ее, вот и все. Это еще не говорит о целостности всего словаря. Справедливости ради отмечу, что существует довольно большое количество способов поиска поврежденных блоков. Если вы используете для резервирования RMAN, такие повреждения очень легко диагностируются в процессе копирования. Предохраняться надо ведь по любому, а диагностику ошибок вы получите в качестве бонуса. Можно использовать DBVERIFY, который умеет работать как с offline, так online файлами данных. Если у вас установлен db_block_checksum, то все дополнительные проверки теряют смысл, т.к. Oracle сам будет проверять целостность всех блоков. Правда платой за это может быть незначительное проседание в производительности. На уровне отдельных объектов можно использовать analyze table xyz validate structure cascade и dbms_repair… Fucker ... |
|||
:
Нравится:
Не нравится:
|
|||
27.07.2004, 10:26 |
|
Почему так медленно SELECT COUNT(*)
|
|||
---|---|---|---|
#18+
MarkelenkovЯ их не запоминаю. Например, помню, что в его книге (в русском переводе) "Expert One-on-One Oracle" он пишет, что размер ITL в блоке 23 байта. Страницу назвать по памяти не могу, искать лень (в русском переводе книга разбита на 2 тома). Помню это потому, что проверял. Может быть, опечатка. Видел это же число еще у нескольких авторов - гипноз? Кстати, Адамс на мой взгляд , будет покруче Кайта и я ему верю больше. При этом он, кстати, никогда не работал в Oracle Corp. Поэтому Адамс поближе к гениальности, imho. Хотя тоже, бывает, ошибается ;-) В качестве небольшой добавки к словам DBGroup Consulting: Справедливости ради все-таки стоит процитировать фрагмент документации http://download-west.oracle.com/docs/cd/B13789_01/server.101/b10743/logical.htm#sthref313 ConceptsIn data blocks allocated for the data segment of a table or cluster, or for the index segment of an index, free space can also hold transaction entries. A transaction entry is required in a block for each INSERT, UPDATE, DELETE, and SELECT...FOR UPDATE statement accessing one or more rows in the block. The space required for transaction entries is operating system dependent; however, transaction entries in most operating systems require approximately 23 bytes. Так что концепции честно признались, что это число приблизительное(approximately) и зависит от ОС. примерно 23 это ведь и 24 и 25, а может даже и 22 Fucker ... |
|||
:
Нравится:
Не нравится:
|
|||
27.07.2004, 14:30 |
|
Почему так медленно SELECT COUNT(*)
|
|||
---|---|---|---|
#18+
Так что концепции честно признались, что это число приблизительное(approximately) и зависит от ОС. примерно 23 это ведь и 24 и 25, а может даже и 22 В военное время значение числа Пи может достигать 4 или даже 5-ти! ... |
|||
:
Нравится:
Не нравится:
|
|||
27.07.2004, 16:28 |
|
Почему так медленно SELECT COUNT(*)
|
|||
---|---|---|---|
#18+
кстати rman тоже не все ловит. Повезло тут недавно убедится :)) ... |
|||
:
Нравится:
Не нравится:
|
|||
27.07.2004, 16:40 |
|
Почему так медленно SELECT COUNT(*)
|
|||
---|---|---|---|
#18+
FuckerЕсли у вас установлен db_block_checksum, то все дополнительные проверки теряют смысл, т.к. Oracle сам будет проверять целостность всех блоков Я бы не был так категоричен. Точнее, мне кажется, было бы сказать "всех читаемых и записываемых блоков во всех табличных пространствах". Для TS SYSTEM, как известно, это включено по умолчанию и регулируется другим параметром. Блок может уже давно скончаться, а Oracle узнает об этом только при его чтении :-( Fuckerпримерно 23 это ведь и 24 и 25, а может даже и 22 Хорошо, пусть будет ни вам, ни нам - 23.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
27.07.2004, 19:32 |
|
Почему так медленно SELECT COUNT(*)
|
|||
---|---|---|---|
#18+
Fucker В.Вот это у меня не открывается, вылезает что-то другое: http://www.sql.ru/images/laugh.gif Надеюсь, что на сей раз вылезло то, что надо В. FuckerЗавтра, послезавтра постараюсь перечитать несколько глав и привести несколько примеров. Первый будет связан с использованием утилиты экспорт. Если завтра у нас не будет дождя, который обещают, то я уеду на выходные за город, поэтому очень прошу на всякий случай или не публиковать это до понедельника, или в понедельник освежить, а то все затеряется. В. автор Выявление повреждений Я использую утилиту EXP в качестве средства для выявления повреждений базы данных, физических или логических . Если с помощью утилиты EXP выполнить полное экспортирование базы данных, она проверит весь словарь данных и найдет в нем любую логическую несогласованность . Кроме того, она полностью просмотрит каждую таблицу в базе данных, читая все строки. Если имеется таблица со сбойным блоком, этот блок будет найден. Утилита не выявляет определенные типы логических повреждений, например индекс, указывающий на несуществующие строки, поскольку просматривает таблицы, но обнаружит наиболее существенные ошибки (индекс всегда можно пересоздать, а вот пересоздание таблицы иногда невозможно). Как разработчик, в некоторых отдельных случаях я мог бы воспользоваться утилитой exp с full=y для выявления повреждений прикладных данных. Но именно пользовательских данных, а не повреждений базы данных . Реально exp оставляет за бортом огромное количество различного рода «внутренних» повреждений базы данных (не буду сейчас в это углубляться, пока поверьте мне на слово, их огромное множество). То, что полный экспорт системы завершился без предупреждающих сообщений, еще не означает, что база данных находится в работоспособном состоянии. Это говорит только о том, что ваши данные пока еще доступны . Ну и кроме всего прочего, DBA обычно не раздает направо и налево exp_full_database. Особенно мне нравится, когда подобный экспорт часто идет в /dev/null Как DBA, я думаю, что утилита exp не самый подходящий инструмент для выявления повреждений базы данных. Это довольно медленное и ресурсоемкое решение, сильно осложняемое тем, что consistent=y иногда проблематично сделать на интенсивно обновляемых базах данных большого объема и вы в этом случае не застрахованы от ORA-01555, а consistent=n применим только к пассивно живущему трупу. Ну и наконец, самое главное - exp НЕ проверит весь словарь данных и НЕ найдет в нем любую логическую несогласованность . Утилита exp не экспортирует объекты словаря данных, принадлежащие пользователю sys. Да, экспорт при своей работе использует некоторую информацию из словаря данных, косвенно «проверяя» ее, вот и все. Это еще не говорит о целостности всего словаря. Справедливости ради отмечу, что существует довольно большое количество способов поиска поврежденных блоков. Если вы используете для резервирования RMAN, такие повреждения очень легко диагностируются в процессе копирования. Предохраняться надо ведь по любому, а диагностику ошибок вы получите в качестве бонуса. Можно использовать DBVERIFY, который умеет работать как с offline, так online файлами данных. Если у вас установлен db_block_checksum, то все дополнительные проверки теряют смысл, т.к. Oracle сам будет проверять целостность всех блоков. Правда платой за это может быть незначительное проседание в производительности. На уровне отдельных объектов можно использовать analyze table xyz validate structure cascade и dbms_repair… Fucker Спасибо. Это все очень интересно. Я посмотрю вечером в книжке как это у Тома ... |
|||
:
Нравится:
Не нравится:
|
|||
27.07.2004, 20:09 |
|
Почему так медленно SELECT COUNT(*)
|
|||
---|---|---|---|
#18+
Markelenkov FuckerЕсли у вас установлен db_block_checksum, то все дополнительные проверки теряют смысл, т.к. Oracle сам будет проверять целостность всех блоков Я бы не был так категоричен. Точнее, мне кажется, было бы сказать "всех читаемых и записываемых блоков во всех табличных пространствах". Для TS SYSTEM, как известно, это включено по умолчанию и регулируется другим параметром. Блок может уже давно скончаться, а Oracle узнает об этом только при его чтении :-( Согласен, это мой недочет. Еще можно добавить и про проверку redo ;-) Fuckerпримерно 23 это ведь и 24 и 25, а может даже и 22 Хорошо, пусть будет ни вам, ни нам - 23.5 Хорошо, договорились killedкстати rman тоже не все ловит. Повезло тут недавно убедится :)) И на старуху бывает проруха ;-) RMAN'ом ты ведь после этого не перестал пользоваться Fucker ... |
|||
:
Нравится:
Не нравится:
|
|||
28.07.2004, 09:22 |
|
Почему так медленно SELECT COUNT(*)
|
|||
---|---|---|---|
#18+
Markelenkov FuckerЕсли у вас установлен db_block_checksum, то все дополнительные проверки теряют смысл, т.к. Oracle сам будет проверять целостность всех блоков Я бы не был так категоричен. Точнее, мне кажется, было бы сказать "всех читаемых и записываемых блоков во всех табличных пространствах". Для TS SYSTEM, как известно, это включено по умолчанию и регулируется другим параметром. Блок может уже давно скончаться, а Oracle узнает об этом только при его чтении :-( Пардон, в предыдущем послании моя фраза не туда влезла, поэтому повторю: Согласен, это мой недочет. Еще можно добавить и про проверку redo ;-) Fucker ... |
|||
:
Нравится:
Не нравится:
|
|||
28.07.2004, 10:59 |
|
Почему так медленно SELECT COUNT(*)
|
|||
---|---|---|---|
#18+
2 Fucker есть вопрос по поводу проверки redo знаю только вариант c alter system dump logfile Если подкините еще вариант, буду благодарен. Regards. ... |
|||
:
Нравится:
Не нравится:
|
|||
28.07.2004, 11:17 |
|
Почему так медленно SELECT COUNT(*)
|
|||
---|---|---|---|
#18+
Oracle newbie2 Fucker есть вопрос по поводу проверки redo знаю только вариант c alter system dump logfile Если подкините еще вариант, буду благодарен. Regards. Database ReferenceDB_BLOCK_CHECKSUM determines whether DBWn and the direct loader will calculate a checksum (a number calculated from all the bytes stored in the block) and store it in the cache header of every data block when writing it to disk. Checksums are verified when a block is read-only if this parameter is true and the last write of the block stored a checksum. In addition, Oracle gives every log block a checksum before writing it to the current log . Если не ошибаюсь, он начал влиять на работу с redo с тех пор, как в 8i log_block_cheksum стал obsolete Fucker ... |
|||
:
Нравится:
Не нравится:
|
|||
28.07.2004, 13:02 |
|
Почему так медленно SELECT COUNT(*)
|
|||
---|---|---|---|
#18+
2 В. Затронутая тема сподвигла на перечитывание книги Кайта "Expert One-on-One Oracle" в русском переводе с пометкой некоторых мест. Исходного варианта не имею, поэтому не исключены случаи неточного перевода. Перечитал сегодня том 1 по стр. 130. Глава 2, "Активный журнал повторного выполнения", стр. 98Если необходимо обеспечить максимально быстрое восстановление, придется использовать файлы журнала меньшего размера...Со словом "придется" категорически не согласен. Хотя далее в том же абзаце: "Для сокращения времени восстановления можно изменять и другие параметры базы данных, а не только уменьшать размер файлов журнала повторного выполнения." Глава 2, "Области PGA и UGA", стр. 101Размер области PGA/UGA определяют параметры уровня сеанса в файле init.ora: SORT_AREA_SIZE и SORT_AREA_RETAINED_SIZE. Здесь точнее было бы сказать "определяют в наибольшей степени". Глава 2, "DBWn - запись блоков базы данных", стр. 129...записи в активный журнал повторного выполнения можно пропустить , если в ходе обработки контрольной точки сервер Oracle уже записал измененные блоки на диск. Как это понимать? Глава 2, "Буфер журнала повторного выполнения", стр. 108, повторяет на стр. 129Данные не задерживаются в буфере журнала повторного выполнения надолго. Содержимое этого буфера сбрасывается на диск: - раз в три секунды - при фиксации транзакции - при заполнении буфера на треть или когда в нем оказывается 1 Мбайт данных журнала повторного выполнения Не упомянут случай, когда сброс данных из log_buffer в online redo инициирует DBWn. Возможно, это упрощение. Но, imho, излишнее. Тогда уж следовало сказать "обычно сбрасывается на диск". Естественно, есть много мест, где Кайт сознательно идет на упрощение изложения, что на 100% оправдано. Подобные (сомнительные в моем понимании) места в тексте есть и далее, но это ни коим образом не умоляет ни достоинств самого автора, ни достоинств его великолепной книги. ... |
|||
:
Нравится:
Не нравится:
|
|||
28.07.2004, 21:18 |
|
Почему так медленно SELECT COUNT(*)
|
|||
---|---|---|---|
#18+
Markelenkov2 В. Затронутая тема сподвигла на перечитывание книги Кайта "Expert One-on-One Oracle" в русском переводе с пометкой некоторых мест. Исходного варианта не имею, поэтому не исключены случаи неточного перевода. Перечитал сегодня том 1 по стр. 130. Глава 2, "Активный журнал повторного выполнения", стр. 98Если необходимо обеспечить максимально быстрое восстановление, придется использовать файлы журнала меньшего размера...Со словом "придется" категорически не согласен. Хотя далее в том же абзаце: "Для сокращения времени восстановления можно изменять и другие параметры базы данных, а не только уменьшать размер файлов журнала повторного выполнения." Глава 2, "Области PGA и UGA", стр. 101Размер области PGA/UGA определяют параметры уровня сеанса в файле init.ora: SORT_AREA_SIZE и SORT_AREA_RETAINED_SIZE. Здесь точнее было бы сказать "определяют в наибольшей степени". Глава 2, "DBWn - запись блоков базы данных", стр. 129...записи в активный журнал повторного выполнения можно пропустить , если в ходе обработки контрольной точки сервер Oracle уже записал измененные блоки на диск. Как это понимать? Глава 2, "Буфер журнала повторного выполнения", стр. 108, повторяет на стр. 129Данные не задерживаются в буфере журнала повторного выполнения надолго. Содержимое этого буфера сбрасывается на диск: - раз в три секунды - при фиксации транзакции - при заполнении буфера на треть или когда в нем оказывается 1 Мбайт данных журнала повторного выполнения Не упомянут случай, когда сброс данных из log_buffer в online redo инициирует DBWn. Возможно, это упрощение. Но, imho, излишнее. Тогда уж следовало сказать "обычно сбрасывается на диск". Естественно, есть много мест, где Кайт сознательно идет на упрощение изложения, что на 100% оправдано. Подобные (сомнительные в моем понимании) места в тексте есть и далее, но это ни коим образом не умоляет ни достоинств самого автора, ни достоинств его великолепной книги. Sorry, Ya vchera ne smotrela knizhku - rabotala do 11 vechera. Segodna ne znau kak budet, no ya obazatel'no v skorom vremeni posmotru i sravnu perevod. U mena takoe chuvstvo chto eto perevod. I eshe u mena minus: ya v osnovnom ne ponimau russkuu litaraturu po Oracle, mne trudno dogadivat'sa kakie termini chto oznachaut. ... |
|||
:
Нравится:
Не нравится:
|
|||
28.07.2004, 21:56 |
|
Почему так медленно SELECT COUNT(*)
|
|||
---|---|---|---|
#18+
Глава 2, "Активный журнал повторного выполнения", стр. 98Если необходимо обеспечить максимально быстрое восстановление, придется использовать файлы журнала меньшего размера...Со словом "придется" категорически не согласен. Хотя далее в том же абзаце: "Для сокращения времени восстановления можно изменять и другие параметры базы данных, а не только уменьшать размер файлов журнала повторного выполнения." Я не знаю, что такое Активный журнал повторного выполнения. Глава 2 называется "Архитектура". Я еще посмотрю, может, додумаюсь, что это за журнал, а пока буду писать, что понимаю. Ага, я теперь знаю, что это REDO BUFFER. Ну вот. Русский перевод неверный . Том пишет (простите, я перевожу на ходу и не редактирую, надуюсь, вы поймете): Грубо говоря, содержание REDO BUFFER вымывается: Каждые три секунды или Когда кто-то COMMIT, Когда он наполняется на одну треть или содержит 1 мег словленной REDO log информации. Поэтому иметь размер REDO BUFFER в порядке многих десятков Мег обычно означает расточительское использование хорошей памяти. Для того, чтобы использовать REDO BUFFER cache, например в 6 Мег, вам надо ранить очень долгий процесс который генерирует 2 мег REDO log каждые три секунды или меньше. Если в течение этого времени кто-то COMMIT, вы никогда не используете эти 2 мег места REDO log; оно будет постоянно вымываться. Глава 2, "Области PGA и UGA", стр. 101Размер области PGA/UGA определяют параметры уровня сеанса в файле init.ora: SORT_AREA_SIZE и SORT_AREA_RETAINED_SIZE. Здесь точнее было бы сказать "определяют в наибольшей степени". Вы правы, Том именно так и сказал, в русской версии неточный перевод: " One of the largest impacts on the size of your PGA/UGA will be in the init.ora on session-level parameters, SORT_SIZE and SORT_AREA_RETAINED_SIZE". Глава 2, "DBWn - запись блоков базы данных", стр. 129...записи в активный журнал повторного выполнения можно пропустить , если в ходе обработки контрольной точки сервер Oracle уже записал измененные блоки на диск. Как это понимать? Это надо спросить переводчика. Читаю и перерчитываю главку "DBWn - Database Block Writer" - и не вижу ничего, даже отдаленно напоминающего то, что вы цитируете. Вот опять для верности перечитала и НИЧЕГО ТАКОГО не увидела. Зато поняла, что такое "Активный журнал повторного выполнения" - это REDO BUFFER. Пойду к вашей первой цитате и посмотрю, что там. Глава 2, "Буфер журнала повторного выполнения", стр. 108, повторяет на стр. 129Данные не задерживаются в буфере журнала повторного выполнения надолго. Содержимое этого буфера сбрасывается на диск: - раз в три секунды - при фиксации транзакции - при заполнении буфера на треть или когда в нем оказывается 1 Мбайт данных журнала повторного выполнения Не упомянут случай, когда сброс данных из log_buffer в online redo инициирует DBWn. Возможно, это упрощение. Но, imho, излишнее. Тогда уж следовало сказать "обычно сбрасывается на диск". Это место я уже перевела в начале. Фраза "или когда в нем оказывается 1 Мбайт данных журнала повторного выполнения" у Тома звучит так: "When it gets one third full or contains 1 MB of catched redo log data". Вы правы, Том действительно сознательно идет на упрощение, так как он употребил выражение "In fact", которое можно перевести как "в общих чертах", "в общем", "грубо говоря", и пр. "In fact" означает генеральную идею, без подробностей. Насколько я поняла, перевод не слишком хороший. Наверное, кто-то наспех сделал. ... |
|||
:
Нравится:
Не нравится:
|
|||
29.07.2004, 04:28 |
|
Почему так медленно SELECT COUNT(*)
|
|||
---|---|---|---|
#18+
Я подробно ответила на твое сообщение, но когда я кликнула на Опубликовать, мне пришел ответ что-то вроде "У вас нет права публиковать сообщение на этом форуме". Я пошла назад, но моего текста уже не было. Не хочу все повторять, сил нет, но вкратце - твой анализ блестящ, наши DBA тебе в подметки не годятся и они бы не поняли почти ничего из того, что ты написал и что хорошо бы было обо всем этом спросить у Тома. ... |
|||
:
Нравится:
Не нравится:
|
|||
29.07.2004, 05:04 |
|
Почему так медленно SELECT COUNT(*)
|
|||
---|---|---|---|
#18+
В.Я не знаю, что такое Активный журнал повторного выполнения... ...Ага, я теперь знаю, что это REDO BUFFER. Ну вот. Русский перевод неверный. ...Зато поняла, что такое "Активный журнал повторного выполнения" - это REDO BUFFER. Похоже, Вы путаете log_buffer ( часть оперативной памяти для накопления redo-информации перед сбросом на диск в online redo files) и online redo (текущие, активные, имеющие статус ACTIVE в select status from v$log журнальные файлы или один файл , если online redo не дублируются). В.Это надо спросить переводчика. Читаю и перерчитываю главку "DBWn - Database Block Writer" - и не вижу ничего, даже отдаленно напоминающего то, что вы цитируете Постараюсь, когда приду домой, дать более точные координаты фразы про DBWn. Мне интересно увидеть исходный текст (in English) этого места. К сожалению, уезжаю на днях в отпуск, времени мало. На счет других, процитированных мной мест, - понятно. Это, видимо, некоторые погрешности перевода. В.Насколько я поняла, перевод не слишком хороший. Наверное, кто-то наспех сделал.Переводил В. Кравчук, даю ссылки: /topic/27157&pg=1 http://ln.com.ua/~openxs/projects/oracle http://ln.ua/~openxs/projects/oracle/expert.html Перевод достаточно хороший. Были некие дискуссии о терминологии, но это мелочи. А ошибки и опечатки бывают у всех. Тем более, автор перевода готов принять их список. Я, было, начал делать пометки опечаток карандашом, но потом устал и бросил. По поводу русских терминов. В основном они идут отсюда: http://www.rdtex.ru/docs/glossary/ Рекомендую. По поводу последней фразы - не надо преувеличивать мои заслуги. Я, например, Факеру в подметки не гожусь. Тогда на какую часть его подошвы пускать Ваших админов? ;-) Одна надежда, что Fucker босиком и летом, и зимой бегает :-) ... |
|||
:
Нравится:
Не нравится:
|
|||
29.07.2004, 14:22 |
|
Почему так медленно SELECT COUNT(*)
|
|||
---|---|---|---|
#18+
По поводу последней фразы - не надо преувеличивать мои заслуги. Я, например, Факеру в подметки не гожусь. Тогда на какую часть его подошвы пускать Ваших админов? ;-) Одна надежда, что Fucker босиком и летом, и зимой бегает :-)[/quot] Мой последний постинг был как раз ему (F-ру). Я ему подробно написала, но у меня постинг не прошел и исчез. Надо было его имя в обращении поставить, но у меня рука не поворачивается такие слова писать :) Вы тоже здорово во всем разбираетесь, между прочим, завидую. Мне было интересно сравнивать русский переовд с оригиналом. Если получится до отпуска (опять я вам тут завидую!), подкиньте еще что-нибудь интересное. ... |
|||
:
Нравится:
Не нравится:
|
|||
29.07.2004, 16:33 |
|
Почему так медленно SELECT COUNT(*)
|
|||
---|---|---|---|
#18+
В. Мой последний постинг был как раз ему (F-ру). Я ему подробно написала, но у меня постинг не прошел и исчез. Надо было его имя в обращении поставить, но у меня рука не поворачивается такие слова писать :) тогда зовите его ласково Фунтик ... |
|||
:
Нравится:
Не нравится:
|
|||
29.07.2004, 17:26 |
|
Почему так медленно SELECT COUNT(*)
|
|||
---|---|---|---|
#18+
Markelenkov...online redo (текущие, активные, имеющие статус ACTIVE в select status from v$log журнальные файлы или один файл, если online redo не дублируются). Бес попутал... Конечно же - online redo, это все журнальные файлы, которые отображаются в v$log, а текущие (current), или иначе иногда не совсем корректно называемые активные, имеют статус CURRENT в v$log. В.Мой последний постинг был как раз ему (F-ру). Ну тогда я спокоен... В.наши DBA тебе в подметки не годятся и они бы не поняли почти ничего из того, что ты написал А Вы им покажите, Fucker все очень правильно и доходчиво написал. Должны понять. ... |
|||
:
Нравится:
Не нравится:
|
|||
29.07.2004, 17:38 |
|
|
start [/forum/topic.php?fid=52&msg=32624493&tid=1905960]: |
0ms |
get settings: |
8ms |
get forum list: |
14ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
27ms |
get topic data: |
7ms |
get forum data: |
2ms |
get page messages: |
68ms |
get tp. blocked users: |
1ms |
others: | 306ms |
total: | 441ms |
0 / 0 |