Режим stand in что это

8

Создание, управление и передача ассетов с помощью Arnold Stand-ins, USD и MaterialX. Третья часть

Это заключительная часть обзорной статьи об инструментах для обмена данными между системами визуализации.В первой части мы рассказывали об истории и возможностях формата Universal Scene Description (USD). Вторая была посвящена стандарту MaterialX и процессу экспорта и импорта USD-моделей. Сегодня же очень подробно поговорим об основных операторах Arnold Operators.

Механизм Arnold Operators

В новом проекте, который я выполнял параллельно с подготовкой публикации, мне потребовалось создать несколько вариантов мебели и инвентаря в магазинчиках и квартирах жилого комплекса. Чтобы избежать копирования моделей в сцене и по максимуму использовать ссылки, а также обеспечить рациональное использование памяти, было решено прибегнуть к применению API и инструментов Arnold Operators.

Изначальные модели готовятся к экспорту с назначением соответствующих имен объектов и материалов с текстурами, а затем с помощью форматов USD и MaterialX создаются 2-4 дополнительных варианта образа.

В данном разделе представлены основные операторы Arnold Operators и их ключевые возможности. Помните, что многие операции выполняются на основе Arnold Stand-in’s и обращений к данным, сохраненным в файлах USD и MaterialX.

Ключевым аспектом работы с Arnold Operators является проработка имен объектов или групп объектов. Это можно сделать заранее, проработав ключевые имена для геометрии, материалов и дополнительных эффектов.

Выполнив экспорт модели в файлы сцены Arnold (*.ass), USD (*.usd) или Alembic (*.abc), их можно импортировать в другую сцену с помощью Arnold Stand-ins и создать варианты образов – Arnold Looks – с применением инструментария Arnold Operators.

Меню Arnold Operators добавляет операторы к выделенному в файле USD-объекту

Каждый оператор взаимодействует с моделью с помощью выражений, в которых определены пути к объекту (поверхности), материалам, объемным эффектам и источникам света. Каждый выделенный в списке объект может быть изменен с помощью операторов и назначений. Это позволяет как вносить изменения, так и создавать несколько образов, связанных с одними и теми же объектами в сцене.

Важным преимуществом использования Arnold Stand-in’s и Arnold Operators является оптимизация использования оперативной памяти и внесение изменений в режиме реального времени. Ранее для оценки изменений мог требоваться перезапуск процесса визуализации. Сейчас это стало возможным напрямую в процессе интерактивной визуализации с помощью новых инструментов и API.

Основные типы операторов

Операторы позволяют опытным пользователям переписать любую часть сцены Arnold Renderer и изменять пространство сцены во время визуализации. Вероятно, одним из наиболее распространенных вариантов использования, является переопределение внутренних процедурных параметров (например, шейдеров) внутри файлов *.ass, USD или Alembic. Для этого вы должны знать содержимое узла и имена параметров, определенных внутри процедуры.

Узлы операторов выполняют назначение и переопределение параметров для каждого объекта (узла), включая связи и отложенные переопределения на процедурно сгенерированных узлах. Операторы также могут создавать узлы (MaterialX) и выполнять общие проверки и модификации в сцене.

Некоторые операторы предоставляют параметр выбора (выделения), который с помощью выражения с подстановочными знаками определяет, какие узлы обрабатываются оператором. Ниже будет приведен пример подобного выражения. Если оператор вычисляется в отношении процедуры, он связан с выражением выбора, как предполагается, относящимся к пространству имен процедуры (procedural’s namespace).

Операторы могут быть объединены в «граф операторов», который вычисляется от заданного целевого оператора. В сцене может существовать несколько индивидуальных графов операторов без связей, где для визуализации будет оцениваться только граф, связанный с целевым оператором, и графы операторов, подключенные к процедурным узлам.

Selection Expressions

• or (union);
• and (intersection);
• not (negation);
• and not (exclusion);
• () для вложенной области видимости.

Каждое выделение узлов использует глобальные шаблоны и регулярные выражения. Узел будет обрабатываться оператором, если выражение соответствует его имени. По умолчанию используется соответствие glob, если только выделение не заключено в кавычки регулярного выражения, то есть

Доступные Arnold Operators

Каждый оператор может быть связан с другими операторами и объектами в сцене с помощью Node Editor, что позволит визуализировать граф операторов и вносить в него изменения.

Каждый образ может быть создан в редакторе атрибутов при выделении узла Arnold Stand-ins. В свитке File Contents можно отобразить список всех объектов в импортируемом файле, создать образы (Looks) и связать с каждым из объектов определенные операторы и переопределения для атрибутов объектов, шейдеров, источников света и объемных эффектов.

Пример двух образов (looks) созданных с помощью Arnold Operators и MaterialX

Возможности и инструменты Arnold Stand-in

Вы можете экспортировать любой объект в файл формата *.ass, *.abc и *.usd. Процедурные элементы (также называемые замещающими или прокси) ссылаются на сохраненный на диске файл. Они позволяют сделать вашу рабочую сцену легкой и работоспособной, откладывая загрузку геометрических данных до процесса визуализации.

Arnold Stand-in в редакторе атрибутов Maya

Во время экспорта будут использоваться текущие настройки ядра визуализации Arnold. Таким образом, вам следует выполнить конфигурацию ядра визуализации перед экспортом Stand-ins. Например, вы должны выбрать, хотите ли вы экспортировать модель с активным Motion Blur или нет.

ПРИМЕЧАНИЕ. Шейдеры utility в режиме Object не работают с процедурными (заменяющими) объектами. Это известное ограничение. Например, цвет сфер меняется, когда utility shader находится в режиме Object. Тем не менее, цвет замещающего объекта остается прежним.

Совместное использование Arnold Procedurals между модулями.

Некоторые пользователи могут находиться в студийной среде, в которой может использоваться комбинация приложений Maya, 3ds Max, Houdini и Cinema 4D. Если система визуализации может найти и подключаемый модуль, и шейдеры, вполне возможно экспортировать Arnold Procedurals (*.ass) и повторно использовать их в других редакциях Arnold (и наоборот). Для этого необходимо убедиться, что переменная среда определения пути шейдеров Arnold ARNOLD_PLUGIN_PATH настроена на выбор наборов шейдеров обоих типов.

Рабочий процесс со Stand-ins выглядит следующим образом. Прежде чем вы сможете использовать Stand-ins, вам нужно сначала экспортировать модель, которая будет использоваться позже. Чтобы экспортировать модель, вы должны:

• выбрать объект, который желаете экспортировать;
• в меню выбрать Arnold => Scene Export => Export All/Selection to .ASS. То же самое можно выбрать для Alembic и USD;
• выбрать и ввести имя архива.

Ключевые атрибуты узла Arnold Stand-ins
Кроме того, вы можете экспортировать модель в качестве stand-ins с помощью меню File => Export All. Архив сохраняется в формате Arnold Scene Source (*.ass).

Экспортировать можно как отдельные объекты, так и целую иерархию, состоящую из нескольких объектов. Также можно экспортировать один или секвенцию кадров. В этом случае значение диапазона кадров в параметрах визуализации будет использоваться в именах файлов архивов. Чтобы использовать stand-ins, вам нужно создать примитив Arnold Stand-ins. Для этого используйте меню File => Import, File => Create Reference, или Arnold => StandIn (в зависимости от того, что вам удобнее), и выберите необходимый файл архива.

Это создаст узел Arnold Stand-in, который вы можете использовать вместо обычной геометрии. Рассмотрим ключевые атрибуты узла Stand-in. Этот узел обладает семью свитками, которые содержат следующие ключевые параметры:

Свиток File / Frame

Свиток File / Frame позволяет управлять файлом с описанием сцены и данными, которые будут импортированы в сцену в процессе визуализации.

• name.#.ext – т.е. name.1.ext, name.2.ext, name.3.ext, . , name.10.ext, . , name.100.ext, .
• name.##.ext – т.е. name.01.ext, name.02.ext, name.03.ext, . , name.10.ext, . , name.100.ext, .
• name.###.ext – т.е. name.001.ext, name.002.ext, name.003.ext, . , name.010.ext, . , name.100.ext, .
• name####.###.ext – обозначает четырехзначное заполнение для номеров кадров и трехзначное заполнение для номера подкадра (subframe).

ПРИМЕР. Если мы укажем на файл с именем scene_001.ass, он будет распознан как шаблон последовательности в виде scene _ ###.ass. Если вы хотите отменить автоматическое распознавание последовательности, можно вручную изменить строку пути и удалить шаблон заполнения с соответствующим именем файла.

Для процедур, переключатель для включения или отключения абсолютных / относительных путей (абсолютные по умолчанию) можно найти на вкладке System, в настройках ядра визуализации, в диалоговом окне Render Settings.

• Use Global Settings – использует настройку Standin Draw в настройках системы визуализации, чтобы определить, как отображать Stand-ins.
• Use Local Settings – использует локальные настройки.
• Bounding Box – отображение stand-ins в качестве bounding box.
• Disable Draw – отключает отображение дублера.

Viewport Draw Mode – позволяет задать режим отображения данных процедур в stand-ins. Поддерживаются режимы: bounding box, per object bounding box, polywire, wireframe, point cloud, shaded polywire, shaded.

Use File Sequence – когда включено, данный атрибут распознает требуемый формат последовательности кадров и автоматически открывает ее.

Frame – читаемый кадр, который заменит кадр, который определен атрибутом Use Frame Extension. Вам нужно поместить Maya Expression (‘frameNumber = frame’), чтобы получить последовательность stand-ins, которая будет загружена в разные кадры секвенции.

Frame Offset – определяет смещение к текущему кадру. Это позволяет использовать одну и ту же последовательность анимации при создании различных процедур.

Override Nodes – узлы внутри процедуры могут быть заменены другими узлами с этим атрибутом. К примеру, это может быть использовано для замены шейдеров в существующем файле stand-ins. Когда параметр включен, узлы в непосредственной родительской области процедуры заменяют узлы с одинаковыми именами внутри процедуры.

Namespace – с помощью этого атрибута процедуры могут объявлять настраиваемое пространство имен. Это пространство можно использовать вместо имени процедуры для ссылки на содержимое через абсолютные или относительные пути. Несколько процедур могут использовать одно и то же пространство имен, используя одно и то же персонализированное имя. Кроме того, они могут объявить пустое имя и будут использовать глобальное пространство имен.

Параметр Force Shader Assignments (необходимый для этого процесса) появляется в пользовательском интерфейсе параметров экспорта только тогда, когда параметр Export Shaders отключен.

• Экспортируйте модель, используя только формы с включенным атрибутом Force Shader Assignment.
• Снова экспортируйте модель, используя только шейдеры.
• Создайте два Stand-ins и загрузите каждый из них.
• Задайте одинаковое имя в строку пространства имен для обоих Stand-ins.

User Options – это атрибут общего назначения, состоящий из строки (string). Это поле может быть установлено для отмены любого параметра основного узла в сцене Arnold. Это позволяет вам получить доступ и установить основные параметры Arnold, которые в настоящее время не отображаются в пользовательском интерфейсе. Свойство можно применить к полигональным моделям, волосам и источникам света.

Ignore Group Nodes – данный атрибут можно использовать для прокси-геометрии, расположенной ниже иерархии групп, которая затем пропускается при визуализации. Поэтому любая геометрия, источники света и т. д., когда вы активируете этот параметр, относящиеся к stand-ins объекты, не будут отображаться при визуализации.

Object Path – путь в Alembic для отображения узла в иерархии.

Arnold Procedural Settings

Auto Instancing – позволяет для каждого stand-in определить использование этой функции. Если этот атрибут включен, многократное использование одного и того же имени файла будет прозрачно преобразовано в экземпляры. Этот обходной путь иногда бывает полезен при переопределении процедурных параметров с помощью операторов.

Вы должны отключить это только для предотвращения автоматического создания экземпляров того же файла Stand-ins. Он включен по умолчанию и предназначен только для технических специалистов и опытных пользователей.

СОВЕТ. Я рекомендую отключать данный атрибут, если вы планируете создавать дубликаты Stand-ins с заранее выполненным настройками образов. Это позволит избежать связей между объектами и содержимым внутри файлов.

Alembic Settings

Экспорт модели в формат Alembic можно выполнить с помощью меню Arnold => Scene Export. Arnold alembic export также экспортирует данные подразделения поверхностей и пользовательские атрибуты, заданные в формате имен Arnold, например:

FPS – задает частоту кадров, определенную в кадрах в секунду.

Layers – добавляет дополнительные файлы, которые можно использовать для переопределения свойств в файле Alembic.

Name Prefix – задает необязательный префикс имени для добавления ко всем созданным узлам процедур.

Make Instance – используйте создание экземпляров для узлов полигональной геометрии, имеющих одинаковую форму. По умолчанию это действие отключено. Если этот атрибут включен, процедура будет пытаться идентифицировать идентичные примитивы (используя хеш-ключи свойств массива Alembic) и создавать соответствующие узлы ginstance. Два примитива считаются эквивалентными, если ключи их соответствующих выборок положения точки совпадают вместе с любыми заданными значениями подразделения. Это работает с несколькими архивами или вызовами процедур.

Use Instance Cache – этот атрибут можно использовать для отключения внутреннего кэша архива, который распределяет данные Alembic между узлами, это помогает при использовании операторов для переопределения содержимого Alembic когда активен атрибут Make Instance.

Pull User Params – если вы хотите передать параметры создаваемым объектами, объявите пользовательские данные с тем же типом, что и параметр с префиксом имени объекта и двоеточием (:). Например, используйте :

. Таким образом, следующие декларации гарантируют, что для каждого созданного объекта атрибуту Step Size будет задано значение 0.1.

pull_user_params on
declare polymesh:step_size constant FLOAT
polymesh:step_size 0.1

Ignore Visibility Attributes – не выполняет размытие движения типа velocity, даже если данный тип размытия движения активен.

Radius Attribute Name – имя атрибута, который ищется для определения радиуса точек и кривых. По умолчанию он пустой, поэтому используются значения ширины, определенные по умолчанию для формата Alembic.

Radius Default – задает радиус по умолчанию для кривых и точек, если не указан иной в атрибутах Alembic.

Radius Scale – масштабирует разрешенный атрибут радиуса.

Velocity Ignore – отключает размытие движения на основе velocity, даже если атрибут velocity задан явно.

Velocity Scale – масштабирует действие атрибута velocity, используемого для моделирования размытия движения.

File Contents

Данный свиток показывает содержимое импортируемого в сцене файла stand-in в редакторе атрибутов и позволяет применять переопределения к выбранным в нем элементам.

С помощью группы инструментов Look выполняется создание, редактирование или удаление вариантов внешнего вида. При создании нового образа автоматически добавляется узел оператора aiLookSwitch, который представляет собой комбинацию операторов switch_operator и merge, который связан с корнем графа процедур. При первоначальном образе текущие операторы перемещаются в первый список входов на узле переключения вариантов. Ярлыки в aiLookSwitch используются для заполнения списка из aiStandIn. Этот модуль может быть установлен / отменен инструментами настройки визуализации для добавления различных видов на слой / проход. Имя / внешний вид / проход будут переведены к номеру индекса для визуализации.

Add Assignment – список параметров, которые можно присвоить объектам внутри него. Его можно использовать для добавления атрибутов и определения параметров объектов, расположенных ниже в узле. Он создает узел Set Parameter для каждого выбора и помещает их в список Operators. Верхний – это первый оператор, а нижний – последний оператор в дереве иерархии.

Local Overrides – назначения, которые находятся связаны с узлом в иерархии.

Inherited Assignments – переопределения, которые влияют на объект ниже или соответствуют выбранному выражению (string expression).

Add Operator – добавляет универсальный оператор в точку в графе. Строка выбора должна ссылаться на узлы внутри файла *.ass, *.usd или *.abc.

Show Graph – отображает автономный граф объекта и всех связанных с ним операторов.

Render Stats
Свиток Render Stats позволяет включать или отключать различные параметры визуализации для выбранного stand-in.

StandIn Overrides

Override Standin Light Linking – если этот атрибут включен, связи узла aiStandin с источниками света применяется ко всем объектам в Stand-in.

Override Standin Shaders – если этот атрибут включен, шейдеры, примененные к узлу aiStandin, переопределяют шейдеры для всех объектов в Stand-in.
Переопределение шейдеров не переопределяет карты смещения. Смещение обрабатывается Arnold отдельно: когда сцена транслируется в Arnold с помощью MtoA, смещение геометрия не является частью шейдера (shader), применяемого к объекту.

Extra Attributes

Есть некоторые дополнительные атрибуты, которые скрыты от пользователя, такие как overridePrimaryVisibility, overrideOpaque и т. д. Они расположены в нижней части дополнительных атрибутов в редакторе атрибутов для Stand-ins. Если вы используете элементы управления StandIn Overrides, MtoA автоматически обновит соответствующие флажки в разделе Extra Attributes. Например, чтобы переопределить основную видимость, необходимо также включить дополнительный атрибут overridePrimaryVisibility.

Arnold Procedural – вы можете использовать прокси-геометрию, чтобы представить stand-ins с помощью транслятора процедур Arnold для геометрии. Эта функция использует информацию об Bounding Box из Maya. Если stand-in ограничен, вы можете отключить отложенную загрузку процедур или использовать параметры пользователя для установки минимального и максимального процедурных значений (например, min -1 -1 -1 max 1 1 1).

Создание нескольких образов с Arnold Operators

Важным преимуществом Arnold Renderer является его модульность. По своей природе Arnold – это своего рода конструктор, состоящий из множества блоков (API), которые могут быть объединены для получения желаемого образа. Arnold Operators также являются API, который взаимодействует с данными о геометрии, хранимой в форматах Arnold, Alembic, USD и MaterialX.

Для начала работы с Arnold Operators, используйте свиток Operators в диалоговом окне Render Settings и свиток File Contents в Arnold Stand-ins.

Пример отображения иерархии сцены в Stand-ins в USD (A, B) и в Arnold .ass форматах (С)

В данном примере я показываю вариант с применением Arnold Operators вместе с Arnold Stand-in. Благодаря тому, что Stand-in читает данные, сохраненные в *.ass, *.usd, *.abc, каждый объект, материал, текстура будут отображены в списке объектов. Также будет отображена иерархия объектов. Это является важным плюсом, так как вы можете заранее проработать структуру объектов и связать операторы с ними в последующем.

Формат USD, как и родной формат сцен Arnold Renderer, предоставляет информацию об объектах, шейдерах, текстурах, камерах и источниках света.

Создание Arnold Look с помощью функции Create New Look в Stand-ins

Для создания нового образа используйте кнопку Create New Look в свитке File Contents. В диалоговом окне New Look введите имя нового образа, или поставьте флажок напротив параметра Duplicate Current Look, если просто желаете скопировать текущий настроенный образ.

Когда создается Arnold Look, в сцену Maya добавляется узел aiLookSwitch, выполняющий переключение образа в Stand-ins. Переключение между образами, выполняется с помощью раскрывающегося списка look.

Благодаря текстовому полю filter… выполняется поиск объекта, материала, источника света по имени. Здесь можно порекомендовать внимательно относится к именованию объектов и продумывать данный процесс заранее. В создании нескольких вариантов объекта, именование объектов и узлов шейдеров является хорошим тоном.

Граф узлов Arnold Operators, связанных с узлом aiLookSwitch и Arnold Stand-in

Для удобства разработки образов на основе Arnold Operators я рекомендую создавать образ без прямой связи со Stand-ins. В диалоговом окне Render Settings, во вкладке Arnold Renderer в свитке Operators создайте или свяжите с атрибутом Target Operator оператор aiMerge, который впоследствии может быть объединен с любым оператором aiLookSwitch.

Диалоговое окно Render Settings и свиток Opertators

Все связанные с aiMerge операторы и введенные в них выражения будут взаимодействовать с геометрией в Stand-ins. По своей сути, во время процесса визуализации, Arnold загружает данные из Stand-ins в ОЗУ, и в режиме реального времени обращается к ним в процессе создания графа операторов.

Это удобно, если вы создаете вначале только геометрию, а варианты образов разрабатываете отдельно, на этапе Look Development, в Stand-ins можно загружать только модель, без проработки материалов, а последующие образы будут загружаться на основе графов MaterialX, что упрощает подготовку к финальной визуализации и выбора соответствующего образа.

Рассмотрим граф, приведенный на пару рисунков выше. Данный граф демонстрирует связи между Arnold Operators для четырех образов. С помощью оператора aiSetParameter выполняется поиск необходимых узлов в сцене и присвоенных им новых атрибутов и свойств.

Узел оператора aiSetParameter. Слева приведен пример с переопределениями атрибутов шейдеров материала, справа приведен пример переопределения атрибутов геометрии

Каждый атрибут может быть определен типом данных (например, float, int, string, rgba и т. д.), именем (например, имя атрибутов в Maya), оператором (равенство, умножение, деление и т. д.), значением и выражением. Для ряда атрибутов, которые определены в интерфейсе Maya, будут автоматически добавлены соответствующие элементы интерфейса (флажок, раскрывающийся список, текстовое поле и т. д.).

Когда граф операторов будет создан, его можно подключить к созданному в Stand-ins оператору aiLookSwitch с созданным ранее образом.

В процессе интерактивной визуализации, вы можете выполнять изменение образов с помощью раскрывающегося списка looks и видеть изменения в Arnold Render View.

Пример визуализации трех вариантов модели в одной сцене с применением Arnold Operators

Экспорт готовых графов выполняется с помощью функции Export looks в узле Arnold Stand-ins. Экспорт может быть выполнен в форматы Arnold (*.ass), MaterialX (*.mtlx) и USD (*.usd). При экспорте в формат MaterialX, вам также будет предоставлена возможность настройки имен свойств объектов, пути к узлам и разделителя, аналогично функционалу диалогового окна Export to MaterialX…

Настройка экспорта созданного образа в формат MaterialX

Выполнив экспорт графа в отдельный файл, при следующем импорте модели в Maya создайте узел aiMaterialX (Рис. 18) и новый Look для Stand-ins и просто загрузите его, выбрав необходимый образ в списке.

Узел aiMaterialX позволяет загрузить и применить к Stand-ins заранее подготовленные образы

Атрибут Mtlx Filename определяет путь и файл с конфигурациями образов. Раскрывающийся список Assign Type позволяет выбрать, какой элемент применять, look или material. При выборе режима material в списке Look будет отображен список всех сохраненных в MaterialX материалов.

Флажки Assign Materials, Assign Properties, Assign Visibilities позволяют выбрать глобально, какие данные необходимо назначить объектам Stand-ins из выбранного в списке образа.

Заключение

Активное внедрение поддержки форматов USD и MaterialX в приложения компьютерной графики предоставило бесшовные возможности передачи данных между различными приложениями и системами визуализации. На данный момент ведется активная разработка множества инструментов, сохраняющих данные в USD и описывающих графы затенения в MaterialX.

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

Первый проект посвящен реализации поддержки формата USD в Maya, второй – реализации USD в Arnold, а третий проект – специальный универсальный шейдер Autodesk Standard Surface. Он доступен в Autodesk 3ds Max и Autodesk Maya при выборе Arnold Renderer в качестве текущего средства визуализации. А его блоки (диффузный цвет, отражения, рельефность, подповерхностное рассеивание и т. д.) реализованы на уровне параметров MaterialX и базовых определений свойств поверхности, реализованных в стандарте. Настройка отражений в Standard Surface будет представлена также в файле MaterialX и интерпретирована другой системой визуализации или тем же Arnold Renderer.

Механизм Arnold Operators предоставляет пользователям один из наиболее гибких инструментов для редактирования сцен в режиме IPR. В отличие от классического редактирования сцены и перезапуска процесса визуализации, с помощью Arnold Operators мы можем создавать множество вариантов и выбирать наиболее подходящий вариант.

Механизм Arnold Operators можно использовать во всех приложениях, поддерживаемых Arnold. Наиболее оптимальным считается процесс с применением MtoA, MAXtoA и HtoA, где механизм операторов реализован полностью.

На официальном форуме Autodesk, создана тема Обсуждение PIXAR USD в Maya, Arnold и 3ds Max, в которой вы можете задать свои вопросы о поддержке форматов USD, MaterialX и их реализации в целевых приложениях. Там же вы можете предложить свои идеи, которые впоследствии могут быть переданы разработчикам компании Autodesk.

Если у вас возникли вопросы, касающиеся Arnold Renderer, поддержки USD и MaterialX в Maya и других приложениях, напишите специалистам компании «ПОИНТ». Вам обязательно помогут. И до скорых новых встреч!

Еще раз про Oracle standby

Представим себе ситуацию, когда наш проект, использующий в качестве СУБД Oracle, неожиданно (или с надеждой ожидаемо) стал критически важным для бизнеса (соответственно, появилась готовность выделять средства на обеспечение надежности системы).
До этого момента мы вполне обходились ежедневным или даже еженедельным бэкапом («горячим» или «холодным» копированием, а может и просто экспортом данных) и нас устраивало время восстановления системы порядка суток (будем считать, что данных у нас на пару терабайт).
И вот оказалось, что на восстановление системы нам отводится не более часа, и никакие данные нам терять нельзя.
Итак, все указывает на то, что нам придется поднимать standby сервер.
В принципе, большая часть из того, о чем говорится в этой статье, описано в «Oracle Data Guard Concepts and Administartion», а также в куче мест на просторах Сети, но, по большей части, это инструкции, содержащие последовательность команд, без особого описания их смысла и, главное, без рекомендаций, что делать, если что-то идет не так.
Я постараюсь описать процесс развертывания физической standby базы максимально подробно с указанием тех грабель на которые когда-либо натыкался.
Указание на случайно не обнаруженные мной проблемы, а также любые уточнения и дополнения всячески приветствуются.

В дальнейшем, когда в тексте будут приводиться примеры команд и запросов, я буду использовать следующие обозначения:
$ — команда вводится в командной строке операционной системы под пользователем oracle.
SQL> — команда вводится в sqlplus. В этой статье везде, где это не определено явно, подразумевается, что sqlplus запущен в административном режиме (sqlplus / as sysdba), а экземпляр базы задан через переменную $ORACLE_SID.
RMAN> — команда вводится в rman. Здесь также, если явно не определено что-то другое, подразумевается, что rman запущен командой rman target /, а экземпляр базы задан через переменную $ORACLE_SID.

Перед тем, как мы начнем, стоит немного сказать о тех принципах организации БД Oracle, которые понадобятся нам для понимания механизма работы резервного копирования и восстановления данных в СУБД Oracle.

Экземпляр БД Oracle содержит следующие виды файлов:
Управляющие файлы (Control files) — содержат служебную информацию о самой базе данных. Без них не могут быть открыты файлы данных и поэтому не может быть открыт доступ к информации базы данных.
Файлы данных (Data files) — содержат информацию базы данных.
Оперативные журналы (Redo logs) — содержат информацию о всех изменениях, произошедших в базе денных. Эта информация может быть использована для восстановления состояния базы при сбоях.

Существуют другие файлы, которые формально не входят в базу данных, но важны для успешной работы БД.
Файл параметров — используется для описания стартовой конфигурации экземпляра.
Файл паролей — позволяет пользователям удаленно подсоединяться к базе данных для выполнения административных задач.
Архивные журналы — содержат историю созданных экземпляром оперативных журнальных файлов (их автономные копии). Эти файлы позволяют восстановить базу данных. Используя их и резервы базы данных, можно восстановить потерянный файл данных.

Главная идея при создании standby экземпляра состоит в том, чтобы с помощью выполнения транзакций, сохраненных в оперативных или архивных журналах основной БД, поддерживать резервную БД в актуальном состоянии (такой механизм для Oracle называется Data Guard).
Отсюда следует первое требование к нашей основной базе — она должна быть запущена в archivelog mode.
Вторым требованием является наличие файла паролей. Это позволит удаленно подключаться к нашей БД в административном режиме.
Третье требование — это режим force logging. Этот режим нужен для принудительной записи транзакций в redo logs даже для операций, выполняемых с опцией NOLOGGING. Отсутствие этого режима может привести к тому, что на standby базе будут повреждены некоторые файлы данных, т.к. при «накатке» архивных журналов из них нельзя будет получить данные о транзакциях, выполненных с опцией NOLOGGING.
Также необходимо отметить, что если вы используете Oracle ниже 11g, то необходимо, чтобы сервера для основной базы и для standby имели одинаковую платформу. Т.е., если ваша основная база работает на Linux-сервере, то standby-сервер не может быть под управлением Windows.

Все примеры в этой статье будут ориентиваны на unix-системы, однако, их отличие от случая Windows-систем, в основном, состоит только в способе написания путей к файлам.
Не забываем также, что обмен данными между основным и standby серверами будет происходить по SQL-Net, поэтому необходимо, чтобы соединения на соответствующий порт (как правило, 1521 tcp) было открыто в обоих направлениях.

Будем считать, что наша база называется test. Мы будем так настраивать конфигурацию основной и standby базы, чтобы в любой момент мы могли поменять их роли местами (switchover). Мы планируем, что наша система будет использовать Data Guard protection mode, который называется MAXIMUM PERFORMANCE.

Итак, поехали.
Для начала поверяем соответствие нашей БД необходимым требованиям.

1. Смотрим, в каком режиме работает наша основная БД:

SQL> select name, open_mode, log_mode from v$database;

NAME OPEN_MODE LOG_MODE
——— ———- ————
TEST READ WRITE ARCHIVELOG

Если вы не видите значения ARCHIVELOG в поле LOG_MODE, выполняем следующие команды:

SQL> shutdown immediate;
SQL> startup mount;
SQL> alter database archivelog;
SQL> alter database open;

2. Проверяем наличие файла паролей:

SQL> select * from v$pwfile_users;

Если вы не видите этот результат, создаем необходимый файл:

$ orapwd file=$ORACLE_HOME/dbs/orapw$ORACLE_SID password=xxxxxxxx force=y

Вместо ‘xxxxxxxx’ необходимо вставить текущий пароль пользователя SYS.

3. Включаем режим force logging:

SQL> alter database force logging;

Переходим к конфигурированию нашей системы. Для начала выполним необходимые настройки на основной базе. Будем сохранять все данные в каталоге /data/backup.

Создаем standby redo logs. Они нужны только на standby базе для записи данных, сохраняемых в redo logs на основной базе. На основной базе они нам понадобятся, когда мы будем переключать ее в режим standby и при этом использовать real-time apply redo. Файлы standby redo logs должны быть такого же размера как и online redo logs. Посмотреть размер online redo logs можно с помощью команды:

SQL> select bytes from v$log;

BYTES
———-
52428800
52428800
52428800

Смотрим, какие группы для redo logs есть в нашей базе:

SQL> select group# from v$logfile;

Создаем standby redo logs:

SQL> alter database add standby logfile group 4 ‘/oradata/test/stnbylog01.log’ size 50m;
Database altered.

SQL> alter database add standby logfile group 5 ‘/oradata/test/stnbylog02.log’ size 50m;
Database altered.

SQL> alter database add standby logfile group 6 ‘/oradata/test/stnbylog03.log’ size 50m;
Database altered.

Создаем файл с параметрами нашего экземпляра (pfile). Мы будем учитывать, что наша основная база может быть переключена в режим standby, а это требует задания параметров, которые будут использоваться только в standby режиме.

SQL> create pfile=’/data/backup/pfilePROD.ora’ from spfile;

Нам необходимо добавить некоторые параметры в получившийся файл, если их там нет:

db_name=’test’ — это имя нашей базы (одинаковое для основного и standby экземпляра).
db_unique_name=’testprod’ — а это уникальное имя для каждого экземпляра, оно не будет изменяться при смене ролей со standby на production.
log_archive_config=’dg_config=(testprod,teststan)’ — определяем имена экземпляров, между которыми будет происходить обмен журналами.
log_archive_dest_1=’SERVICE=teststan LGWR ASYNC VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) db_unique_name=’teststan’ – когда экземпляр является основной базой (PRIMARY_ROLE), мы будем передавать архивные журналы на standby сервер с помощью процесса LGWR. Параметр ASYNC указывает, что данные, сгенерированные транзакцией, не обязательно должны быть получены на standby до завершения транзакции – это не приведет к остановке основной базы, если нет связи со standby.
log_archive_dest_2=’LOCATION=/oradata/test/archive VALID_FOR=(ALL_LOGFILES,ALL_ROLES) db_unique_name=testprod’ – здесь мы указываем каталог, куда будут локально сохранятся архивные журналы (для основной базы) или куда будут складываться пришедшие с основной базы журналы (для standby базы).
log_archive_dest_state_1=ENABLE – включаем запись архивных журналов в log_archive_dest_1. Пока мы не создали standby базу, этот параметр можно поставить в значение DEFER, если мы не хотим видеть лишние сообщения о недоступности standby базы в alert_log.
log_archive_dest_state_2=ENABLE – включаем запись архивных журналов в log_archive_dest_2.
fal_client=’testprod’ – этот параметр определяет, что когда экземпляр перейдет в режим standby, он будет являться клиентом для приема архивных журналов (fetch archive log).
fal_server=’teststan’ – определяет FAL (fetch archive log) сервер, с которого будет осуществляться передача архивных журналов. Параметры fal_client и fal_server работают только когда база запущена в standby режиме.
standby_file_management=’AUTO’ – задаем режим автоматического управления файлами в standby режиме. При таком значении параметра все создаваемые или удаляемые файлы основной базы будут автоматически создаваться или удаляться и на standby базе.

Если мы все-таки хотим разместить нашу standby базу в каталогах, отличных от тех, в которых размещена основная база, нам понадобятся дополнительные параметры:

db_file_name_convert=’/oradata_new/test’,’/oradata/test’ – этот параметр указывает, что в именах файлов данных, которые будут создаваться в standby базе (т.е. когда наш основной экземпляр начнет работать в режиме standby), необходимо изменить пути с ‘/oradata_new/test’ на ‘/oradata/test’.
log_file_name_convert=’/oradata_new/test/archive’,’/oradata/test/archive’ – этот параметр указывает, что в именах журнальных файлов, которые будут создаваться в standby базе, необходимо изменить пути с ‘/oradata_new/test/archive’ на ‘/oradata/test/archive’.

В итоге файл параметров для основной базы помимо всего прочего должен иметь следующие записи:

# эти параметры нам понадобятся для работы в режимах PRIMARY и STANDBY
db_name=’test’
db_unique_name=’testprod’
log_archive_config=’dg_config=(testprod,teststan)’
log_archive_dest_1=’SERVICE=teststan LGWR ASYNC VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) db_unique_name=’teststan’ log_archive_dest_2=’LOCATION=/oradata/test/archive VALID_FOR=(ALL_LOGFILES,ALL_ROLES) db_unique_name=testprod’
log_archive_dest_state_1=ENABLE
log_archive_dest_state_2=ENABLE
# эти параметры нам понадобятся для работы только в режиме STANDBY
fal_client=’testprod’
fal_server=’teststan’
standby_file_management=’AUTO’

Если есть такая возможность, перезапускаем основную базу с новыми параметрами и создаем новый spfile на основе переработанного нами pfile:

SQL> shutdown immediate;
SQL> startup nomount pfile=’/data/backup/pfilePROD.ora’;
SQL> create spfile from pfile=’/data/backup/pfilePROD.ora’;
SQL> shutdown immediate;
SQL> startup;

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

Задаем необходимые параметры:

SQL> alter system set log_archive_config=’dg_config=(test,teststan)’;
System altered.

Задаем места для записи архивных журналов. На работающей базе мы не сможем поправить параметр log_archive_dest_1, если он задан. Поэтому только добавляем направление копирования в standby базу:

SQL> alter system set log_archive_dest_2=’SERVICE=teststan LGWR ASYNC VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) db_unique_name=teststan’;
System altered.

SQL> alter system set log_archive_dest_state_2=ENABLE;
System altered.

SQL> alter system set FAL_SERVER=teststan;
System altered.

SQL> alter system set FAL_CLIENT=test;
System altered.

SQL> alter system set standby_file_management=’AUTO’;
System altered.

Добавляем в tnsnames.ora запись о standby базе:

TESTSTAN =
(DESCRIPTION =
(ADDRESS_LIST =
(ADDRESS = (PROTOCOL = TCP)(HOST = standbysrv)(PORT = 1521))
)
(CONNECT_DATA =
(SERVICE_NAME = teststan)
)
)

Пришло время создать backup-ы (если их нет). Для этого мы будем пользоваться утилитой rman.
Необходимо, чтобы место, где располагается бэкап, из которого мы будем разворачивать standby базу, было точно таким же, как и место, куда мы этот бэкап сохраняли. Т.е. если мы складываем бэкап в каталог ‘/data/backup’, то при восстановлении базы на standby-сервере rman будет искать данные бэкапа в таком же каталоге. Для решения этой задачи есть два очевидный пути: скопировать данные бэкапа с основного сервера на standby в точно такой же каталог, созданный там, или использовать для бэкапа сетевой ресурс, который одинаково монтируется на обоих серверах.

Запускаем rman на основном сервере:
$ rman target /

Интересный момент для случая, когда Oracle установлен на Linux. Если у вас установлен пакет PolyglotMan (RosettaMan), то при попытке выполнить
$ rman target /
может возникнуть ошибка:
rman: can’t open target
Эта ситуация возникает в случае, если путь до исполняемого файла rman этого пакета — (например, /usr/X11R6/bin/rman) в переменной окружения $PATH располагается раньше, чем путь до ораклового rman. Т.е. мы пытаемся запустить rman из пакета PolyglotMan и передать ему в качестве параметра файл target, который он, естественно, не может открыть.

Создаем контрольный файл для standby базы:

RMAN> backup current controlfile for standby format ‘/data/backup/standbycontrol.ctl’;

Создаем бэкап нашей основной базы и архивных журналов:

RMAN> run
2> <
3> allocate channel c1 device type disk format ‘/data/backup/%u’;
4> backup database plus archivelog;
5> >

Здесь нас может поджидать неприятность, если по каким-то причинам у нас нет полного набора архивных журналов (например, они были удалены). Тогда rman выдаст ошибку:

RMAN-20242: Specification does not match any archivelog in the recovery catalog

Для исправления ситуации необходимо проверить и изменить статусы архивных журналов в репозитории rman. Для этого выполним следующую команду:

RMAN> change archivelog all crosscheck;

Если бэкап прошел успешно, копируем содержимое каталога /data/backup/ на standby сервер (если мы не использовали общий сетевой ресурс для бэкапа) и приступаем к созданию экземпляра на standby сервере.

Для начала нам необходимо установить Oracle на standby-сервере без создания экземпляра БД. Для облегчения дальнейшей жизни пути к $ORACLE_HOME на standby-сервере должны быть такими же, как и на основном. Также устанавливаем все патчи, которые были установлены на основном сервере, для полного соответствия версий Oracle.
Создаем конфигурацию listener-а и net service names.
Так как для разворачивания копии основной базы на standby сервере мы будем использовать rman, запущенный на боевом сервере, а при этом standby экземпляр базы у нас будет находится в nomount режиме, то нам необходимо явно прописать сервис в listener.ora, иначе все попытки подключиться из rman к будущему standby как к auxiliary будут блокироваться.
В итоге listener.ora должен выглядеть приблизительно так:

SID_LIST_LISTENER =
(SID_LIST =
(SID_DESC =
(SID_NAME = PLSExtProc)
(ORACLE_HOME = /oracle)
(PROGRAM = extproc)
)
(SID_DESC =
(GLOBAL_DBNAME = teststan)
(ORACLE_HOME = /oracle)
(SID_NAME = test)
)
)

LISTENER =
(DESCRIPTION_LIST =
(DESCRIPTION =
(ADDRESS = (PROTOCOL = TCP)(HOST = standbysrv)(PORT = 1521))
(ADDRESS = (PROTOCOL = IPC)(KEY = EXTPROC0))
)
)

Следует заметить, что параметр SID_NAME в данном случае чувствителен к регистру, т.к. listener будет искать файл паролей с именем orapw$SID_NAME.

Кстати, сейчас самое время скопировать файл паролей ($ORACLE_HOME/dbs/orapw$ORACLE_SID) с основного сервера на standby.

Нам также следует прописать нашу основную и standby базы в tnsnames.ora:

TEST =
(DESCRIPTION =
(ADDRESS_LIST =
(ADDRESS = (PROTOCOL = TCP)(HOST = standbysrv)(PORT = 1521))
)
(CONNECT_DATA =
(SERVICE_NAME = teststan)
)
)

TESTPROD =
(DESCRIPTION =
(ADDRESS_LIST =
(ADDRESS = (PROTOCOL = TCP)(HOST = productionsrv)(PORT = 1521))
)
(CONNECT_DATA =
(SID = test)
)
)

Т.к. подразумевается, что приложения «знают» нашу базу под именем test, то и для standby базы мы задаем SID test.

Не забываем перестартовать listener:

$ORACLE_HOME/bin/lsnrctl stop
$ORACLE_HOME/bin/lsnrctl start

Теперь создаем структуру каталогов для нашей базы. Тут важно не забыть, что нужно создать все каталоги для хранения файлов данных и журналов, а также каталоги adump, bdump, cdump, dpdump, udump, располагающиеся обычно в $ORACLE_HOME/admin/$ORACLE_SID.
Если вы не хотите сохранять на standby структуру каталогов основной базы, то необходимо создать каталоги в соответствии со значениями параметров db_file_name_convert и log_file_name_convert.

Также нам необходимо создать на основе файлов параметров основной базы файл параметров для standby. Для этого перепишем на standby сервер файл pfilePROD.ora, переименовав его в pfileSTAN.ora, и внесем необходимые исправления в ту его часть, которую мы редактировали ранее:

# эти параметры нам понадобятся для работы в режимах PRIMARY и STANDBY
db_name=’test’
db_unique_name=’teststan’
log_archive_config=’dg_config=(testprod,teststan)’
log_archive_dest_1=’SERVICE=testprod LGWR ASYNC VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) db_unique_name=’testprod’ log_archive_dest_2=’LOCATION=/oradata/test/archive VALID_FOR=(ALL_LOGFILES,ALL_ROLES) db_unique_name=teststan’
log_archive_dest_state_1=ENABLE
log_archive_dest_state_2=ENABLE
# эти параметры нам понадобятся для работы только в режиме STANDBY
fal_client=’teststan’
fal_server=’testprod’
standby_file_management=’AUTO’

При размещении standby базы в других каталогах также добавляем необходимые параметры:

Пришло время стартовать standby экземпляр базы:

SQL> startup nomount pfile=’/data/backup/pfileSTAN.ora’;
SQL> create spfile from pfile=’/data/backup/pfileSTAN.ora’;
SQL> shutdown immediate;
SQL> startup nomount;

Разворачиваем standby базу из бэкапа. Для этого переходим на основной сервер и запускаем rman.

Подключаемся к будущей standby базе и выполняем дуплицирование (мы помним, что бэкап данных и контрольный файл у нас лежат в каталоге, который и с основного сервера и со standby виден как /data/backup):

RMAN> connect auxiliary sys@teststan
RMAN> duplicate target database for standby nofilenamecheck dorecover;

Параметр nofilenamecheck нам нужен, чтобы rman не ругался на повторяющиеся имена файлов (если мы используем одинаковую структуру каталогов на основном и standby серверах).

Если все прошло успешно, то переводим систему в режим автоматического применения транзакций на standby базе.

Переключаем журнальный файл и смотрим последний номер архивного журнала на основной базе:

SQL> alter system switch logfile;
System altered.

SQL> select max(sequence#) from v$archived_log;

Теперь переходим на standby сервер.

Проверяем состояние базы:

SQL> select name,open_mode,log_mode from v$database;

NAME OPEN_MODE LOG_MODE
——— ———- ————
TEST MOUNTED ARCHIVELOG
SQL> select recovery_mode from v$archive_dest_status;

11 rows selected.

SQL> select max(sequence#) from v$log_history;

Мы видим, что последний примененный лог на standby отстает от основной базы, а также, что процессы ARCH не работают.

Проверяем наличие standby redo logs:

SQL> select * from v$standby_log;

Если их нет – создаем:

SQL> alter database add standby logfile group 4 ‘/oradata/test/stnbylog01.log’ size 50m;
Database altered.

SQL> alter database add standby logfile group 5 ‘/oradata/test/stnbylog02.log’ size 50m;
Database altered.

SQL> alter database add standby logfile group 6 ‘/oradata/test/stnbylog03.log’ size 50m;
Database altered.

Переводим нашу standby базу в режим Real-time apply redo:

SQL> alter database recover managed standby database using current logfile disconnect;

Смотрим, что получилось:

SQL> select recovery_mode from v$archive_dest_status;

RECOVERY_MODE
————————
MANAGED REAL TIME APPLY
MANAGED REAL TIME APPLY
MANAGED REAL TIME APPLY
MANAGED REAL TIME APPLY
MANAGED REAL TIME APPLY
MANAGED REAL TIME APPLY
MANAGED REAL TIME APPLY
MANAGED REAL TIME APPLY
MANAGED REAL TIME APPLY
MANAGED REAL TIME APPLY
MANAGED REAL TIME APPLY

11 rows selected.

SQL> select max(sequence#) from v$log_history;

Как видим, все работает.

Если мы не хотим использовать режим Real-time apply redo, а хотим дожидаться когда будет закончено формирование очередного архивного журнала на основном сервере и он будет передан на standby для применения сохраненных в нем транзакций, то нам необходимо переводить нашу standby базу в режим redo apply командой:

SQL> alter database recover managed standby database disconnect;

Если что-то пошло не так, то для решения проблемы в первую очередь необходимо остановить «накатку» логов:

SQL> alter database recover managed standby database cancel;

Возможно, что в процессе дуплицирования на standby сервер были переданы не все архивные журналы. Тогда их надо вручную скопировать на standby сервер (в нашем случае в каталог /oradata/test/archive), произвести ручную «накатку»:

SQL> recover standby database;

и после этого опять запустить режим Real-time apply redo:

SQL> alter database recover managed standby database using current logfile disconnect;

Процессы переключения ролей между экземплярами (switchover) и перевода standby базы в режим primary в случае падения основной базы (failover) имеют множество своих подводных камней, поэтому это тема отдельной статьи.

stand-in processing

stand-alone processing — autonominis apdorojimas statusas T sritis automatika atitikmenys: angl. off line processing; stand alone processing vok. selbstständige Verarbeitung, f; Verarbeitung getrennt von übrigen System, f rus. автономная обработка, f pranc. traitement… … Automatikos terminų žodynas

off-line processing — autonominis apdorojimas statusas T sritis automatika atitikmenys: angl. off line processing; stand alone processing vok. selbstständige Verarbeitung, f; Verarbeitung getrennt von übrigen System, f rus. автономная обработка, f pranc. traitement… … Automatikos terminų žodynas

Photographic processing — is the chemical means by which photographic film and paper is treated after photographic exposure to produce a negative or positive image. Photographic processing transforms the latent image into a visible image, makes this permanent and renders… … Wikipedia

Transaction processing system — A Transaction Processing System To be considered a transaction processing system the computer must pass the ACID test.From a technical perspective, a Transaction Processing System (or Transaction Processing Monitor) monitors transaction programs … Wikipedia

information processing — Acquisition, recording, organization, retrieval, display, and dissemination of information. Today the term usually refers to computer based operations. Information processing consists of locating and capturing information, using software to… … Universalium

Graphics processing unit — GPU redirects here. For other uses, see GPU (disambiguation). GeForce 6600GT (NV43) GPU A graphics processing unit or GPU (also occasionally called visual processing unit or VPU) is a specialized circuit designed to rapidly manipulate and alter… … Wikipedia

cereal processing — Introduction treatment of cereals (cereal) and other plants to prepare their starch for human food, animal feed, or industrial use. Nutrient composition of selected raw cereal grains (per 100 grams)Cereals, or grains, are members of… … Universalium

Video post-processing — The term post processing (or postproc for short) is used in the video/film business for quality improvement image processing (specifically digital image processing) methods used in video playback devices, (such as stand alone DVD Video players),… … Wikipedia

Automatic data processing — In telecommunication, the term automatic data processing (ADP) has the following meanings: 1. An interacting assembly of procedures, processes, methods, personnel, and equipment to perform automatically a series of data processing operations on… … Wikipedia

Integrated Microcomputer Processing System — IMPS, short for Integrated Microcomputer Processing System is a public domain statistical package developed by the U.S. Census Bureau. The Integrated Microcomputer Processing System (IMPS) performs the major tasks in survey and census data… … Wikipedia

Pyramid (image processing) — Pyramid or pyramid representation is a type of multi scale signal representation developed by the computer vision, image processing and signal processing communities, in which a signal or an image is subject to repeated smoothing and subsampling … Wikipedia

Standin в Dota 2

Если вы увлекаетесь просмотрами профессиональных матчей, то могли увидеть у игроков в никах следующее слово «Standin» за которым после идет его имя, например Standin.SingSing. Многие спрашивают кто такой стендин в доте?

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

Так вот, Standin — это «Замена», что обозначает временную замену основного игрока в команде, само выражение «standing in for a team».

В больших турнирах разрешают использовать в одном матче до 2х стендинов, но бывают исключения, что состав может состоять и из трех стендингов, такое было у The Alliance на DreamLeague 2014.