8.2.13 + MSSQL2008
В конфигурации одна из таблиц имеет порядка 6 млн. записей, их необходимо выводить отчетом на СКД с отборами по нескольким полям, упорядочиванием и несколькими группировками только из этой таблицы, никаких соединений и объединений нет, НО данные не то что через отчет не выводятся, даже через консоль запросов не осилил...сначала вылетала ошибка что недостаточно памяти на сервере приложений, поднял лимит в настройках кластера, теперь - что то типа: "удаленный хост принудительно разорвал существующее соединение". Подскажите плиз что можно еще предпринять? Может в самой СУБД что то настроить надо?

(0) Перейти на Оракл не предлагать?

отчет на 6 мулионов строк под собой не имеет смысла...

(2) А это, может, ОАО "Газпром" какой? ;-)

(3) а разница? чего с ним делать? садиться бухам с линейкой и крыжыть?

(1) боюсь что зажмут 6 килобаксов на субд

Выборкой по 15 строк набирайте.
Это не та "СУБД", чтобы веньгаться "хочу 10 муллионов строк обработать!"
И поменьше читайте рекламки 1С....

(1) а чем оракле поможет? затыкается клиент... а он такой - 2 Гб выжрал и привет горячий...

>И поменьше читайте рекламки 1С....

причем тут 1С...

(2) Неее, все 6 миллионов нафик не нужны, нужно выбрать данные, отобранные по некоторым условиям...

(7) почему 2 ГБ?

мне бы хоть 500 строк отобрать и сгруппировать красиво...дык не хочет ругается

(10) потому... что клиент 32-bit

(6) поподробнее плиз? речь о той выборке что СправочникМенеджер.Выбрать()? Если да, то такой отчет будет ~недельку формироваться...И Выбрать() вроде по 25 строк выбирает, но могу и ошибаться.

(10) можно больше дать памяти - PAE и /3G

(12) 2^32=4294967296 вроде всегда было

(15) приложению доступно не более 2ГБ.
Иначе - смотрите (14)

(15) память адресуюмую осью и память доступную процессу отличать умеем?

(13) Можно выборкой неделю отбирать нужное, сортировать по вспомогательным регистрам, а потом лихо за минуту выбрать окончательно ))
Как получилось, что Менеджеров стало 6 млн?

>/3G

а клиент 1С про это знает? Он 3GB-aware?

*а, елки, что вообще за справочник такой огромный?

например больных... или если шире взять - льготники

(19) достаточно на SQL разрешить.
1С все равно выше своих "кэшей" долбаных не прыгнет - разрешай - не разрешай.
Только запросы рубить уж если.

(17) да, осознал свою ошибку, пардон.

Надо было вообще другую платформу брать.
А не поделку для ларьков.
Остается одно - выбирать месяц данные и делить на регистры по областям.
И не делать больше гигантских объемов.

смотрел через taskmanager на потребеление клиентским процессом памяти - оно держалось на уровне 200 мб и не дергалось, такое впечатление что затыкается либо субд либо сервер приложений или я не прав?

2(25)ну то есть уже rphost и sql server ты решил в таск менеджере не смотреть, подумал что на форуме оно надежнее?

(25) ну может и скуль затыкаться... если он сам 32-bit на 32-bit оси и без костылей из (14)

(250 клиент-то причем?
Вот порядок ваших проблем: SQL не хватает ресурсов (памяти и пр).
Даже если SQL "потянет", 1С-сервер точно рехнется на таких данных.
А клиент - что клиент, ему пофиг, он с сервера данные теперь получает.

(26) я бы с радостью, но могу видеть только свои процессы, остальное только одмина надо просить показать...
(27) естественно скуль х64, ось win2008 r2

2(29) Могу себе представить сидит админ такой... "Так, 1Снику админские права не дам - ему-то зачем, у него Миста есть..."

(29) ну вот пусть "админы"-начальники попы оторвут и придумают, какая СУБД лучше соответствует обработке таких объемов.
А не только деньги стричь да подчиненных погонять.

(30) Нету его сейчас, будет только завтра. Конечно посмотрел бы если бы доступ был...

(0) на скл написать хранимую процедурку, которая выберет все что нужно, через АДО пихать выборку в набор данных СКД. Ток так видимо.

2(32) вот иссяк разговор, честно... с аналогичной пользой можно обсудить погоду

>>>Неее, все 6 миллионов нафик не нужны, нужно выбрать данные, отобранные по некоторым условиям

покажи запрос который затыкается и напиши структуру таблицы (с учетом индексов и их порядка)

структуру полей таблицы в студию

(35) +1

банально "кривой" с точки зрения строения БД запрос лупит по всей таблице...

(33) а потом брать другой справочник? делать соединения? Отборы?
Да вообще нафиг заменить 1С-сервер и выкинуть его за ненадобностью. Ибо все можно через запрос на T-SQL и во внешний источник.
(32) пишите докладную на идиотов-начальников, и пусть самое верхнее руководство принимает решение - будут покупать за свой счет или пойдут искать новую работу.
Дальше только все будет глубже завязываться, что-то и заработает, но все равно рано или поздно встанет колом и будете виноваты вы.
Как "вовремя не предупредивший".

>какая СУБД лучше соответствует обработке таких объемов.

каких таких объемов? 6 000 000 строк для скуля не много

(37) а как он будет еще лупить, если там - список 6-ти млн человек? И нужно выбрать - кто старше 40 лет??

(39) ну конечно, не много.
Если не учитывать, что ~1 млн строк жрут уже более 2 ГБ.
То да, не много.

* 1 млн строк в выборке

(37) обычный селект топ 100 должен отработать всегда на любой кривой таблице, пусть она даже содержит всех физ. лиц России.

(35) индексированы только поля код, наименование и дата, выбирается дата, наименование и еще три неиндексированных поля, отбор по дате либо неиндексированным полям производится, упорядочивание тоже по ним. Можно попытаться проиндексировать еще три поля, но помнится мне что в есть какой то предел на размер индекса...боюсь что база ёкнется, а с бекапа поднимать долго. Существует такое ограничение? Или то только в фаловой?

(40) по индексу с высокой селективностью...

(44) *пардон "фаЙловой"

(43) а где тут top 100? тут табличка с неизвестными индексами и текстом/планом запроса...

у меня бухия 1.6 за весь период имела около 6 мульенов записей в регистре бухгалтерии.... это много???

(48) Семечки. если не попытаться конечно всё это в отчет не запихнуть и все 6 лямов на экран вывести.
(44) Посмотри какое количество записей возвращается запросом.

(48) вы отличаете, когда запрос берет итоги или по периоду данные, а когда - целиком весь регистр пережевывает?
Вот у ТС - второй вариант.
(сколько раз уже слышал - "а у нас 250 Гб база! и 1С тянет! мы крутые! Слава 1С!"
Выгнали бы несколько тысяч таких "начальничков", глядишь, другие бы умней стали).

(46) сделай запрос ВЫБРАТЬ ПЕРВЫЕ 100
    Код Наименование

(50) у меня регистр СВЕДЕНИЙ не переодический примерно 4 мл записей, запросы к нему порядка 1..3 сек идут (и оптимизацией практически не занимались)

(49) не могу, процесс крашится при выполнении оного...сначала думает минуты 2-3, а потом вылетает с ошибкой

(52) +1

(51) делал, выбирает, но тоже со скрипом

(55) из под 1С? Роль какая - полные права?

(52) да, конечно, я по мисте сервера изучал.
1С и 4 млн записей.... одним запросом...
ну-ну.

(56) да, да

(56) канеш

(4) таблица, таблице - рознь

(60) 2(57)

да, забыл упомянуть, там 24 поля, 1/4 из них строки длиной ~100 символов и еще одно ~300 символов...

(52) какой регистр сведений - ответственные лица???? большая текучка кадров, да?

(62) походу тупо памяти скулю (или серверу 1с ) не хватает. Заюзал бы на х64 (если есть возможность).

(63) :D

если перенести все данные из справочника в РС что то изменится в лучшую сторону? Регистр сведений не страдает от лимита количества измерений аля Регистр накопления?

(62) а слона то он и не заметил

(64) дык у нас уже все что можно х64, и ось, и сервер приложений, и субд..разве что клиент 32-битный

(67) виноват : (

(66) это вообще-то разные абсолютно вещи.
посмотри как сделан в типовых адресный классификатор.

чем закончилась то история ?

(66) в 1С есть ограничения на количество измерений РС/типы данных в них (что-то не более 900 символов на все измерения выделяется).
Записей должно быть не больше 999 999 999.

(69) Гонишь. Сервер не может крашиться просто при подсчете количества записей в таблице. Хоть миллиард записей будет, он тебе мгновенно вернёт единичку и девять ноликов. иначе у тебя уже физическое повреждение данных в таблицах или самих таблиц или железа.

ТС что-то не договаривает...

(74) только одно не договаривает: какой идиот взял 1С и заменил ей ранее работавшую СУБД.

(75) есть и такое подозрение

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

структуру таблицы с запросом, я так понял, мы не увидим?

(77) системные требования для обработки 6 млн записей озвучьте.
Также желательно - версии SQL и OS.

(72) Откуда дровишки?

(80) на измерения или количество записей?

>>>>да, забыл упомянуть, там 24 поля, 1/4 из них строки длиной ~100 символов и еще одно ~300 символов...

видать структуры мы не увидем, стыдно показывать!

(0) переделывай регистр!!!

(81) и на то и на то

(81) Хотелось бы более подробно почитать просто.

Ну и да у меня тут в РБ лежит порядка 2 млн записей - отчеты нормально строятся.

(83) измерения - попробуйте создать десяток измерений с типом "строка" и длиной 200 символов.
Про кол-во записей - читал, еще удивился, что так много для 1С.

Афигели. У меня только заявок в базе полтора мильёна, а в каждой табличная часть - и ничего не тормозит и не рушится.
(85) Троль?

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

(86) а я че-то сомневаюсь, что ты олимпиады выигрывал.
Разве что егэ.

У меня регистр остатки - несколько десятков миллионов записей. Ничего не продумано, работает типовой.

(87) записей может быть и миллиард, и лежат они в 500-ах БД.
А выбирается - по 30-50 тыс. за раз.
И все работает на C2D.

(85) и правда

В процессе обновления информационной базы произошла критическая ошибка.
по причине:
Ошибка СУБД:
Длина ключа индекса превышает максимально допустимую '_InfoR12145_ByDims_SSSSSSSSSSSS (_Fld12146, _Fld12147, _Fld12148, _Fld12149, _Fld12150, _Fld12151, _Fld12152, _Fld12153, _Fld12154, _Fld12155, _Fld12156, _Fld12157)'
по причине:
Длина ключа индекса превышает максимально допустимую '_InfoR12145_ByDims_SSSSSSSSSSSS (_Fld12146, _Fld12147, _Fld12148, _Fld12149, _Fld12150, _Fld12151, _Fld12152, _Fld12153, _Fld12154, _Fld12155, _Fld12156, _Fld12157)'

(88) Точно троль. Я угадал.

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

Только тролю может прийти в голову создать десяток измерений типа строка. Да еще и длиной 200.

(91) на самом деле - 1С не такая крутая штука, как разводят некоторые "олимпиадники".

(62) (0) усиленно курим понятия: "Нормальные формы", "Индексы"

P.S. про НФ курим 3 раза...

(93) С Ж_ывотными стараюсь не общаться.

(95) да просто не надо сравнивать мягкое с теплым

(98) какая разница, если нужно обработать огромный запрос? не так, так через соединения-объединения.
1С всегда найдет отчет/запрос, чтобы перебирать всю таблицу, какая бы огромная она не была.

(100) за удачников

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

(99) при чем тут 1с? Посмотри на структуру его таблицы. К тому же запрос так и не показан.

(101) А как лно не в рОссии?? Нормально все? Очко не жмет???

(103) Кормим троля? :) У него смысл жизни делать запросы с фильтрами по неиндекcированным полям, причем по десятку измерений типа строка, длина 200. ИМХО даун какой-то. Как он по-русски писать умудряется?

(104) так через гугль транслит, он и читает так же.

(105) Гугль с даунского умеет? :)

(103) теорему БЖ скоро не осилит ни один 1С-сервер - настолько огромна база уже её база.

(107) УГ

(107) От точно через гугль переводиш и пишешь

МишельЛагранж - что за кловун?

(110) судя по темам, большой любитель RLS ;)

(110) Такой вот он северный олень

МишельЛагранж - почитай про кластерный индекс и про денормализацию данных, может и поймешь чего нибудь в программирование

6 миллионов записей в таблице - не так уж и много для SQL

(0) Конфигурация типовая? ))))))))))

(71) она продолжается...
(73) тот запрос, что выбирает данные крашится. если просто через КОЛИЧЕСТВО(), то 6 368 616 записей
(75) ниче не заменяли, наша база для учета продолжает себе работать, эти данные были импортированы из другой, не 1Совской базы
(82) написал же что это справочник, а не регистр. Структуру приблизительно описал в (44) И да,не увидите, но по другим причинам...
(100) ты печален
(108) (112) развели тут срач понимаешь =)
(114) если не смотреть на (62), то да - немного

Проблема была в том что в скуле был установлен лимит на потребление озу = 8 ГБ, у меня туда достуа просто нет :(
Про ограничение на размер индекса так никто и не ответил, скуль таким не страдает?
Теперь проблема в объеме озу на сервере, начинается выполнение запроса и потихоньку скушивается вся память...
Если проиндексирую необходимые поля и настрою отбор так, чтобы вывелось скажем 400 строк, память израсходуется только на то чтобы уместить эти 400 срок и индексы или нет?

(116) Значить офигительно круто спроектировано :)
И что у тебя в полях по сто символов ? У тебя по ним индекс строится ? Данные в них структурированные или в каждой строке таблицы уникальные строковые значения в полях ?

(117) строковые поля уникальные, иначе бы сделал справочник под них. Индекс не строится ибо нафик не нужен - по ним ни сортировка, ни упорядочивание не выполняются. Индексированных полей всего 3, нарошно не ставил индексы куда попало, чтобы ускорить загрузку данных в 1С (на перестроение индекса куча времени уходит).

(118) >строковые поля уникальные
6 000 000 - гуиды что ли?

(118) Тогда все равно не много , бусть себе лежат , жрать не просят :)
(119) Фига се гуид 300 символов - к каждому атому вселенной наверное :))

(119) нет, там просто текст - некое описание свойств объекта. Оно то может совпадать, но таких немного, а раздувать базу из-за сомнительного преимущества не хочется.

И принципы нормализации баз все равно нарушены :(

Я бы сделал какрас с одним справочником - Код, Наименование, Реквизит (строка,50). В справочник запихнул бы 6 млн. записей с рандомными кодом, наименованием и реквизитом (гнапрмер ГУИДы), каждый сотый элемент записывал бы с одинаковым значением реквизита - символов 40. А потом бы запросом нашел все элементы справочника с этим реквизитом. Если не рухнет - то наращивал бы реквизиты справочника. Если сразу рухнуло - то явно дело в связке платформа-СУБД.

(122) Прямо телепат, это из (0) Было ясно.
(121) Нужно однако структуру менять. Поля по 100 и 300 строк выносить в справочник, делать ссылки на регистр - тогда взлетит. Или в SQL лезть там смотреть на индексы, селективность, может порядок полей поменять....

(124) Не на, а в регистре.

(123) Угу , третья нормальная форма

(124) в 0 про несколько строковых полей по 100 и одному на 300 еще ничего не было :)

(123) тут уже вопрос в ограниченном объеме RAM на сервере.
(125) данные в справочнике, а не в регистре. Чет я сомневаюсь что от этого запрос меньше памяти станет потреблять.

Что с индексами делать? Что по (116) скажете? Мне важно чтобы, получая данные из БД, не нагнуть сервак ненароком, там много народу работает...

(128_ Так может лучше сначала сгруппировать что-нужно, посчитать аггрегаты нужные, а потом уже вывод на экран делать.
Я что-то, не  уверен что все поля и все строки нужны.
Тогда уже в OLAP залезте.
6 лямов строк да если каждая по 30кб это 180Гб. Прикинь через клиента тянуть и на экране показать?
Нет прямиком в OLAP...

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

Выигрыш будет огромным по экономии памяти

(128)  Совет, попробуй сделать запрос только выбирать не все символы из длинных столбцов, а скажем подстроку первые 25 - 50?
Если отработает, то дело в памяти.

(130) Абсолютно присоединяюсь к оратору. Даже если платформа позволяет делать поля по 300 символов, это не значит, что так нужно делать.

(129) Ну на практике если точно известно что в выборке гарантированно будет не более нескольких сотен строк , и строится она будет строго по индексированным полям , такую систему как у ТС в принципе применить можно (но не нужно :) )
Ни о каких сложных группировках речи идти не может в таком случае .

v8: СКД. Миллион строк в отчете. Как выводить?

+(134) и самый прикол в том что отчетом реально пользовались..

пришла аудиторская проверка - потребовала отчет по нужным оборотам.. и получила его :)

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

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

(135) епт, о_0 походу, чтобы распечатать его пришлось бы небольшой лес вырубить...

(136) Ну важно, ты работоспособность запроса и сервака проверь?

+(136) Индексы помогают, но не всегда оптимизатор SQL их берёт там от кучи факторов зависит... Я спать ушед.

Ну так в (123) тебе подсказали , выноси 300 строковую в отдельный справочник , да и остальные можно , в основном только гуиды

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

(138) работают и формируют отчет с 2.5 млн. записей что еще проверить?

(0) предлагаю такую структуру

справочник с 3 индексироваными полями (те которые сейчас индексированые)
+
справочник ТипыПолей
+
регистр сведений, индексированые измемрения ссылкаНаСправочник и ТипПоля + индексированое поле ЗначениеРеквизита

уверяю - что работать будет на порядок быстрее

(142) и опять же от структуры базы зависит , если она нормализована хорошо то по чему бы и нет , а ТС одна строка несколько килобайт оперативки в запросе отжирает .
При построении запроса строго по индексным полям , памяти отожрется сколько строк на выходе запроса будет

(144) ээээ 8ка, план счетов... запрос по вирт. таблице остатков...

это типа хорошо нормализированная база или как?

(0) Предлагаю создать SP, да и запустить её. Данные пусть на сервер же выкинет, куда-нибудь во времененую таблицу. Оттуда их забрать.

(143) звучит разумно, завтра попробую...
(146) Ну опять таки эта sp вынесет мне всю память с сервака. А как к временной таблице скуля из 1С обратиться?

У меня честно говоря такая плоская таблица используется для ведения расширенной системы логирования , с выходом на что то приближенное к аудиторскому следу . За цикл до свертки накапливается 2.5 миллиона записей примерно (строковых полей по 300 символов нет , всего полей 19 ,пара по 150 , по нескольким строится индекс) , но когда проектировал эту систему точно знал что выборке максимум пара тысяч строк будет и очень редко , как правило несколько десятков
(145) Хорошо , была бы плохо нормализованная у тебя на 1.6 миллиона строк не 600 мегов оперативы ушло а в десять раз больше . На субконто счетов ведь строго говря пишутся элементы справочника а не значения элементов справочника

2(147) если релиз 14, то например из СКД как внешний АДО-источник данных... Но я еще не пробовал.

МишаЛ. как обычно отжигает... вместо чтения букварей по скулю...

(149) 14-й релиз НЕтестовый уже вышел? обещали вроде до начала июля, 2-го числа смотрел - не было нифига

(151) вышел вышел.. все уже даже поставили его давным давно.. только ты проспал все веселье...

(147) Через com-объект ADO. На инфостарте есть примеры. Я в особо трудных случаях генерил таблицу на SQL(таблицу сеанса, через #), набивал данными из 1с, обрабатывал SP, данные кидал во вторую таблицу сеанса, забирал. Я не понимаю, как 6 млн записей могут убивать 8 гб сервер.

(152) надо обновиться тады. а где же гудеж с обсуждением новых фичЬ и ништяков?
(153) там много полей, некоторые содержат большие строки, потому и тяжелые такие...ну и на том же серваке еще одна база крутится, тесновато им было.

(154) а видимо нет косяков.. вот и молчат все в тряпочку... наслаждаются...

2(154) чувак.. ты чего:
v8: 8.2.14 Ошибки. Впечатления.

(156) да, чет я провтыкал, 557 постов блин : ) спс.

(0) имеется (на Оракле+софт, а не МССКЛ и 1С) OLTP система, в ней висят постоянно ~600 юзеров. Пару таблиц под миллиард записей, за 100млн больше десятка таблиц. Кое-где соединяются друг с другом и/или маппинги происходят 100млн таблиц друг на друга (правда идти могут по неск.часов, и используются технологии Oracle Streаms, Data Caption..). Дамп базы ~4Тб. Хранилище порядка 2900 таблиц включает. Работает!
( или почитай про Одноклассники/ВКонтакте )
Поля строковые тоже вовсю используются.

(153) Могут, но только в одном случае - если он их все в память тащит.

Пиндец, товарищи. С таким количеством полей с самого начала нужно было юзать механизм дополнительных характеристик. Выделять поля уникального ключа в справочник, идентификаторы остальных полей хранить в ПВХ, значения в РС. Отчеты бы на компоновке строились на раз-два. А так сервер СУБД потеет только от одной выборки нескольких строк - ради 3 полей в 3 строчках тащить 70 полей в тех же 3-х строчках. Диски горят, кэш рэйда забит, очередь стоит. А ведь еще небось и память кривыми запросами пожирается...

(160) Да нет, тут есть очень грамотный товарищ, который уверен что это 1С (или SQL?!) 6 миллионов записей вытянуть ну никак не может. Это очень большой спец в программировании и проектировании БД.

Я рекомендую гражданину МишельЛагранж с его постом (72) убиться головой о стену

http://alldba.ru/index.php?option=com_content&view=article&id=278:-microsoft-sql-server&catid=45:microsoft-sql-server&Itemid=119

МишельЛагранж еще тот кловун.

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