Бывало всплывало за последний месяц, до этого работало всё нормально. Помогало пересчёт заново.
Не считает это куб и еще один - который это же, но скопирован месяца 3 назад и скорее всего добавлено пару переменных.
Служба запущена от имени администратора. Разрешения все на папку есть.
Как вариант, перезаписать SQL срипт на стандартный, взять из токлько установленного справочника. Еще есть вариант через апдейты, но я не помню как именно вернуть значения кубов.
В данном отчет скрип стандартный. Он никем не переписан. Апдейты - только если на версию 7,5,3 (чего не хотелось бы), т.к. из 7,5,2 это самый новый.
Служба - понятно. Менеджерскую запустите от имени администратора и попробуйте вручную пересчитать куб.Сообщение от VINNI87
фильтр по дате пересчета пробовали меньше сделать?
Попробуйте за последний день выбрать - если повторится ошибка, наоборот, исключите этот день. Если ошибка пропадет - скорее всего, проблема в самой смене. Тогда перезакачайте ее и проверьте еще раз.
Запустил от имени администратора дектопно - без разницы. Поставил в фильтре и 1 день, и только одно 4 января, одно и тоже.
Похоже не хватает памяти. На чем сервер отчетов крутится? сколько ОЗУ? Файл подкачки? Такое бывает, когда данные вырастают. А куб по расходу - это самый большой куб, всеобъемлющий тксказать..
Под рукой версии 7.5.2 нет, вот скрин с 7.5.3. Данных больше года, считается без проблем, но правда долго.
1.PNG
Так же, статья с просторов UCS по оптимизации пересчета кубов:
RKeeper 7: Оптимизация пересчета кубов
1. Периоды анализа данных кубов
Как правило, период анализа данных кубов и отчетов представляет из себя:
1.1. Короткий период (ежедневные/еженедельные/ежемесячные): скорость вычисления таких кубов необходимо сокращать за счет наложения фильтра на период обрабатываемых данных.
1.2. Фиксированный прошедший период (прошлый год/квартал/месяц, все данные до какой-либо даты): такие кубы можно вычислить один раз (при каждой смене периода его, конечно, надо вычислить заново).
2. Правила оптимизации
Ниже перечислены несколько правил, позволяющих оптимизировать вычисление кубов:
2.1. Проанализируйте частоту использования Ваших Кубов и соответствующих отчетов: если некоторые кубы и отчеты используются лишь для просмотра/печати отчетов в конце месяца/недели другого периода - выставьте им соответствующую периодичность пересчета. В случае эпизодического использования - выставьте "По Запросу", в случае, если куб и его отчеты не используется совсем - отключите его пересчет, установив периодичность в "Никогда".
2.2. В случае, если смены закрываются не одновременно, посмотрите, указан ли час пересчета в каждом кубе, укажите время, например, ночное, когда никто не использует сервер и не идет закрытий смен. Если имеется разброс между временами закрытия смен, (например, на одном сервере смена закрывается в 18.00, а на другом - в 20.00) - либо не устанавливайте периодичность "По Закрытию Смены", либо установите соответствующее значение свойства "Интервал Ожидания Данных" у элемента Сервер Отчетов (в описанном случае следует использовать значение 02:30 - т. е. ожидать данных в течение двух с половиной часов, а лишь затем начать пересчитывать кубы). Это позволит избежать двойного пересчета кубов.
2.3. Если у Вас есть необходимость смотреть кубы за конкретный период, а предыдущие периоды просматриваются редко, рекомендуется установить фильтр на интересующую Вас дату для ускорения процесса пересчета. Например, для просмотра кубов с марта 2010 года установите следующий фильтр: 01.03.2010 - 31.12.2100. В случае, если Вас интересуют лишь отчеты за один день (например, просмотр ежедневных отчетов в течение месяца) так же имеет смысл выбора фильтра на короткий период, например, месяц (в вышеописанном примере - текущий месяц).
2.4. В случае, если это допустимо, можно создать новую базу (например, в начале нового года), а данные за прошлые года оставить в старой БД, используя для доступа к ним отдельный Сервер Отчетов.
2.5. В случае, если это допустимо, можно удалить данные за прошлые периоды из накопительной БД: либо воспользовавшись справочником Общие Смены, либо физически удалив данные из БД (SQL или check.udb) и закачав интересующие смены вручную (скопировав их в каталог incoming на Сервере Справочников).
2.6. В случае использования БД SQL существует способ получения отчетов напрямую из БД (без построения и последующего использования куба) при помощи SQL запроса: это позволяет запрашивать лишь действительно необходимые данные, с учетом фильтров на даты и прочие условия. Для создания подобного отчета следует в форме создания отчета в поле Report Source выбрать "SQL Query". Далее при помощи редактора FastReport 4 следует изменить макет либо сохранить автоматически сгенерированный. Для доступа к данным отчета используется такой же механизм, как и ранее: меню в главной форме либо пункт во всплывающем меню при клике на отчете в справочнике OLAPi Кубы и Отчеты.
2.7. Кубы, вычисление которых занимает длительное время, имеет смысл проанализировать подробнее: выяснить, какие поля используются в отчетах, неиспользуемые поля следует удалить из структуры куба. Если куб является предустановленным, рекомендуется выставить ему периодичность "Никогда", создать его копию и в ней уже удалить неиспользуемые поля. Если используется много кубов в одной схеме, имеет смысл проанализировать возможность "склеивания" кубов в меньшее количество, но с бОльшим количеством полей, таким образом уменьшив общее число кубов, подлежащих вычислению.
2.8. Если планируется анализ "закрытого" периода (с заданными датами начала и окончания), и данный интервал находится в прошлом (например, весь прошлый год) - периодичность такого куба следует выставить в "Никогда". Запустить процесс вычисления такого куба можно, вызвав из всплывающего меню пункт "Пересчитать".
Xeon и 24 гига. Сегодня ночью попробую отключить все стор хаусы. Но в запущенном состоянии и во время простоя показывает что занято только 8,8 гигов оперативы.
База дорасла до 25 гигов
Server 2008 x64? Терминальный?
Сервер отчетов там один? или несколько?
25 ГБ это очень много, попробуйте считать куб по блюдам отдельно от общего пересчета, в часы минимальной нагрузки на сервер. И поставьте фильтр пересчета.
2008r2 x64, sql 2008 r2. База распухла в 2 раза после перехода на 7,5,2 - спасибо ИА отчетам. Куб пробую считать отдельно - лучше не становится. Запускаю вручную.
---------- Добавлено в 14:01 ---------- Предыдущее сообщение было размещено в 13:34 ----------
Посчитал. При позиции "фильтровать данные" не работает. Быстрее выбивает ту же ошибку. При позиции "фильтровать и добавлять данные" считает нормально.
Безымянный1.jpgВот что выдает отчет, который был скопирован пол года назад из этого.
Ваши права
VINNI87 
