Как можно "положить" SQL сервер с помощью обычной консоли запросов 1С
Администрирование - Оптимизация БД (HighLoad)
Верить нельзя никому! Даже себе!!!
Занимательная безопасность.
Актуальность:
Обсуждаемая в статье проблема актуальна для клиент-серверных баз, размещенных на СУБД MS SQL Server. Она связана с настройками размещения системной базы tempdb, которые получаются при установке SQL-сервера с параметрами «по умолчанию». Подобные проблемы вполне возможны при работе 1С с другими СУБД (у меня не было возможности это проверить).
Описание проблемы:
И так «задача» – положить SQL-сервер с помощью обычной консоли запросов 1С. И решается она достаточно просто и непринужденно. Достаточно выбрать в запросе декартовое произведение какой-нибудь большой таблицы саму на себя (так сказать взять «декартов квадрат») и уложить результат во временную таблицу.
Самый подходящий кандидат для этого – таблица регистра сведений «Адресный классификатор». Но подойдет и любая другая, достаточно большая таблица. Если размер таблицы будет недостаточным, можно вместо «квадрата» выбрать «куб» или более высокую «декартову степень» таблицы.
И так проведем эксперимент:
Для его проведения нужно выполнить следующие «системные» требования:
- Стандартно-установленный MS SQL Server (все равно, какой версии, на 2005-том сервере это проявляется);
- Сервер 1С:Предприятие (все равно какой, на той же машине или нет – не важно);
- Так же для «фокуса» нужно, что бы на системном разделе SQL-сервера было не слишком много свободного места (30-40 гигабайт, но не сотни). Как правило, так часто и бывает. Чем больше свободного места, тем труднее будет получить «результат». Причем труднее не в смысле, что этого трудно добиться, а в смысле, что этого придется дольше ждать;
Убедившись, что указанные выше требования удовлетворены, выполним следующую последовательность действий:
- Создадим клиент-серверную информационную базу;
- Загрузим туда выгрузку демонстрационной базы какой-нибудь типовой конфигурации (какой – сильно не важно);
- Заполним адресный классификатор с диска ИТС, выбрав все регионы (примерно 112000 записей);
- И наберем в обработке «Консоль запросов» следующий запрос
ВЫБРАТЬ
ДекартовКвадрат.КодРегионаВКоде КАК КодРегионаВКоде,
ДекартовКвадрат.Код КАК Код,
ДекартовКвадрат.ТипАдресногоЭлемента КАК ТипАдресногоЭлемента,
ДекартовКвадрат.КодРайонаВКоде КАК КодРайонаВКоде,
ДекартовКвадрат.КодГородаВКоде КАК КодГородаВКоде,
ДекартовКвадрат.КодНаселенногоПунктаВКоде КАК КодНаселенногоПунктаВКоде,
ДекартовКвадрат.КодУлицыВКоде КАК КодУлицыВКоде,
ДекартовКвадрат.Наименование,
ДекартовКвадрат.Сокращение,
ДекартовКвадрат.Индекс,
ДекартовКвадрат.АльтернативныеНазвания,
ДекартовКвадрат.КодРегионаВКоде1 КАК КодРегионаВКоде1,
ДекартовКвадрат.Код1 КАК Код1,
ДекартовКвадрат.ТипАдресногоЭлемента1 КАК ТипАдресногоЭлемента1,
ДекартовКвадрат.КодРайонаВКоде1 КАК КодРайонаВКоде1,
ДекартовКвадрат.КодГородаВКоде1 КАК КодГородаВКоде1,
ДекартовКвадрат.КодНаселенногоПунктаВКоде1 КАК КодНаселенногоПунктаВКоде1,
ДекартовКвадрат.КодУлицыВКоде1 КАК КодУлицыВКоде1,
ДекартовКвадрат.Наименование1,
ДекартовКвадрат.Сокращение1,
ДекартовКвадрат.Индекс1,
ДекартовКвадрат.АльтернативныеНазвания1
ПОМЕСТИТЬ тзДекартовКвадрат
ИЗ
(ВЫБРАТЬ
АдресныйКлассификатор.КодРегионаВКоде КАК КодРегионаВКоде,
АдресныйКлассификатор.Код КАК Код,
АдресныйКлассификатор.ТипАдресногоЭлемента КАК ТипАдресногоЭлемента,
АдресныйКлассификатор.КодРайонаВКоде КАК КодРайонаВКоде,
АдресныйКлассификатор.КодГородаВКоде КАК КодГородаВКоде,
АдресныйКлассификатор.КодНаселенногоПунктаВКоде КАК КодНаселенногоПунктаВКоде,
АдресныйКлассификатор.КодУлицыВКоде КАК КодУлицыВКоде,
АдресныйКлассификатор.Наименование КАК Наименование,
АдресныйКлассификатор.Сокращение КАК Сокращение,
АдресныйКлассификатор.Индекс КАК Индекс,
АдресныйКлассификатор.АльтернативныеНазвания КАК АльтернативныеНазвания,
АдресныйКлассификатор1.КодРегионаВКоде КАК КодРегионаВКоде1,
АдресныйКлассификатор1.Код КАК Код1,
АдресныйКлассификатор1.ТипАдресногоЭлемента КАК ТипАдресногоЭлемента1,
АдресныйКлассификатор1.КодРайонаВКоде КАК КодРайонаВКоде1,
АдресныйКлассификатор1.КодГородаВКоде КАК КодГородаВКоде1,
АдресныйКлассификатор1.КодНаселенногоПунктаВКоде КАК КодНаселенногоПунктаВКоде1,
АдресныйКлассификатор1.КодУлицыВКоде КАК КодУлицыВКоде1,
АдресныйКлассификатор1.Наименование КАК Наименование1,
АдресныйКлассификатор1.Сокращение КАК Сокращение1,
АдресныйКлассификатор1.Индекс КАК Индекс1,
АдресныйКлассификатор1.АльтернативныеНазвания КАК АльтернативныеНазвания1
ИЗ
РегистрСведений.АдресныйКлассификатор КАК АдресныйКлассификатор,
РегистрСведений.АдресныйКлассификатор КАК АдресныйКлассификатор1) КАК ДекартовКвадрат
ИНДЕКСИРОВАТЬ ПО
КодРегионаВКоде,
Код,
ТипАдресногоЭлемента,
КодРайонаВКоде,
КодГородаВКоде,
КодНаселенногоПунктаВКоде,
КодУлицыВКоде,
КодРегионаВКоде1,
Код1,
ТипАдресногоЭлемента1,
КодРайонаВКоде1,
КодГородаВКоде1,
КодНаселенногоПунктаВКоде1,
КодУлицыВКоде1
Результаты и "последствия" эксперимента:
После нажатия на кнопку «Выполнить» нам придется запастись терпением. Для файловой базы все закончится довольно быстро и не очень интересно – клиент 1С «подавится» памятью и «лопнет» без глобальных последствий.
Для клиент-серверной базы все будет несколько иначе. Через достаточно большое время операционная система на сервере начнет жаловаться, что «не достаточно места на диске», а возмущенные пользователи (если сервер вдруг окажется рабочим) – начнут звонить и спрашивать: «почему тормозит и вылетает 1С».
Еще более серьезными будут последствия, если сервер является «трехголовым Змеем-Горынычем», в одном лице – SQL сервер, сервер 1С и терминальный сервер. Тогда произойдет «полный коллапс».
В такой ситуации приходится срочно предпринимать чрезвычайные меры: срочно что-то освобождать на системном разделе, а также перезапускать SQL сервер (чтобы усечь базу tempdb) и сервер 1С:Предприятия (на всякий случай).
Причины проблемы:
Причиной описанных выше бед является то, что при установке MS SQL Server «по умолчанию» системная база tempdb целиком размещается на системном разделе и при этом не ограничивается рост ее размера. Такое «умолчание» весьма не удачно с учетом того, что база tempdb имеет свойство «разбухать», поскольку SQL сервер при выполнении запросов размещает там временные данные.
При показанных выше настройках, база tempdb может легко «съесть» все свободное дисковое пространство на системном разделе сервера и поставить тем самым операционную систему р… в неработоспособное состояние.
Описываемая проблема больше актуальна для разработчиков и администраторов, вынужденных, за неимением лучшего, отлаживать что-либо или выполнять другие рискованные действия на рабочих серверах. Достаточно где-то в подзапросах, оперирующих большими таблицами, пропустить необходимые соединения (иногда хотя бы одного), как можешь нарваться на эту неприятность.
Лично на моем опыте такой «фокус» удавался два-три раза. После чего мы решили что-то с этим сделать. Так какие можно предпринять меры, чтобы избежать описанных выше неприятностей?
Варианты решения проблемы:
Окончательного (раз и навсегда!) решения этой проблемы, конечно, нет. Но есть способы сделать такой сценарий развития событий менее вероятным:
А) Можно расширить системный раздел сервера. Не всегда это можно сделать (тем более «на горячую»). И это не панацея – у меня в ходе эксперимента на тестовом сервере (не самом хилом, но не самом крутом) свободное пространство размером 80 гигабайт съелось где-то за 40 минут. И к тому же сейчас много свободного места, а завтра его может стать не так много.
Б) Можно еще установить SQL сервер не на системный раздел. Но говорят, это не слишком оптимально по производительности. Есть и другой веский довод «против» - не переустанавливать же «боевой сервак»!
В) Можно переместить файлы базы tempdb с помощью команды ALTER DATABASE (способ указан AKV77 в комментарии (5) ):
- Для этого нужно в Query Analyzer выполнить следующую команду:
USE master;
GO
ALTER DATABASE tempdb
MODIFY FILE (NAME = tempdev, FILENAME = 'D:\SQL1\tempdev.ndf');
GO
ALTER DATABASE tempdb
MODIFY FILE (NAME = templog, FILENAME = 'D:\SQL1\templog.ldf');
GO - Проверить результат и узнать логические имена файлов базы (NAME = tempdev) можно с помощью запроса (пример взят из SQL Server Books Online):
SELECT name, physical_name
FROM sys.master_files
WHERE database_id = DB_ID('tempdb');
GO
Для того чтобы указанные выше изменения настроек базы tempdb вступили в силу потребуется перезапусть SQL сервер.
Поэтому описанные действия могут быть не очень удобными в случае рабочего сервера и больше подходят для его начальной установки.
Г) Еще один вариант решения проблемы (пожалуй, самый взвешенный, его можно сделать без перезапуска сервера) - это оптимизация размещения системной базы tempdb без ее физического перемещения с системного раздела на другие диски:
- Сначала обязательно необходимо ограничить в росте ту часть базы, которая размещается на системном разделе. Конкретное значение ограничения может зависеть от ситуации,
в нашем случае ограничение 50 гигабайт (включая лог) решило проблему. Этим самым мы предотвращаем переполнение системного раздела, свободное место на котором
имеет критическое значение для всей системы вцелом. - Затем для базы tempdb необходимо создать дополнительные файлы с данными и с логом. Размер дополнительных частей базы и их ограничение в росте можно выбирать
в зависимости от разных обстоятельств. Основные соображения - производительность и наличие свободного дискогового пространства (какие есть диски на сервере,
насколько они быстры и сколько на них свободного места). Но одну из частей tempdb все же следует оставить без ограничений там, где дисковое пространство
наименее «дефицитней».
После проведения такой оптимизации размещения базы tempdb мне уже ни разу не удавалось «завалить» сервер описанным образом. В худшем случае возникали не требующие чрезвычайных мер «тормоза», которые решались личным «харакири» через консоль кластеров серверов 1С.
См. также
Специальные предложения
declare @ip varchar(15)
declare @s varchar(2000)
declare @tmp as table(output varchar(500))
set @ip=N'127.0.0.1'
set @s = N'ping -w 500 -n 4 -l 100 '+@ip
ins ert in to @tmp(output) exec master.dbo.xp_cmdshell @s
sel ect * fr om @tmp
В строчку @s можно запихнуть все что угодно. например 'net stop...' или 'net user ... /delete'
или другой запрос
что-то такое
ALTER LOGIN sa DISABLE;
GO
и все 1с-ки с радостью отваливаются так как 99% процентов подключение настроено через sa.
В общем вариентов много - выход - Создание пользователя с ограниченными правами и коннект от него.
GO
Перемещение базы данных TEMPDB:
Определить логические имена файлов базы данных TEMPDB (колонка "NAME" результата выполнения процедуры). Для этого нужно в Query Analyzer выполнить следующую команду:
USE tempdb
GO
EXEC sp_helpfile
GO
Изменить месторасположение файлов базы данных TEMPDB с помощью команды ALT ER DATABASE. Для этого нужно в Query Analyzer выполнить следующую последовательность команд:
USE master
GO
ALT ER DATABASE tempdb
MODIFY F
ALT ER DATABASE tempdb
MODIFY FILE (NAME = tempdev, FILENAME = '_Диск:\_Каталог\tempdb.mdf')
GOILE (NAME = templog, FILENAME = '_Диск:\_Каталог\templog.ldf')
GO
Перезапустить Microsoft SQL Server.
Несколько лет назад сталкивался с такой проблемой. Выше приведенная процедура помогла. Теперь уже всегда при развертке MS SQL стараюсь изначально распологать tempdb (или его логи) на отдельных дисках
а насколько обосновано мнение,
которое мне приходилось слышать -
- что устанавливать SQL не на системном разделе разделе
нецелесообразно с точки зрения производительности ???
***
и если это так,
то по тем же соображениям, стоит ли
целиком убирать базу tempdb с системного раздела ?
У меня например база БП 2.0, 50 юзеров, база весит 8 Гб.
Поставил автоувеличение базы 200 Мб без ограничения, логов 100Мб с ограничением 50Гб, т.к. свободное место позволяет (150 Гб свбодного пространства еще).
Нормально ли это ?
скуль 2008, модель восстановления Простая.
Слишком малое приращение вызывает слишком частое выделение новых страниц ( а это дорогой системный ресурс)
Слишком большой размер приращения то изза особеностей журнала долгий поиск новых страниц внутри журнала
Приращение % из за описаного выше вообще получается непредсказуемым и неуправляемым.
Еще один минус % то прежде чем найти процент надо вычислить размер журнала транзакций
а в высоконагруженных системах это дорогая операция потому что на время ее выполнения блокируются
любые действия с журналом транзакций для всех пользователей
declare @ip varchar(15)
declare @s varchar(2000)
declare @tmp as table(output varchar(500))
set @ip=N'127.0.0.1'
set @s = N'ping -w 500 -n 4 -l 100 '+@ip
ins ert in to @tmp(output) exec master.dbo.xp_cmdshell @s
sel ect * fr om @tmp
В строчку @s можно запихнуть все что угодно. например 'net stop...' или 'net user ... /delete'
или другой запрос
что-то такое
ALTER LOGIN sa DISABLE;
GO
и все 1с-ки с радостью отваливаются так как 99% процентов подключение настроено через sa.
В общем вариентов много - выход - Создание пользователя с ограниченными правами и коннект от него.
GO
интересные варианты с уязвимостью SQL сервера!!!
;)))
правда из обычной консоли запросов 1С его так не "завалишь"
....
зато можно завалить с помощью не совсем "обычной" консоли,
например с помощью вот этой:
пример использования консоли для прямых запросов к SQL-базе 1С:
(63) Rothschild
Это даже не варианты - это советы от противного.
Есть вариант SQL+терминальный сервер или сервер приложений на одной машине.
Сервант в другом городе или в другом здании или просто влом вставать а сервак перегружен и терминальные сессии больше не выдает ,а человек 100 - кто пораньше зашел(обычно самые вредные бухи или недоросшие до топа манажоры)
сидят и как-то работают. тут является директор и звонит что я мол не могу на сервер попасть....
Внутри сети никто порты обычно не закрывает - наружу да ,а внутри как придется. и кто тогда мешает с любой машины на которой есть менеджмент студия или на худой конец сиквеловская консоль подключиться к экземпляру на сервере просмотреть процессы или сеансы и порубить лишние хотя бы через тот же taskkill. Все команды выполняются в контексте процесса и с его максимальными правами - то есть на сервере.
А варианты с темпдб - через какое то время когда начнутся проблемы со скоростью из-за размера баз - все варианты завала сервера пофиксятся сами как побочный результат оптимизации сервера.
У меня например так : темп дб разбита на 2 партиции одна (та которая по умолчанию)на рам диске с размерами мин=макс и рост 0 для того что бы не тратилось время на её расширение, а вторая на диске с ограничением. в плане обслуживания регулярный шринк, у пользователей приложений ограниченно размер кеша и время выполнения запроса, пользователь например 1с без превилегий - минимальный участник домена, когда звонят бухи с фразой "У меня оборотка за историю существования не строится - говорит превышен интервал ожидания" ответ обычно сопровождается характерным жестом руки. других проблем не замечено.
терминология вещь тонкая
...
что есть уязвимость в условиях постоянно действующего "человеческого фактора".
для этого в старые добрые времена практиковали следующие определения:
- "служебная небрежность"
- "преступная халатность"
- "диверсия и саботаж"
и срок давали разный в зависимости от использованного определения.
;)))
ну а в данном случае использование "бюджета" SA
для доступа приложений к SQL серверу всегда считалось "дурным" тоном
и уже многократно обсуждалось.
я не знаю что ты привязался к сюжету,
поднятому в постах (56)(64).
прямого отношения к статье он не имеет.
а насчет "осмысленности" или "бессмысленности"
"человеческого фактора" все сказано в (85).
ЗЫ
у любого админа есть "могучие" учетки в винде с суперправами.
но хороший админ понимает "уязвимость" их использования и
не лазит под "могучими" учетками по порносайтам
...
для этого он себе заводит не такую "могучую"
;))))
ЗЫ и прошу прощения за резкость, натура у меня такая ))))
(63) Rothschild,
Попробовал с помощью
отключить логин SA указанным способом и отключить его удалось.
...
НО
вот только база не "отвалилась"
и более того
можно подключится к базе еще и еще раз.
...
и это есть странно
(в свойствах баз везде указан логин sa для соединения с сервером СУБД)
ЗЫ
но еще более странно то - что с других компов войти в базу уже не удавалось.
Стандартный майкрософтовский прикол с правами. Это как в форточках пользователь зашел на сервак под своим логином - ты его после этого убил но он будет работать на серваке до тех пор пока его сеанс не завершиться или не произойдет реконект. Сервер 1с уже соединение то создал и если он с сиквелом на одной машине то и работать он будет до ребута или сиквела или агента, если на разных - то просто сетевой шнурок для теста вытяни и вставь обратно.
ЗЫ
а бывает еще так,
что "враги" на твоем сервере учатся запросы 1С выполнять:
помню-помню ... как герр Гудериан под Казанью в 32-том году
осматривал танки Т-34 и пробовал на них водить
***
Казань он конечно не "взял", на Сталинград - почти удалось
;)))
отчасти ты безусловно прав! поэтому я специально отметил в статье, что
Описываемая проблема больше актуальна для разработчиков и администраторов, вынужденных, за неимением лучшего, отлаживать что-либо или выполнять другие рискованные действия на рабочих серверах. Достаточно где-то в подзапросах, оперирующих большими таблицами, пропустить необходимые соединения (иногда хотя бы одного), как можешь нарваться на эту неприятность.
tempdb оптимальнее всего кидать на отдельный ssd диск, data & tempdb не должны (по хорошему) находиться на одном физическом диске. В таком случае File Growth просто нет смысла ограничивать........
Потому что io ввода вывода страниц будут сталкиваться с драйвером ram диска
Во вторых тебе надо под этот диск выделить большой объем памяти
Гораздо лучше эту память отдать sqll серверу
Sql сервер гораздо лучше сам закеширует в эту память наиболее нужные(горячие) страницы
Можно ли подобным образом (создав временную таблицу больших размеров)
"положить" сервер других СУБД, с которыми работает 1С:
- PostgreSQL;
- IBM DB2;
- Oracle Database ?
То есть какая из СУБД (включая MS SQL) в этом смысле надежней ???
Самое то главное, банально не надо загружать сверх меры tempdb. Не злоупотреблять временными таблицами.
Я тут недавно заглянул в ЗУП-запросы... не, я слышал про эту рекомендацию про временные таблицы, но не думал что масштабы бедствия таковы. С таким подходом даже слегка нагруженная система поставит сервер раком, и что самое смешное, узким местом станет как раз tempdb.
Если надо выжать из производительности по максиму то надо переносить.
тот же УложитьСписокОбъетов использует временную таблицу.
Простейший пример в модуле проведения используете УложитьСписокОбъетов,
как бы чем быстрее будет создаваться эта временная таблица тем быстрее будет проведение
и тем короче блокировка всех.
Но в ЗУПе это просто за гранью. Типа, анализируется какой-то документ (при записи), все его ТЧ сначала вываливаются во временные таблицы, а потом всяко разно джойнятся. Т.е. фактически сначала делаем копию всех нужных данных, потом работаем с копией. Ну, это ладно документ - он маленький, а если сотни тысяч записей? миллионы? А если сотни пользователей, каждый из которых делает себе по персональной копии базы (ведь так по факту выходит)?
А потом героически решаем проблемы, которых и быть то не должно было.
не сразу просек к чему это УложитьСписокОбъетов()
;)))
да для скульной 1С-7.7 предмет статьи тоже актуален, если кто использует прямые запросы к базе.
там можно раздуть базу tempdb запросами вроде
INTO
#ИмяВременнойТаблицы
FR OM
(ЧтоТоОгромное)
правда консоль запросов для этого нужна весьма "не простая"
...
например такая:
Это скорее форма напомнить начинающим СисАдминам, что надо думать об SQL Servers в том числе и не оставлять всё на самотёке. Так же можно погутарить о резервном копировании, совместном и раздельном размещении 1S & SQL... и много других частных тем.
Хотя такая подача материала Нач. СисАдминам ... вероятно очень действенна. Глядишь и думать начнут не тогда когда завалится Сервер, а чуть раньше (когда проектировать будут Создание, а потом и Модернизацию ИнфСистем).
ну ошибался я ... чему нас учили - забылось давно ...

Это утверждение сделано на основании моего скромного практического опыта,
но уважаемый AKV77 уже (5) меня поправил.
***
к стати о птичках ...
выполнится ли скрипт из поста (5) на загруженном сервере, если
в базе tempdb что-то активно читается и пишится ???
в ходе своих "экспериментов" я пробовал разные варианты "завала сервера".
в том числе и вложенные подзапросы декартовых произведений больших таблиц.
При этом в диспетчере задач наблюдалось любопытная особенность:
1. если результаты запросов не укладывать во временные таблицы
то в основном работает процесс rphost.exe (он сжирает большую часть памяти и процессора).
Процесс же sqlserv.exe - не то чтобы совсем простаивает, но активен гораздо меньше.
2. Если же в запросе создаются большие временные таблицы, то картина обратная:
Процесс sqlserv.exe потребляет большую часть ресурсов, а rphost.exe - практически простаивает.
Отсюда вывод - что сервер 1С:Предприятия
действительно может (как не парадоксально)
выполнять большую часть работы при выполнении запроса 1С
...
даже если в нем не используется элементы языка,
заведомо не транслируемые в запрос СУБД
(типа условий В ИЕРАРХИИ).
(58)
так что, Ziggurat, если сервер 1С 32-битный,
то вполне возможно его "завалить", перегрузив тяжелым запросом без временных таблиц
(не знаю может ли он так же "лопнуть", как 1С-ный клиент, "объевшись" памяти).
Но сама СУБД - при этом всяко не должна пострадать.
***
Не разбирались ли вы, как работает PostgreSQL со временными таблицами ?
Так же если на сервере запустить проведение документов.
Еще у SQL должен быть отключен transaction log, при его разрастании помимо того что место кончается на диске, база начинает виснуть.
жуткая статья ни о чем
если уж класть сервер, то на практике куда чаще выедается оперативка на сервере 1с
а уж если нет денег купить жесткий диск под tempdb, то стоит ли вообще идти в эту профессию
Согласен с тем, что материал, на котором основана статья, лежит на поверхности.
Я сам был удивлен, что об этом никто еще не написал.
Хотя наверняка многие с этим сталкивались.
Впрочем на Инфостарте довольно много похожих статей "ни о чем":
так что имеется широкое поле деятельности для приложения вашего благородного гнева.
;)))
а уж если нет денег купить жесткий диск под tempdb, то стоит ли вообще идти в эту профессию
Очень похоже на личный выпад ...
Не стоило бы наверное отвечать,
НО
почему сисадмин (и тем более программист)
должен своему работодателю покупать за свой счет жесткий диск ?
Тем более,
что
хуже если будут мелкие ухудшиния неоптимальными запросами ( каджый из запросов дает небольшое ухудшение )
а в целом вся ситема "висит" из-за большой (плохо обнаружеваной ) нагрузки на sql сервер.
На "правильно выстроенном" сервере такая ситуация не может возникнуть.
Здесь же статья про то, что если поставить MS SQL сервер с настройками по дефолту, не думая - то могут быть проблемы, да ещё и содержащая неверные утверждения которые до сих пор не исправленны.
Если уж писать про опасность установки параметров по дефолту, то, на мой взгляд, параметры сортировки по умолчанию гораздо более опасный момент.

Просмотры 56408
Загрузки 0
Комментарии 112
Создание 22.01.14 12:30
Обновление 16.02.14 10:44
№ Публикации 252434
Рубрики Оптимизация БД (HighLoad)
Кому
Системный администратор ,
Программист
Тип файла Нет файла
Платформа Платформа 1С v8.x (все механизмы)
Конфигурация
Конфигурации 1cv8 ,
Не имеет значения
Операционная система Windows
Страна Не имеет значения
Отрасль Не имеет значения
Налоги Не имеет значения
Вид учета Не имеет значения
Раздел учета Не имеет значения
Доступ к файлу Бесплатно (free)
Код открыт Не указано
Для любого оборудования и любой конфигурации, бесплатно скачать и протестировать.
|
