Сделано в России

Александр Соколов
Компания РДТЕХ
(mailto:ap_sokolov@mail.ru)
(под редакцией М. Р. Когаловского,
kogalov@cemi.rssi.ru)

О чистоте русского языка и точности терминологии
(часть XX)

• Введение
• Из переписки
• recovery
• process freelist
• lazy loading
• feature
• Oracle-Managed File
• subclause
• fuzzy file
• wrap, wrapper, wrapper type
• tree-structured query

Введение

Данный выпуск колонки посвящен продолжению обсуждения терминологических вопросов, возникших в процессе перевода комплекта документации СУБД Oracle9i, который был выполнен компаниями РДТЕХ (www.rdtex.ru) и ITI Ltd. (www.iti.ru).

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

Из переписки

recovery
В связи с появлением и развитием архитектуры Oracle Real Applications Cluster в разных книгах появились разные трактовки данного термина. Приведем несколько определений.

recovery (восстановление, по глоссарию)

The application of redo data or incremental backups to database files in order to reconstruct lost changes. The three types of recovery are instance recovery, crash recovery, and media recovery. Oracle performs the first two types of recovery automatically using online redo records; only media recovery requires you to restore a backup and issue commands. Only Recovery Manager can recover datafiles by applying incremental backups. (Backup and Recovery Concepts)

instance recovery (восстановление экземпляра, по глоссарию)

• The automatic application of redo log records to Oracle uncommitted data blocks after a crash or system failure. (Performance Tuning Guide and Reference)
• Recovery of an instance in the event of software or hardware failure, so that the database is again available to users. If the instance terminates abnormally, then the instance recovery automatically occurs at the next instance startup. (SQL*Plus User's Guide and Reference)
• In an Oracle Real Applications Cluster configuration, the application of redo data to an open database by an instance when this instance discovers that another instance has crashed. A surviving instance automatically uses the redo log to recover the data in the instance's buffer cache. Oracle undoes any uncommitted transactions that were in progress on the failed instance when it crashed and then clears any locks held by the crashed instance after recovery is complete. (Backup and Recovery Concepts)

crash recovery (???)

The automatic application of online redo records to a database after either a single-instance database crashes or all instances of an Oracle Real Applications Cluster configuration crash. Crash recovery only requires redo from the online logs: archived redo logs are not required.

In crash recovery, an instance automatically recovers the database before opening it. In general, the first instance to open the database after a crash or SHUTDOWN ABORT automatically performs crash recovery. (Backup and Recovery Concepts)

media recovery (восстановление носителя, по глоссарию)

The application of redo or incremental backups to a restored backup datafile or individual data block to bring it to a specified time. Datafile media recovery always begins at the lowest SCN recorded in the datafile headers.

When performing media recovery, you can recover:

• The whole database
• A tablespace
• A datafile
• A set of blocks within a datafile

If you use all redo data, you perform complete recovery; if you use only part of the redo data, you perform incomplete recovery. Typically, you perform media recovery after a media failure damages some or all of the database files (datafiles, control files, or online redo logs). (Backup and Recovery Concepts)

Вопрос М. Вольштейна (Mark.Volshtein@iti.ru).
Если использовать термины из глоссария, возникает проблема при переводе фразы "crash or instance recovery", встречающиеся очень часто.

Кроме того, как следует из определения (the application of redo data to an open database by an instance when this instance discovers that another instance has crashed – Oracle9i Backup and Recovery Concepts), instance recovery – это восстановление не экземпляра, а восстановление базы данных (уцелевшим) экземпляром.

Может быть, следует исправить перевод "instance recovery" на "восстановление с помощью уцелевшего экземпляра"?

Временное предложение А. Соколова.
Ваше предложение создаст, по моему мнению, проблемы при переводе других фраз. Действуйте пока по контексту, пишите что-то типа: "применение журнальных данных...".

Комментарий А. Соколова.
Мне кажется, общий перевод термина "instance recovery" как "восстановление экземпляра" нужно сохранить до наведения единообразия во всем комплекте документации Oracle, в случае Real Applications Cluster действовать по контексту, а "crash recovery" переводить как "восстановление системы (баз(ы) данных) (после фатального сбоя)". В данном определении есть недостаток: не ясно, выполняется ли также восстановление носителя.

Комментарий С. Мисюры (misiura@rdtex.ru).
Что касается классического термина "instance recovery", то его содержательный смысл – "восстановление экземпляра", судя по приведенному определению, не изменился в версии 9.2 (даже в контексте Oracle RAC). По-прежнему он означает восстановление ОДНОГО экземпляра (точнее говоря – кеш-буфера экземпляра). Сюда же входит случай, когда после отказа ОДНОГО из экземпляров Oracle RAC, какой-то из оставшихся в работе экземпляров восстанавливает отказавший экземпляр, воспроизводя в своем кеш-буфере изменения отказавшего экземпляра и откатывая незавершенные транзакции.

Термин "crash recovery" означает то же, что и "instance recovery" – восстановление экземпляра после его отказа. Если буквально интерпретировать приведенные определения этих терминов, то "crash recovery" – понятие более общее, чем "instance recovery", так как оно применимо не только к ситуации восстановления одного экземпляра, но и к ситуации восстановления НЕСКОЛЬКИХ экземпляров (Oracle RAC). В этом случае запускаемый экземпляр восстанавливает в своём кеш-буфере изменения нескольких отказавших экземпляров.

Предлагаю термины "instance recovery" и "media recovery" не менять, поскольку их содержательный смысл остался прежним. Для термина "crash recovery" предлагаю варианты: "восстановление транзакций" или "восстановление изменений транзакций" (длиннее, но точнее).

Словосочетание "crash or instance recovery" переводить как "восстановление изменений транзакций или восстановление экземпляра"

(смысл: "восстановление изменений транзакций, что иначе называется восстановлением экземпляра"). Предательский союз "или", который в одних случаях означает взаимоисключающую альтернативу, а в других случаях эквивалентен словосочетанию "иначе говоря", сильно затрудняет смысловое понимание фразы "восстановление изменений транзакций или восстановление экземпляра" (те же проблемы, кстати, возникают и в английском языке). Поэтому, возможно, было бы правильнее "crash recovery" переводить так же как и "instance recovery" – термином "восстановление экземпляра". И так же переводить фразу "crash or instance recovery" – термином "восстановление экземпляра".

Комментарий А. Бачина (abachin@fors.ru).
Отвечаю сходу, немедленно, чтобы дискуссия не развивалась в ненужную сторону. Поэтому мои слова могут быть даже сбивчивы и не до конца обоснованы.

Дело в том, что в случае кластеризированной архитектуры мы имеем качественно иную ситуацию, нежели при работе с одиночным экземпляром. В последнем случае крах экземпляра вызывал остановку функционирования системы базы и ее восстановление (той или иной степени тяжести) по файлам redo log (журнала регистрации изменений базы). В кластерном случае база продолжает работать, а восстанавливается экземпляр. Это принципиальная разница, так как восстановление экземпляра может идти опять же по файлам redo log (напомню, что redo log для каждого экземпляра кластера – собственный!!!), но можно и ускорить и облегчить этот процесс, используя сохранившиеся SGA других экземпляров той же базы. С большой степенью вероятности они хранят в себе достаточно много данных, метаинформации и пр., что погибло в аварийно остановленном экземпляре. Поэтому возможно их использование для восстановления аварийного экземпляра.

Что, собственно говоря, и имелось в виду, по моему, под термином "instance recovery", что достаточно правильно и понятно отражает перевод этого термина как "восстановление с помощью уцелевшего экземпляра". Я бы только добавил (возможное) множественное число для уцелевших экземпляров.

Комментарий А. Пересыпкина (aperesypkin@mail.ru).
Мне сейчас при переводе встретился термин instance recovery, поэтому я внимательнее посмотрел его описание и пришёл к выводу, что в словаре дан правильный перевод, потому что это действительно восстановление экземпляра в случае программного или аппаратного сбоя (Recovery of an instance in the event of software or hardware failure), которое может выполняться другим экземпляром, как об этом говорится в следующей фразе: When an instance fails and the failure is detected by another Oracle instance, Oracle performs the following recovery steps.(Далее описываются действия по восстановлению.)

crash recovery – это восстановление после сбоя экземпляров, или более кратко: восстановление после сбоя. Для контекста могу привести такую фразу: Crash recovery (recovery after instance failure) and media recovery of many datafiles on many different disk drives are good candidates for parallel recovery.

media recovery – это восстановление файлов данных, хотя, наверно, лучше оставить прежний перевод восстановление носителя, чтобы сохранилась согласованность с прежними переводами.

Комментарий С. Мисюры.
Замечание к комментарию А. Бачина.
Термин "instance recovery" используется как в контексте Oracle RAC (и тогда он означает восстановление уцелевшим экземпляром изменений из кеш-буфера отказавшего экземпляра), так и вне этого контекста (когда с б/д работает один экземпляр). Содержательный смысл этого термина в обоих случаях одинаков, поэтому не вижу оснований переводить термин "instance recovery" как "восстановление с помощью уцелевшего экземпляра". Зачем искусственно усложнять себе работу, переводя "instance recovery", в зависимости от смыслового контекста, то как "восстановление с помощью уцелевшего экземпляра", то как "восстановление экземпляра", если содержательный смысл этого термина одинаков во всех возможных контекстах?

Замечание к комментарию А. Пересыпкина.
Термин "восстановление после сбоя" – неадекватный перевод исходного "crash recovery", т.к. сбои бывают разными (в т.ч. возможен "сбой носителя", который здесь не подразумевается). "Восстановление после сбоя экземпляра" – слишком длинно, и неясно, как в этом случае переводить словосочетание "crash or instance recovery" – ведь не "восстановление после сбоя экземпляра или восстановление эземпляра" же?

Резюме.
В результате дискуссии только укрепился в собственном мнении:

1. "instance recovery" по-прежнему переводить (всегда) как "восстановление экземпляра";
2. "media recovery" по-прежнему переводить как "восстановление носителя";
3. "crash recovery" переводить как "восстановление экземпляра" или, если смысловой контекст требует другого варианта для этого термина (например, встречается оборот "crash or instance recovery") – переводить как "восстановление изменений транзакций".

Комментарий А. Соколова.
В Oracle9i Real Application Clusters Concepts восстановление после сбоя одного или нескольких экземпляров называется также Database Recovery и состоит из нескольких этапов:

1. Remastering Global Cache Service Resources of the Failed Instance.
2. Instance Recovery.

В свою очередь во время Instance Recovery выполняются:

1. Cache Recovery.
2. Transaction Recovery.

For cache recovery, Oracle replays the online redo logs of the failed instance. Transaction recovery comprises rolling back all uncommitted transactions of the failed instance. Uncommitted transactions are in-progress transactions that did not commit.

В таком случае словосочетание "восстановление изменений транзакций" означает непонятно что. Уж лучше оборот "crash or instance recovery" переводить как "восстановление экземпляра", помня при этом, что есть два вида "восстановления экземпляра", то есть исходить из контекста.

Комментарий А. Соколова после завершения перевода.
Редактором книги Oracle9i. Концепции резервирования и восстановления предложен вполне удачный перевод термина "crash recovery" как "аварийное восстановление". Переведенное определение этого термина имеет следующий вид:

"Автоматическое применение журнальных записей к базе данных после аварийного завершения работы единственного экземпляра базы данных или всех экземпляров в конфигурации Real Applications Clusters. Для аварийного восстановления требуются только записи оперативного журнала – архивные журналы не нужны.

При аварийном восстановлении экземпляр перед открытием базы данных автоматически восстанавливает базу данных. Как правило, автоматическое восстановление выполняется тем экземпляром, который первым открывает базу данных после аварийного завершения работы или выполнения оператора SHUTDOWN ABORT".

Резюме.

• "instance recovery" – "восстановление экземпляра";
• "media recovery" – "восстановление носителя";
• "crash recovery" – "аварийное восстановление".

Комментарий М. Р. Когаловского.
"аварийное восстановление" – это ложно ориентирующий термин, как говорят в терминографии. Само восстановление ведь отнюдь не аварийное. Речь идет о восстановлении в случае аварийной ситуации. Поэтому я бы предпочел "восстановление при (или "в случае") аварийной ситуации".

Резюме.
"crash recovery" – "восстановление при (или "в случае") аварийной ситуации"

process freelist

Контекст, приведенный переводчиком.
A process freelist holds a linked list of blocks that have free space available for any new processes that wish to insert data into the segment.

Предложение переводчика.
"список свободных блоков для процессов" со ссылкой на http://www.jlcomp.demon.co.uk/app_d.html.

Комментарий А. Соколова.
В документации Oracle я не обнаружил определения термина "process freelist", поскольку, по всей видимости, он относится к внутренним механизмам СУБД и никак не управляется пользователями. Тем более, продолжим цитату из ссылки: (I have called this a 'transaction freelist' in the book, and should probably have called it a segment freelist anyway – and will do so from here on)".

В документации Oracle термины "process freelist" и "freelist" используются как синонимы: "A freelist is a list of free data blocks that usually includes blocks existing in a number of different extents within the segment. Blocks in freelists contain free space greater than PCTFREE. This is the percentage of a block to be reserved for updates to existing rows. In general, blocks included in process freelists for a database object must satisfy the PCTFREE and PCTUSED constraints. (Database Performance Tuning Guide and Reference)

Следовательно, в обоих случаях можно переводить как "список свободных блоков".

Замечание Н. Костюкевич (Natalia.Kostioukevitch@iti.ru).
Списки свободных блоков бывают разные ("master freelist", "transaction freelist" и т.д.). Поэтому нужно указывать, что за список.

Комментарий А. Соколова.
В документации Oracle вообще отсутствует термин "transaction freelist", согласно http://www.jlcomp.demon.co.uk/app_d.html его можно перевести как "транзакционный список свободных блоков" или "список свободных блоков транзакции" (A transaction freelist holds a linked list of blocks which have been made free by a single transaction.).

Термин "master freelist" в документации Oracle встречается (без определения) дважды: в SQL Reference (в контексте Real Application Clusters) и в Supplied PL/SQL Packages and Types Reference (в контексте перестройки списков свободных блоков объекта схемы (таблицы или индекса), когда объект не имеет групп списков свободных блоков). Его можно перевести как "главный список свободных блоков".

Термин "process freelist" используется (без определения) в Database Reference в описаниях представлений словаря базы данных типа: ALL_ALL_TABLES, ALL_CLUSTERS, ALL_INDEXES и т.д. в контексте количества списков свободных блоков, выделенных сегменту, а также один раз в Database Performance Tuning Guide and Reference в том же контексте (продолжим цитату из предыдущего комментария: "Specify the number of process freelists with the FREELISTS parameter".). Согласно http://www.jlcomp.demon.co.uk/app_d.html термин "process freelist" является синонимом термина "segment freelist" (см. цитату в предыдущем комментарии), там же: "When you create a table using the default value of the FREELISTS storage parameter, Oracle allocates a single segment freelist in the segment header block; if you then insert a row into that table, Oracle will attach a few blocks to that free list." Следовательно, термин "process freelist" можно переводить и как "список свободных блоков (сегмента)".

lazy loading

Вопрос А. Пересыпкина.
В глоссарии нет слова lazy, а оно встретилось у меня в таком контексте: "Note that loading of the temporary space cache is lazy, and that instances can be dormant."

Поиск по документации и словарям показал, что слово lazy встречается только в сочетании с другими словами, например, Lazy Write, lazy type conversions, Lazy XML Load, Lazy Manifestation, Lazy Initialization и т.д. А отдельного термина Lazy нет. В данном случае нужно перевести термин lazy loading, но его определения в документации Oracle я не нашёл. В других словарях я нашёл следующие термины:

1. Lazy indexing = отложенное индексирование
2. lazy evaluation = принцип экономии работы (Алгоритм работы диспетчера виртуальной памяти. Действие, например подкачка, не выполняется, пока оно не становится абсолютно неизбежным.)
3. Lazy data model = модель поздней загрузки данных
4. lazy-write, lazy write = отложенная запись
5. lazy commit = отложенное подтверждение
6. lazy protocol registration – отложенная регистрация протоколов

Предлагаю следующий вариант перевода:

lazy loading = отложенная загрузка

А фразу: "Note that loading of the temporary space cache is lazy, and that instances can be dormant." предлагаю перевести так: "Загрузка кеша временного пространства выполняется в отложенном режиме, а экземпляры могут быть неактивными."

Резюме.
"lazy loading" = отложенная загрузка

feature

Контекст.
"Oracle Managed Files feature" (Database Administrator’s Guide)

Предложение переводчика.

"функция управления файлами"
Предложение А. Соколова.

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

Oracle-Managed File

Предложение переводчика.
"файл, управляемый Oracle" (Database Administrator’s Guide)

Комментарий А. Соколова.
Наверное, иногда следует указывать, что это – "файл, управляемый сервером (базы данных)", а не корпорацией Oracle. Хотя бы в заголовках разделов, согласно определению:

"A file that is created automatically by the Oracle database server when it is needed and automatically deleted when it is no longer needed." (Oracle9i Backup and Recovery Concepts)

subclause

Контекст.
The rules are very similar to those for table partitions, but unlike the MODIFY PARTITION clause for ALTER TABLE, there is no subclause to rebuild an unusable index partition, but there is a subclause to coalesce an index partition or its subpartitions. (Database Administrator's Guide)

Предложение переводчика.
"расширение предложения"

Контекст.
The DATAFILE subclause of the UNDO TABLESPACE clause is optional and a filename is not required in the file specification. (Database Administrator's Guide)

Предложение переводчика.
"суб-предложение"

Предложение А. Соколова.
"атрибут предложения"

Замечание А. Бачина.
Или я что-то не понимаю, или процесс обсуждения плавно зацикливается, или переводчики не пользуются уже наработанным материалом, или ...

Кажется ведь, что пришли к согласию: "statement" – "предложение", "clause" – "фраза". И тогда: "subclase" – "часть фразы" или (что лучше) "подфраза".

Ответ А. Соколова.
У нас достигнута договоренность: "statement" – "оператор" или "команда", "clause" – "предложение" или "фраза". Переводчики повсеместно используют термины: "оператор" и "предложение".

О "фразе" и "предложении". По Ожегову и Шведовой:

• "фраза" – "законченное высказывание (в грамматике: любая интонационно оформленная синтаксическая единица, содержащая сообщение, фраза)"…
• "предложение" – 1. "В грамматике: любая синтаксически и интонационно оформленная конструкция, выражающая сообщение". 2. Существительное от глагола "предложить". 3. "То, что предложено, предлагается."…

Мне в "предложении" как раз нравится его двусмысленность, которая как раз соответствует контексту. Аналогичная ситуация была в свое время с термином "представление". Обсуждение этого вопроса с филологами см. в http://gramota.ru/buro.html?gotoq=67266.

"Подфраза", на мой взгляд, смотрится не очень хорошо в конструкциях типа "подфраза А фразы В". Более привлекательно: "атрибут А фразы В".

Замечание А. Бачина.
Категорически против:

1. Атрибут предполагает наличие домена значений.
2. Термин "подфраза" ничем не лучше, не хуже чем "подгруппа", "подпространство" и т.д. – хоть архитектурное единство терминологии сохраняется.
3. Так и не могу понять, почему прямой(!!) перевод "statement" = "предложение" нужно заменять иностранным термином "оператор", у которого и без того многовато значений.

1. Атрибут необязательно предполагает наличие домена значений. Например, в http://www.kolbi.ru/cgi/dict/s.pl: 1. атрибут # от лат. attributum – присовокупленное. Признак объекта в системе, показывающий его состояние, например атрибуты файла: "архивный", "скрытый", "системный", "только для чтения" (см. также data attribute, directory attribute, file attribute, line attribute); 2. существенный признак, свойство, характеристика чего-либо.
2. Термин "подфраза" меня не так смущает, как логически вытекающая необходимость введения термина "подпредложение" (второй допустимый и согласованный редакторами РДТЕХ вариант перевода "clause" – "предложение").
3. Если обратиться к Энциклопедии М. Р. Когаловского, публикациям в "Открытых системах", материалам http://www.citforum.ru/, в частности, к статьям и переводам уважаемого профессора С. Д. Кузнецова, то практически всегда и везде " SQL statement" переводится как "оператор". Зачем изобретать велосипед и не пользоваться авторитетными источниками.

Комментарий М. Р. Когаловского.
Поддерживаю мнение Анатолия. Мне кажется, использовать вариант “атрибут” здесь не следовало бы. Все-таки разговор идет в контексте реляционных баз данных. Вполне может встретиться высказывание о предложении (или операторе – как хотите) SQL, в котором одновременно упоминаются термины subclause и attribute. И как тогда поступать в таком случае?

fuzzy file

Контекст.
A datafile that contains at least one block with an SCN more recent than the checkpoint SCN in its header. For example, this situation occurs when Oracle updates a datafile that is in backup mode. A fuzzy file that is restored always requires recovery. (Oracle9i Backup and Recovery Concepts)

Предложение М. Вольштейна.
"файл, измененный с момента последней контрольной точки" или просто "измененный файл".

Проблема в том, что этот термин встречается в книге только в глоссарии и только один или два раза (причем один раз – когда ему дается определение, примерно совпадающее с первым вариантом перевода, то есть может получиться тавтология).

Комментарий Н. Костюкевич.
Слово "измененный" совершенно не соответствует слову "fuzzy". Ведь основной смысл английского термина не в том, что файл изменился, а в неясности его состояния (какие там были SCN после контрольной точки, что записано на диск, а что нет, и т.п.).

Слово "fuzzy" в математике уже давно имеет эквивалент "нечеткий". Предлагаю назвать и эти файлы нечеткими. Дело не только в этой книге. Этот термин очень важен в концепции согласованного резерва (consistent backup) и может встретиться в других местах. Давайте сделаем его таким, чтобы он позволял отличить одно понятие от другого.

Комментарий А. Криушина (kriushin@rdtex.ru).
"файл, измененный с момента последней контрольной точки" – абсолютно верно. Просто "измененный файл" – увы, не просто.

Проблема в том, что если АБД выполнил резервирование "вручную", позабыв выполнить оператор ALTER TABLESPACE ... BEGIN BACKUP, то при восстановлении (RECOVER) такой резервной копии ему будет указано, что резервная копия файла – "fuzzy". Фактически, такая копия непригодна для восстановления.

С другой стороны, в представлении V$DATAFILE_HEADER есть столбец "FUZZY", что обычно свидетельствует о нахождении файла в режиме горячего резервирования.

Комментарий А. Соколова.
Перевод "измененный файл" совершенно не соответствует контексту.

Термин "fuzzy" в математике уже давно имеет эквивалент "нечеткий" в достаточно строго определенном контексте. В Интернете также встречаются такие понятия, как теория "нечетких баз данных" (http://www.tora-centre.ru/library/fuzzy/fuzzy-.htm), технология "нечеткого индекса" (http://www.pcweek.ru/Year2000/N16/CP1251/Strategy/chapt1.htm) и т.п., но все эти понятия так или иначе связаны с "нечеткой логикой". Поэтому перевод "нечеткий файл" будет, с моей точки зрения, вводить в заблуждение читателей.

Вместе с тем, существует термин "fuzzy bаckup", который в Интернете переводится как "нечеткое (резервное) копирование" (http://www.osp.ru/dbms/1998/03/06.htm) или "размытое резервное копирование" ("…резервное копирование обычно осуществляется при работающей (online) базе данных. Этот процесс называется “размытое (“fuzzy”) резервное копирование”, потому что он выполняется на протяжении некоторого отрезка времени. Если в процессе резервного копирования экстентов базы данных происходят какие-либо изменения, процесс копирования безусловно продолжается. – http://www.cna.ru/library/articlesdir/big98.html?156).

Почему бы не переводить "fuzzy file" как "размытый" файл данных, если считать это термином?

Комментарий А. Криушина.
Не против. По крайней мере, это будет уникальным термином в документации.

Комментарий М. Р. Когаловского.
Замена “нечеткий” на “размытый” никак не меняет дела. Если говорить о математике, то действительно нужно вспомнить введенный Заде термин “fuzzy set”, который переводится на русский язык как “нечеткие множества”. Но часто используется и синоним - “размытые множества”. Позднее стали говорить о “fuzzy logics”, хотя этот термин переводят как “нечеткая логика”.

Комментарий А. Пересыпкина.
Нашёл в своей базе данных среди старых переводов такой вариант: "fuzzy file" = "неполный файл".

Комментарий А. Бачина.
Предлагаю вариант не буквального, но смыслового перевода этого термина: "fuzzy file" – "продвинутый (или продвинувшийся) файл", ибо смысл явления в том, что файл "ушел" (продвинулся) за контрольную точку. Термин же "нечеткий" или "размытый" (вот ужас-то!) такой смысловой нагрузки не несет.

Комментарий А. Криушина.
Как и английское слово "fuzzy" применительно к ситуации.

К тому же не следует забывать, что ВСЕ файлы данных в открытой базе бОльшую часть времени – "fuzzy", т.е. содержат изменения позже контрольной точки. Здесь же обсуждается "продвинутость" файла только в контексте резервирования/восстановления – т.е. (в большинстве случаев) по отношению к контрольной точке НАЧАЛА РЕЗЕРВИРОВАНИЯ.

Как-то на курсах по Backup and Recovery один из студентов объявил, что нашел перевод fuzzy как "пушистый" – всем понравилось. Поскольку о терминологии договорились, то потом на практикуме недоразумений не было – все с удовольствием "выдирали пух" из fuzzy-файлов.

Комментарий Н. Костюкевич.
Я не проверяла Интернет и мне пока не очень ясно, как вы выбрали между "нечетким" и "размытым" (даже если это где-то и сказано, это не значит что термин общепринят), но если ваши коллеги не возражают против слова "размытый", я тоже его приму. Просто слово "нечеткий" гораздо более распространено в специальных терминах. Достаточно заглянуть в Lingvo. Но если вы все-таки предпочтете слово "размытый", лучше просмотреть весь диск по Oracle9i, выбрать все термины с "fuzzy" и внести их в словарь все сразу как "размытые".

Комментарий А. Соколова.
Термины с "fuzzy" используются в документации Oracle, по крайней мере, в двух контекстах. В обсуждаемом здесь контексте, а в продуктах типа Oracle Text, Oracle interMedia используется терминология нечеткой логики:"fuzzy matching" – "нечеткое сопоставление", "fuzzy query" – "нечеткий запрос" "fuzzy search" – "поиск на основе нечеткой логики" и т.п.

Комментарий С. Мисюры.
Поддерживаю вариант перевода "файл, измененный с момента последней контрольной точки" для термина "fuzzy file". Это максимально точный перевод. Правда, длинно. Сокращенный же вариант перевода "измененный файл" – не точен. Может быть, в качестве сокращенного варианта перевода использовать термин "несогласованный файл"?

Не поддерживаю идею использования термина "нечеткий файл" ("размытый файл"). Мало того, что этот термин не рождает, как мне кажется, никаких ассоциаций и предположений о содержательном смысле данного термина, он еще и "выпадает" из контекста остальной русскоязычной терминологии Oracle, и не соответствует традициям тех. литературы по информационным технологиям. Разве мыслимо в серьезной книге использовать термин "нечёткий файл"?

Комментарий Н. Костюкевич.
Мы хотим всего лишь найти термин, который:

1) соответствует оригиналу (т.е. слову "fuzzy")

2) позволяет отличить этот термин и эту ситуацию от множества других

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

Во-вторых, этот термин должен не повторять определение (слово "fuzzy" тоже не означает "файл, измененный с момента последней контрольной точки", однако разработчики сочли его подходящим для ситуации), а просто выделить этот понятие из других понятий, как правильно отметил Андрей Криушин. Для этого слова "нечеткий" и "неясный" также вполне подходят. К тому же, пара "fuzzy" – "нечеткий" уже давно устоялась в информатике, математике и т.п. Никто же не жалуется на то, что термин "нечеткая логика" (fuzzy logic) не объясняет, что же это такое.

Мы не изобретаем термины (это прерогатива разработчиков), а просто переводим их. Так давайте это и делать.

Резюме.
Перевод термина "fuzzy file" в русском техническом языке не обнаружен, поэтому мы вправе предложить свое решение: "файл, измененный с момента последней контрольной точки". Пусть длинно, но термин не распространен и у его авторов – во всем комплекте документации встречается только в одной главе и в глоссарии. В тех же случаях, когда слово "fuzzy" встречается в названиях соответствующих столбцов представлений словаря данных, их смысл следует переводить по контексту, что мы всегда и делали.

wrap, wrapper, wrapper type

Контекст.
PL/SQL and Java interoperate in the server. You can execute a PL/SQL package from Java or wrap a PL/SQL class with a Java wrapper so that it can be called from distributed CORBA and EJB clients.
…

For example, C has the union keyword and the void* pointer, and Java has the typeof operator and wrapper types such as Number. (Application Developer’s Guide – Fundamentals)

Предложение переводчика.
"wrapper type" – "тип свертки"

Комментарий М. Р. Когаловского.
Здесь смысл употребления этого термина вполне стандартный – тот, который он имеет в стандарте CORBA. Статья о нем есть в моей энциклопедии. Его нужно переводить как "обертка" или "адаптер".

Глагол "wrap" можно перевести как "обертывать" или "создавать обертку (адаптер)".

Относительно "wrapper type" наверное все ясно, если речь о Java. Но вот в CORBA такого термина нет. В языке определения интерфейсов IDL wrapper представляется своим интерфейсом.

Комментарий И. Абдуллина.
В документации 8.0 я переводил "PL/SQL Wrapper" как "Утилита свертки PL/SQL". В 9.2 я не стал возражать против предложенного переводчиком "Утилита Wrap для PL/SQL". Но там речь шла о программе, преобразующей исходный текст PL/SQL в некий внутренний код (можно предположить, что это код DIANA, хотя об этом ничего не сказано). Назначение этой утилиты – скрыть исходный текст.

Здесь же, согласитесь, другой случай: мне кажется, здесь больше подходит второй из приведенных М.Р.Когаловским терминов: "адаптер", м.б. "программный адаптер". Кстати, можно использовать и русское слово "переходник".

Что касается соответствия "wrapper type" то в приведенном контексте оно вызывает вопросы. Понятно же, здесь имеются в виду типы данных, используемые в адаптере. Как бы ни переводилось слово "wrapper", слово "тип" в этом контексте должно обязательно сопровождаться словом "данных", т.е. например, "wrapper type" – "тип данных адаптера"

Комментарий А. Соколова.
"wrapper type" – в документации по Java "wrapper" – обычно "класс-обертка", "класс-адаптер" или "класс-оболочка". Поскольку у "класса" в ООП есть синоним – "тип", то его можно не дублировать ("тип типа"...). Так что выбирать нужно из этих вариантов. Мне больше импонирует "класс-обертка", т.к. легче манипулировать с глаголом, да и слово русское и широко используется в ООП.

Комментарий И. Абдуллина.
Класс-обертка" звучит несколько обидно для класса. "Класс-адаптер" или "класс-оболочка" в этом плане кажутся лучше. Но не "тип свертки". В общем-то, наверное, мне, как дилетанту в этой области, не пристало здесь спорить.

Резюме.
"создавать адаптер", "адаптер", "класс-адаптер"

Комментарий М. Р. Когаловского.
Адаптер представляет собой объект, который инкапсулирует некоторый необъектный программный код. Этот объект относится к некоторому типу (классу). Я полагаю, что именно этот тип (класс) должен обозначать термин “wrapper type”.

tree-structured query

Контекст.
Row operators return or reference particular rows. ALL retains duplicate rows in the result of a query or in an aggregate expression. DISTINCT eliminates duplicate rows from the result of a query or from an aggregate expression. PRIOR refers to the parent row of the current row returned by a tree-structured query.

Старый перевод.
"запрос древовидной структуры"

Предложение И. Абдуллина.
"запрос, выполняющий обход дерева"

Предложение М. Вольштейна.
"иерархический запрос"

Комментарий А. Соколова.
Я согласен с Марком: "иерархический запрос". См., например,

• Иерархические запросы к таблице (CONNECT),
• Иерархические запросы,
• Мой Компьютер Weekly :: Любителям ORACLE на заметку,
• Relib.com: Дискуссия "Есть ли у SQL SERVER иерархический запрос".

Ответ И. Абдуллина.
Я согласен: "иерархический запрос".

Резюме.
"иерархический запрос"

Продолжение следует.