Базе два года. Всего работает 30 пользователей - фирма маленькая.
Но при этом размер растет на 200-300 Мб каждый день.

Общий размер на сегодня 170 Гб - это данные за два года. Из них 140 Гб занимают всего три таблицы!!!!

Привожу данные по этим таблицам:


Я не админ - поэтому прошу ткнуть носом, где искать косяк.
Или это нормальный размер и можно смириться с ним?

Это таблицы ценовых условий. Так что если у вас прейскурант на 100 000 позиций, который обновляется каждый день, то наверное ничего удивительного.

У нас 2000 позиций, из них активных 500-600.

Ну тогда у Вас всё хорошо, и эти таблицы очень даже не большие.
А если серьёзно, то разбирайтесь, таких размеров даже у больших
клиентов быть не должно. Или САП пинайте, если доступ есть

Я бы порекомендовал поговорить об этом с консультантом, который ведет сбытовой модуль. Уж он-то должен знать, кто и как создает новые ценовые условия.

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

Есть подозрение, что база такая огромная тоже из-за их самописных транзакций.

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

Посмотрите (обычным запросом к БД), под какими пользователями генерятся эти условия:
select count(*), ERNAM
from sapsr3.KONH
where ERDAT = to_char(sysdate-1,'yyyymmdd')
group by ERNAM

И еще - создаются ли документы изменений под эти условия? То, что в ТОП-3 Ваших таблиц не вошли CDHDR и CDPOS, заставляет думать, что не создают...

Как нетрудно догадаться, мне, как сотруднику компании "АБ Консалт" не очень приятно читать подобные сообщения. Мне кажется, если бы уважаемый Johnny вместо обращения на форум обратился бы к нашим консультантам, он бы получил больше полезной информации о том, как и почему настроена система.
Бизнес-требованием в данной системе был ежедневный полный пересчет прейскуранта по все позициям, в зависимости от курса валюты.
Так что рост данных таблиц закономерен. Также, во избежание еще большего роста базы, было отключено создание документов изменений.
Я совершенно не исключаю возможных ошибок наших специалистов, но, согласитесь, если есть необходимость их устранить, то продуктивнее общаться напрямую, а не лить грязь на форуме, тем более специальном.
А может, причина того, что вопросы задаются не нам напрямую, все же не низкая квалификация наших специалистов, а кое-что другое ?

С уважением,
Антон Бобров
системный администратор/консультант по базису
"АБ Консалт", Екатеринбург

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

Грязь никто на вас не льет, даже наоборот. Дикий рост базы - это всего лишь маленькое проявление непрофессионализма вашей фирмы.
Если есть желание, мы можем составить подробный полный отчет о вашем внедрении и выложить на форум.

Также можем написать о том, как ваша фирма "втюхала" нам SAP, который реально не нужен оптовой фирме, в которой работает в общей сложности 50 человек, из них только 30 за компьютерами.

господа - просьба не заниматься выяснением отношений в данном разделе форума.

Высказать все, что о друг друге думаете можете при личной встрече:) Екатеринбург не слишком большой город.

ЗЫ - спорный вопрос о нужности/ненужности SAP в небольших предприятиях. Я думаю бизнес ответит на него сам.

Что-то большие таблички.. Для 2000 позиций.
БД - Oracle?
тогда глянь размер табличек в GB:

select s.segment_type, s.segment_name, sum(bytes/1024/1024/1024) from dba_segments s where s.owner = 'SAPUSR' group by s.segment_type, s.segment_name order by 3 desc


потом select count(*) from KONP;

select count(*) from KONH;

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

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

Немного выяснили ситуацию.
Каждый день до сих пор генерятся цены в евро и рублях по каждому из 8 заводов (в нашем случае филиалов) по всем 2000 позициям.
Причем цены в евро не меняются совсем и не менялись никогда - их правят только вручную - зачем они генерятся, я не знаю.

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

MS SQL

если проблема не разрешилась, скиньте контакт на sap_02@rambler.ru. Помогу