Кто что блокирует, ms sql + 1c

Копирование числовых ячеек из 1С в Excel Промо

Решение проблемы, когда значения скопированных ячеек из табличных документов 1С в Excel воспринимаются последним как текст, т.е. без дополнительного форматирования значений невозможно применить арифметические операции. Поводом для публикации послужило понимание того, что целое предприятие с более сотней активных пользователей уже на протяжении года мучилось с такой, казалось бы на первый взгляд, тривиальной проблемой. Варианты решения, предложенные специалистами helpdesk, обслуживающими данное предприятие, а так же многочисленные обсуждения на форумах, только подтвердили убеждение в необходимости описания способа, который позволил мне качественно и быстро справиться с ситуацией.

Состояния ограничений целостности

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

При загрузке больших объемов данных с использованием SQL*Loader или утилиты Import может потребоваться значительное время на загрузку данных, каждую строку которых нужно проверять на предмет нарушения целостности. Более эффективная стратегия предусматривает отключение ограничения, загрузку данных и последующую проверку корректности загруженных данных. После завершения загрузки ограничения вновь вводятся в действие посредством включения. Когда ограничение отключается,как описано здесь, база данных уничтожает индекс. Подобным образом реализуется лучшая стратегия — предварительное создание неуникальных индексов для ограничений, которые база данных не должна уничтожать, поскольку они обрабатывают дублированные записи.

На заметку! Состояние enabled (включено) — это состояние ограничений Oracle по умолчанию

Отключаются ограничения двумя способами: указание в качестве состояния ограничения либо disable validate (отключить с проверкой), либо disable no validate (отключить без проверки) с использованием конструкции DISABLE VALIDATE и DISABLE NO VALIDATE, соответственно. Аналогично, для включения ограничения применяются конструкции ENABLE VALIDATE и ENABLE NO VALIDATE. Ниже кратко обсуждаются различные способы включения и отключения ограничений.

Состояние Disable Validate

В случае использования команды DISABLE VALIDATE выполняются следующие два действия сразу. Во-первых, конструкция VALIDATE гарантирует, что все данные в таблице удовлетворяют условию ограничения. Во-вторых, конструкция DISABLE избавляет от необходимости поддерживать ограничение. Oracle сбрасывает индекс ограничения,но сохраняет его действительным. Вот пример: 

SQL> ALTER TABLE sales_data
ADD CONSTRAINT quantity_unique
UNIQUE (prod_id,customer_id) DISABLE VALIDATE;

После выдачи приведенного выше оператора SQL наличие только уникальных комбинаций уникальных ключей prod_id и customer_id в таблице гарантируется, однако уникальный индекс не поддерживается.

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

Состояние Disable No Validate

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

Индексы на основе функций

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

Ниже показано, как создать индекс на основе функции LOWER

Этот оператор CREATE INDEX создаст индекс по столбцу l_name, хранящему фамилии сотрудников в верхнем регистре. Однако этот индекс будет основан на функции, поскольку база данных создаст его по столбцу l_name, применив к нему предварительно функцию LOWER для преобразования его значения в нижний регистр.

Правило одинакового источника (Same-Origin Policy)

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

Ресурс считается принадлежащим к другому источнику (cross-origin), если он располагается на другом домене/поддомене, протоколе или порте.

Это, конечно, здорово, но для чего правило одинакового источника вообще существует?

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

Разработчики этого мошеннического сайта сделали так, чтобы он имел доступ к фрейму и мог взаимодействовать с DOM сайта вашего банка — так они смогут переводить деньги на свой счёт от вашего имени.

Да, это огромная угроза безопасности — мы ведь не хотим, чтобы кто угодно имел доступ к чему угодно.

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

В данном случае сайт попытался получить доступ к ресурсам из другого источника —. Правило одинакового источника заблокировало это действие. В результате разработчики мошеннического сайта не смогли добраться до нашей банковской информации.

Но какое отношение всё это имеет к CORS?

Как с помощью PowerShell найти компьютер на котором была заблокирована учётная запись

Вы можете использовать следующий скрипт PowerShell, чтобы найти источник блокировки учётной записи конкретного пользователя в журналах событий PDC. Этот скрипт возвращает время блокировки и имя компьютера, с которого она произошла (замените Alex на имя интересующего вас пользователя):

$Usr = 'Alex'
$Pdc = (Get-AdDomain).PDCEmulator
$ParamsEvn = @{
	'Computername' = $Pdc
	'LogName' = 'Security'
	'FilterXPath' = "* and EventData='$Usr']]"
}
$Evnts = Get-WinEvent @ParamsEvn 
$Evnts | ForEach-Object {$_.Properties.value + ' ' + $_.TimeCreated + ', UserName: ' + $Usr}

Пример полученных данных:

HACKWARE-WIN 09/29/2021 07:31:59
HACKWARE-WIN 09/29/2021 06:53:12
HACKWARE-WIN 09/29/2021 05:44:18

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

$Usr = 'Alex'
$Date = (Get-Date).AddDays(-2)
$Evnts = Get-WinEvent -FilterHashtable @{ LogName='Security'; StartTime=$Date; Id='4740'; Data="$Usr";  }
$Evnts | ForEach-Object {$_.Properties.value + ' ' + $_.TimeCreated + ', UserName: ' + $_.Properties.value}

Точно так же вы можете опросить все контроллеры домена в Active Directory из PowerShell:

$Usr = 'MiAl'
Get-ADDomainController -Filter * | Select-Object -exp hostname | % {
	$ParamsEvn = @{
		'Computername' = $Pdc
		'LogName' = 'Security'
		'FilterXPath' = "* and EventData='$Usr']]"
	}
	$Evnts = Get-WinEvent @ParamsEvn
	$Evnts | ForEach-Object {$_.MachineName + " " + $_.Properties.value + ' ' + $_.TimeCreated + ', UserName: ' + $_.Properties.value}
}

Анализ полученного результата

Во-первых, интерпретируем результат запроса к представлению dm_tran_locks независимо от dm_exec_requests:

Как видно, сессия с идентификатором «65» установила (GRANT) на единственный индекс таблицы «_InfoRg243» следующие блокировки: IX на уровне страницы индекса и X на уровне ключа индекса. Как можно догадаться, это тот сеанс, который производит запись в регистр из 1С:Предприятие. Сессия с номером «55» установила (GRANT) блокировку IS на уровне страницы единственного индекса таблицы «_InfoRg243», а S блокировку на уровне ключа записи установить не удалось и поэтому она находится в ожидание (WAIT) до момента освобождения ресурса (или таймаута).

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

При таком подходе (сначала dm_exec_requests, затем dm_tran_locks) получим следующую интерпретацию:

Представление	Интерпретация результата
dm_exec_requests	Сеансом с идентификатором «55» (жертва) был отправлен запрос «Select * from dbo._InfoRg243», который встал на ожидании получения S блокировки по ресурсу «KEY: 9:72057594051559424 (227b7397de24)». Блокирующим является сеанс с идентификатором «65» (источник)
dm_tran_locks	Запрашиваемая блокировка сеанса «55» по ресурсу «227b7397de24»: S блокировка по ключу индекса «_InfoRg243_ByDims_N» таблицы «_InfoRg243». Как видно, причина по которой жертве не удается установить блокировку заключается в том что источник уже установил исключительную блокировку на данный ресурс. Установленная источником блокировка (X) несовместима с блокировкой жертвы (S)

(B*tree)

В реализации индексов на основе B-деревьев используется концепция сбалансированного (на что указывает буква ‘B’ (balanced)) дерева поиска в качестве основы структуры индекса. В Oracle имеется собственный вариант B-дерева. Это обычные индексы, создаваемые по умолчанию, когда вы применяете оператора CREATE INDEX.

Индексы на основе B-деревьев структурированы в форме обратного дерева, где блоки верхнего уровня называются блоками ветвей (branch blocks), а блоки нижнего уровня – листовыми блоками (leaf blocks). В иерархии узлов все узлы кроме вершины, или корневого узла, имеют родительский узел и могут иметь ноль или более дочерних узлов. Если глубина древовидной структуры , т.е. количество уровней, одинакова от каждого листового блока до корневого узла, то такое дерево называется сбалансированным, или B-деревом.

B-деревья автоматически поддерживают необходимый уровень индекса по размеру таблицы. B-деревья также гарантируют, что индексные блоки всегда будут заполнены не меньше, чем наполовину, и менее, чем на 100%. B-деревья допускают операции выборки, вставки и удаления с очень небольшим количеством операций ввода-вывода на один оператор. Большинство B-деревьев имеет всего три и менее уровней. При использовании B-дерева нужно читать только блоки B-дерева, так что количество операций ввода-вывода будет ограничено числом уровней B-дерева (скажем, тремя) плюс две операции ввода-вывода на выполнение обновления или удаления (одна для чтения и одна для записи). Для выполнения поиска по B-дереву понадоисят всего три или менее обращений к диску.

Реализация B-дерева от Oracle – всегда сохраняет дерево сбалансированным. Листовые блоки содержат по два элемента: индексированные значения столбца и соответствующий идентификатор ROWID для строки, которая содержит это значение столбца. ROWID – уникальный указатель Oracle, идентифицирующий физическое местоположение строки и обеспечивающий самый быстрый способ доступа к строке в базе данных Oracle. Сканирование индекса быстро дает ROWID строки, и отсюда можно быстро получить к ней доступ непосредственно. Если запрос нуждается лишь в значении индексированного столбца, то конечно, последний шаг исключается, поскольку извлекать дополнительные данные, кроме прочитанных из индекса, не потребуется.

Использование SELECT и предикатов IN, OR, BETWEEN, LIKE

Предикаты — слова IN, OR, BETWEEN, LIKE в секции WHERE — также позволяют выбрать определённые диапазоны значений (IN, OR, BETWEEN) или
значения в строках (LIKE), которые требуется выбрать из таблицы. Запросы с предикатами IN, OR, BETWEEN имеют
следующий синтаксис:

SELECT ИМЯ_СТОЛБЦА FROM ИМЯ_ТАБЛИЦЫ
WHERE ЗНАЧЕНИЕ
ПРЕДИКАТ (IN, OR, BETWEEN) (ЗНАЧЕНИЯ, УКАЗЫВАЮЩИЕ ДИАПАЗОН)

Запросы с предикатом LIKE имеют следующий синтаксис:

SELECT ИМЯ_СТОЛБЦА FROM ИМЯ_ТАБЛИЦЫ
WHERE ИМЯ_СТОЛБЦА LIKE
ВЫРАЖЕНИЕ

Пример 7. Пусть требуется выбрать из таблицы Staff имена, должности
и число отработанных лет сотрудников, работающих в отделах с номерами 20 или 84.
Это можно сделать следующим запросом (на MS SQL Server — с предваряющей конструкцией USE company1;):

SELECT Name, Job, Years
FROM Staff
WHERE Dept IN (20, 84)

Результат выполнения запроса:

На сайте есть подробный урок об использовании предиката IN.

Пример 8. Пусть теперь требуется выбрать из таблицы Staff те же данные,
что и в предыдущем примере. Запрос со словом OR аналогичен запросу со словом IN и перечислением интересующих
значений в скобках. Запрос будет следующим (на MS SQL Server — с предваряющей конструкцией USE company1;):

SELECT Name, Job, Years
FROM Staff
WHERE Dept=20 OR Dept=84

Пример 9. Выберем из той же таблицы имена, должности
и число отработанных лет сотрудников, зарплата которых между 15000 и 17000 включительно (на MS SQL Server — с предваряющей конструкцией USE company1;):

SELECT Name, Job, Years
FROM Staff
WHERE Salary BETWEEN 15000 AND 17000

Результат выполнения запроса:

На сайте есть подробный урок об использовании предиката BETWEEN.

Предикат LIKE используется для выборки тех строк, в значениях которых встречаются символы, указанные
после предиката между апострофами (‘).

Пример 10. Выберем из той же таблицы имена, должности
и число отработанных лет сотрудников, имена которых начинаются с буквы S и состоят из 7 символов
(на MS SQL Server — с предваряющей конструкцией USE company1;):

SELECT Name, Job, Years
FROM Staff
WHERE Name LIKE ‘S_ _ _ _ _ _’

Символ подчёркивания (_) означает любой символ. Результат выполнения запроса:

Пример 11. Выберем из той же таблицы имена, должности
и число отработанных лет сотрудников, имена которых начинаются с буквы S и содержат любые другие буквы
в любом количестве (на MS SQL Server — с предваряющей конструкцией USE company1;):

SELECT Name, Job, Years
FROM Staff
WHERE Name LIKE ‘S%’

Символ процентов (%) означает любое количество символов. Результат выполнения запроса:

На сайте есть подробный урок об использовании предиката LIKE.

Значения, указанные с использованием предикатов IN, OR, BETWEEN, LIKE можно инвертировать при помощи
слова NOT. Тогда запрашиваемые данные будут иметь противоположный смысл. Если мы используем NOT IN (20, 84),
то будут выведены данные сотрудников, которые работают во всех отделах, кроме имеющих номера 20 и 84.
С использованием NOT BETWEEN 15000 AND 17000 можно получить данные сотрудников, зарплата которых не
входит в интервал от 15000 до 17000. Запрос с NOT LIKE выведет данные сотрудников, чьи имена не начинаются
или не содержат символов, указанных с NOT LIKE.

Предложение WHERE

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

Типы условий выбора:

• Сравнение значений атрибутов со скалярными выражениями, другими атрибутами или результатами вычисления выражений.
• Проверка значения на принадлежность множеству.
• Проверка значения на принадлежность диапазону.
• Проверка строкового значения на соответствие шаблону.
• Проверка на наличие null-значения.

Сравнение

В языке SQL используются традиционные операции сравнения ,,,,,.

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

Пример 5.Определить номера деталей, поставляемых поставщиком с номером 2.

Пример 6.Получить информацию о поставщиках Иванов и Петров.

Строковые значения атрибутов заключаются в апострофы.

Проверка на принадлежность множеству

Операция проверяет, принадлежит ли значение атрибута заданному множеству.

Пример 7.Получить информацию о поставщиках ‘Иванов’ и ‘Петров’.

Пример 8.Получить информацию о деталях с номерами 1 и 2.

Проверка на принадлежность диапазону

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

Пример 9.Определить номера деталей, с ценой от 10 до 20 рублей.

Пример 10.Вывести наименования поставщиков, начинающихся с букв от ‘К’ по ‘П’.

Сравнение символов

Буква ‘Р’ в условии запроса объясняется тем, что строки сравниваются посимвольно. Для каждого символа при этом определяется код. Для нашего случая справедливо условие: ‘П’<‘Петров’<‘Р’

Проверка строкового значения на соответствие шаблону

Операция используется для поиска подстрок. Значения столбца, указываемого перед служебным словом сравниваются с задаваемым после него шаблоном. Форматы шаблонов различаются в конкретных СУБД.

Для СУБД MS SQL Server:

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

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

Пример 11.Вывести фамилии поставщиков, начинающихся с буквы ‘И’.

Пример 12.Вывести фамилии поставщиков, начинающихся с букв от ‘К’ по ‘П’.

Проверка на наличие null-значения

Операции и используются для сравнения значения атрибута со значением .

Пример 13.Определить наименования деталей, для которых не указана цена.

Пример 14.Определить номера поставщиков, для которых указано наименование.

Агрегатные функции HQL

В таблице представлены агрегатные функции, поддерживаемые HQL :

Функция	Описание
avg (property name)	получение среднего значения
count (property name or *)	получение количества записей
max (property name)	получение максимального значения
min (property name)	получение минимального значения
sum (property name)	вычисление суммарного значения

Использование оператора DISTINCT позволяет выделить уникальные значения. Следующий запрос вернет количество уникальных
имен сотрудников :

String hql = "SELECT COUNT (distinct e.firstName) "
              + "FROM Employee e";
Query query = session.createQuery(hql);
List results = query.list();

При каких обстоятельствах таблица оракула будет заблокирована

Блокировки DML можно разделить на блокировки строк, блокировки таблиц и взаимоблокировки.

• Блокировка строки: когда транзакция выполняет операции вставки, обновления или удаления базы данных, транзакция автоматически получает монопольную блокировку строки операции в таблице операций.

• Блокировка на уровне таблицы: когда транзакция получает блокировку строки, транзакция также автоматически получает блокировку таблицы (разделяемую блокировку), чтобы другие транзакции не влияли на обновление строки записи операторами DDL. Транзакция также может получить общую блокировку или эксклюзивную блокировку в процессе.Только когда транзакция показывает, что эксклюзивная блокировка определена с помощью оператора LOCK TABLE, транзакция может получить эксклюзивную блокировку для таблицы или ее можно отобразить с помощью LOCK TABLE Определите общую блокировку на уровне таблицы (см. Соответствующие документы для конкретного использования LOCK TABLE).

• Тупик: когда двум транзакциям требуется набор конфликтующих блокировок, и транзакция не может быть продолжена, возникает тупик. Например, транзакция 1 имеет монопольную блокировку в записи строки №3 таблицы A и ожидает, пока транзакция 2 освободит монопольную блокировку в записи №4 таблицы A, а транзакция 2 находится в таблице A В строке записи №4 имеется эксклюзивная блокировка, и в ожидании, когда транзакция 1 освободит исключительную блокировку в записи №3 в таблице A, транзакция 1 и транзакция 2 ждут друг друга, что вызывает взаимоблокировку. Взаимоблокировки обычно возникают из-за плохого дизайна транзакции. Тупиковая ситуация может использоваться только в SQL: изменить сеанс уничтожения системы «sid, serial #»; или использовать команду соответствующего процесса уничтожения операционной системы, например kill -9 sid в UNIX, или использовать другие Инструмент убивает процесс тупика.

Блокировки DDL можно разделить на: эксклюзивные блокировки DDL, общие блокировки DDL, блокировки анализа.

• Эксклюзивная блокировка DDL: операторы DDL, которые создают, изменяют и удаляют объект базы данных, получают монопольную блокировку рабочего объекта. Например, при использовании оператора alter table для поддержания полноты, согласованности и законности данных транзакция получает исключительную блокировку DDL.

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

• Блокировка анализа: ORACLE использует общий пул для хранения проанализированных и оптимизированных операторов SQL и программ PL / SQL, чтобы приложения, выполняющие один и тот же оператор, работали быстрее. Объект, кэшированный в общем пуле, получает блокировку анализа на объект базы данных, на который он ссылается. Блокировка анализа — это уникальный тип блокировки DDL, Oracle использует ее для отслеживания зависимостей между объектами общего пула и объектами базы данных, на которые он ссылается. Когда транзакция изменяет или удаляет объект базы данных, удерживающий блокировку анализа в разделяемом пуле, ORACLE делает недействительным объект в разделяемом пуле. В следующий раз, когда на этот оператор SQL / PLSQL будет сделана ссылка, ORACLE повторно проанализирует и компилирует этот оператор.

Использование интерфейса Database Control для управления блокировками сеансов

Наиболее эффективный способ увидеть, какие блокировки в данный момент существуют в экземпляре, заключается в использовании инструмента Oracle Enterprise Manager (OEM) Database Control (или Grid Control). Попасть на эту страницу можно через Database Control Home Page -> Performance -> Additional Monitoring Links -> Instance Locks (Домашняя страница Database Control -> Производительность -> Дополнительные ссылки мониторинга -> Блокировки экземпляра). На странице Instance Locks (Блокировки экземпляра) отображаются все замки — как блокирующие, так и не блокирующие.Большинство замков, которые вы увидите, безвредны; это стандартные неблокирующие замки, которые Oracle использует для поддержки параллелизма.

Чтобы увидеть замки, которые вызывают соперничество между сеансами в системе, выберите элемент Blocking Sessions (Заблокированные сеансы) из раскрывающегося списка на странице Instance Locks. На странице Blocking Sessions (Заблокированные сеансы) отображаются все сеансы, которые в данный момент блокируют другие сеансы. Перейти непосредственно на страницу Blocking Sessions можно также по маршруту Database Control Home Page -> Performance -> Additional Monitoring Links -> Blocking Sessions (Домашняя страница Database Control -> Производительность -> Дополнительные ссылки мониторинга -> Заблокированные сеансы).

На странице Blocking Sessions отображаются идентификаторы блокирующих и блокируемых сеансов (рис. 1). Блокирующий сеанс можно прервать, выбрав его и щелкнув на кнопке Kill Session (Уничтожит сеанс).

На рис. ниже видно, что пользователь удерживает монопольную блокировку (на определенной строке таблицы , которую можно видеть на рисунке),тем самым блокируя попытки пользователя получить монопольную блокировку той же строки. Блокирующий сеанс идентифицируется значением 1 или выше в столбце (Заблокированные сеансы) на странице Blocking Sessions (см. рис. 1.). Блокируемый сеанс обозначается значением 0.

Узнать в точности состояние ожидания блокирующих и ожидающих сеансов можно на OEM-странице Hang Analysis (Анализ зависаний), которая доступна по маршруту Database Control Home Page -> Performance -> Additional Monitoring Links -> Hang Analysis (Домашняя страница Database Control — Производительность — Дополнительные ссылки мониторинга — Анализ зависаний). На странице Hang Analysis отображается следующая информация:

• мгновенно заблокированные сеансы;
• сеансы, находящиеся в продолжительном ожидании;
• зависшие сеансы.

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

На заметку!

Сервер 1С:Предприятие на Ubuntu 16.04 и PostgreSQL 9.6, для тех, кто хочет узнать его вкус. Рецепт от Капитана

Если кратко описать мое отношение к Postgres: Использовал до того, как это стало мейнстримом.
Конкретнее: Собирал на нем сервера для компаний среднего размера (до 50 активных пользователей 1С).
На настоящий момент их набирается уже больше, чем пальцев рук пары человек (нормальных, а не фрезеровщиков).
Следуя этой статье вы сможете себе собрать такой же и начать спокойную легальную жизнь, максимально легко сделать первый шаг в мир Linux и Postgres.
А я побороться за 1. Лучший бизнес-кейс (лучший опыт автоматизации предприятия на базе PostgreSQL).
Если, конечно, статья придется вам по вкусу.

Ограничения первичного ключа

Первичный ключ — очень важный тип ограничения в таблице. Когда необходимо,чтобы значения столбца идентифицировались уникальным образом, это обеспечивается созданием первичного ключа по значению столбца. Столбец, на котором определен первичный ключ, должен быть уникальным и не null.

Таблица может иметь только один первичный ключ, который можно создать при создании таблицы, как показано в следующем примере:

SQL> CREATE TABLE dept
(dept_id number(9) PRIMARY KEY);

Кроме того, можно добавить ограничение и к существующей таблице:

SQL> ALTER TABLE dept
ADD PRIMARY KEY(dept_id); 

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

SQL> ALTER TABLE dept
ADD CONSTRAINT
dept_pk PRIMARY KEY(dept_id);
Table altered.
SQL>

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

Столбцы первичного ключа должны быть указаны как отдельный элемент оператора CREATE TABLE после списка всех столбцов.

На заметку! В обоих предыдущих примерах Oracle автоматически создает индексы на столбце,который назначен первичным ключом.

Индексы с реверсированным ключом

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

При использовании индекса с реверсированным ключом базы данных не сохраняет ключи индекса друг за другом в лексикографическом порядке. Таким образом, когда в запросе присутствует предикат неравенства, ответ получается медленнее, поскольку база данных вынуждена выполнять полное сканирование таблицы. При индексе с реверсированным ключом база данных не может запустить запрос по диапазону ключа индекса.

Как отследить, какой процесс блокирует учётную запись домена

Итак, мы выяснили, с какого компьютера или сервера была заблокирована учётная запись. Теперь было бы здорово узнать, какая программа или процесс являются источником блокировки учётной записи.

Часто пользователи начинают жаловаться на блокировку своих учётных записей домена после изменения паролей. Это говорит о том, что старый (неправильный) пароль сохраняется в определённой программе, скрипте или службе, которая периодически пытается аутентифицироваться на контроллере домена с неверным паролем. Рассмотрим наиболее распространённые места, в которых пользователь мог сохранить старый пароль:

• Подключённые сетевые диски (через net use);
• Работы Windows Task Scheduler (Планировщика заданий Windows);
• Службы Windows, настроенные для запуска из учётной записи домена;
• Сохранённые учётные данные в Credential Manager (Диспетчере учётных данных) (в Панели управления);
• Браузеры;
• Мобильные устройства (например, те, которые используются для доступа к корпоративному почтовому ящику);
• Программы с автоматическим входом или настроенная функция автоматического входа в Windows;
• Отключённые/незанятые сеансы RDP на других компьютерах или серверах RDS (поэтому рекомендуется установить ограничения для сеансов RDP);

Подсказка: существует ряд сторонних инструментов (в основном коммерческих), которые позволяют администратору проверять удалённый компьютер и определять источник блокировки учётной записи. В качестве достаточно популярного решения отметим Lockout Examiner от Netwrix.

Чтобы выполнить подробный аудит блокировки учётной записи на найденном компьютере, необходимо включить ряд локальных политик аудита Windows. Для этого откройте локальный редактор групповой политики (gpedit.msc) на компьютере (на котором вы хотите отслеживать источник блокировки) и включите следующие политики в разделе Computer Configurations → Windows Settings → Security Settings → Local Policies → Audit Policy:

• Audit process tracking: Success , Failure
• Audit logon events: Success , Failure

В русскоязычной версии это соответственно: Конфигурации компьютера → Конфигурация Windows → Параметры безопасности → Локальные политики → Политика аудита:

• Аудит отслеживания событий: Успех, Отказ
• Аудит событий входа в систему: Успех, Отказ

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

An account failed to log on.
Failure Reason: Account locked out.

На русском это:

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

Как видно из описания события, источником блокировки учётной записи является процесс mssdmn.exe (компонент Sharepoint). В этом случае пользователю необходимо обновить пароль на веб-портале Sharepoint.

После завершения анализа и выявления и устранения причины блокировки не забудьте отключить локальные политики аудита.

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

Вы также можете вывести список событий с кодом 4625 в PowerShell:

Get-WinEvent -FilterHashtable @{ LogName='Security'; Id='4625'; }

Следующую команду вы можете использовать для вывода событий блокировки для конкретного пользователя (впишите его вместо MiAl):

Get-WinEvent -FilterHashtable @{ LogName='Security'; Id='4625'; Data="MiAl" }

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

Get-WinEvent -FilterHashtable @{ LogName='Security'; Id='4625'; Data="MiAl" } | Format-List

Эта команда аналогична предыдущей, но покажет события только за последние 2 дня:

$Date = (Get-Date).AddDays(-2); Get-WinEvent -FilterHashtable @{ LogName='Security'; Id='4625'; Data="MiAl"; StartTime=$Date; } | Format-List

Обслуживание индексов

Данные индекса постоянно изменяются из-за DML-действий, связанных с его таблицей. Индексы часто становятся слишком большими, если происходит много удалений сток, потому что пространство, занятое удаленными значениями, автоматически повторно индексом не используется. За счет периодического применения команды REBUILD можно реорганизовать индексы и сделать их более компактными, а потому и более эффективными. Команда REBUILD также служит для изменения параметров хранения, которые устанавливаются во время начального создания индекса.

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

Оперативную перестройку индекса можно ускорить за счет добавления к показанному выше оператору ALTER INDEX конструкции ONLINE NOLOGGING. После добавления этой конструкции база данных не будет генерировать данные повторного выполнения для операции перестройки индекса.

Модификаторы запроса SELECT

Вы можете использовать следующие модификаторы в запросах .

APPLY

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

Синтаксис:

Пример:

Исключает из результата запроса один или несколько столбцов.

Синтаксис:

Пример:

REPLACE

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

Этот модификатор не изменяет имена или порядок столбцов. Однако он может изменить значение и тип значения.

Синтаксис:

Пример:

Комбинации модификаторов

Вы можете использовать каждый модификатор отдельно или комбинировать их.

Примеры:

Использование одного и того же модификатора несколько раз.

Использование нескольких модификаторов в одном запросе.

Выявляем и оптимизируем ресурсоемкие запросы 1С:Предприятия

Обычно предметом оптимизации являются заранее определенные ключевые операции, т.е. действия, время выполнения которых значимо для пользователей. Причиной недостаточно быстрого выполнения ключевых операций может быть неоптимальный код, неоптимальные запросы либо же проблемы параллельности. Если выясняется, что основная доля времени выполнения ключевой операции приходится на запросы, то осуществляется оптимизация этих запросов.
При высоких нагрузках на сервер СУБД в оптимизации нуждаются и те запросы, которые потребляют наибольшие ресурсы. Такие запросы не обязательно связаны с ключевыми операциями и заранее неизвестны. Но их также легко выявить и определить контекст их выполнения, чтобы оптимизировать стандартными методами.