периферийная база 70, центр 50 это нормально?

разработчик г_о_в_н_о_базы на все вопросы говорит что админы филиала тупые, сам же однако не рвется всё настроить так чтобы всё летало

в периферийке регистры незакрыты, так часто бывает в РИБ (зачеркнуто) УРБД

(15)и что делать?

Судя по нику ты программированием в этом году начал заниматься?-)

(17)я не обсуждаю действия модераторов )))

(16) Закрывать, вестимо

(17)и я так понял что все кто в прошлом начал знают что делать? )))

(19)как?

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

(22)ну допустим схема миграции есть, и что дальше?

(20) ага, раньше читали жкк, а только потом "накладывали хотелки". А сейчас сначала накладывают хотелки, а потом накладывают кучу, когда базе попа-)

(23) Озвучь.

(0) банально,основной поток данных генерится в ПБ и в ЦБ уходит не все, а только то что нужно

(23) Интересуют в основном только те документы, которые как в (7). Т.е те которые остаются только в ПБ

(24)спокойно... ))) база не моя. я из неё внедряю УПП.
(27)разработчик утверждает что в центральном узле всё.
справочники и документы там точно все, а вот то что в регистрах "рассогласование по набору измерений " это я сразу заметил

(27)утверждают что мигрирует всё

(27)есть подозрение что цу просто почистили, а филиалы нет

(17) Он еще не начал. Только планирует начать...

(30) Есть подозрение, что кому-то почистили черепную коробку...

(32)ну вы то с полной черепной коробкой как можете объяснить сабж?
админы подтвердили разницу в размере, ошибки по недоразумению нет.
расзработчик сообщает что проблемы обмена обусловлены кривизной механизма урбд

(33) "кривизной механизма урбд" - самый "прямой" и простой механизм в 7-ке. Разработчик олень.

>спокойно... ))) база не моя. я из неё внедряю УПП.

жесть!

(35)да пофик, просто интесно было понять что происходит с гбазой

(36) Херня какая-то происходит. Сравни итоги по регистрам, универсальными отчетами.

(33) Уже все объяснили выше. Незакрытые регистры.
разработчик, похоже, сравним с вами...

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

(38)подскажите пожалуйста как можно закрыть регистр, если итоги адекватны?

(39) а кроме партий и остатков регистров нема?

(41)это основняк, остальное там ботва и мало

а какая таблица самая большая?

(42) документы сравни, за месяц, кол-во.

(43)
[dbo].[RG405]    28311829
[dbo].[RG4674]    27422361
[dbo].[RG328]    25360778
[dbo].[RA405]    20284778
[dbo].[_1SCRDOC]    15857481

к (45) это по пб

(45) что и требовалось доказать. А периодичность итогов одинаковая?

(45) не закрытые регистры

(48) может тамм за 15 лет с периодичностью "неделя"

еще в файлике .dd посмотри что за регистры это.

если одинаковая, тогда то, что ты про адекватные итоги писал - фигня

Похоже в периферийку грузятся приходы, которые не должны закрываться в пб

(49) а разве может быть разная периодичность в ЦБ и ПБ?

RG - это итоги, RA - движения

(53) а я не помню уже. но почему нет?

(50)это ТМЦ и Партии
(51)я это сам проверял на 1 мая 2012
(47)сейчас гляну

(55) не бывает такого

(56).2 фигово проверял. итоги должны быть закрыты по всем измерениям

схему миграции надо, выложи мд-шник куда-то.

(58)что фигово?
я запросил остатки скулем на первое мая по регистрам партии и тмц и через опенровсет зафигачил в восьмерку в оприходования, поотом провел их, потом сравнил специальным запросом через опенровсет партии с семеркой тмц - совпало, сравнил с цу - тоже совпало. т.е. оно работатет но как-то странно, а рассогласования по набору измерений там видны сразу при просмотре таблиц, но понять тупняк это или исторически сложилось (база 5 лет не сворачивалась) не могу, может есть "готовое решение" ))) ?

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

(60) ага, списать все по базе, сделать инвентаризацию, внести правильные остатки.

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

(62)и что записи в регистрах исчезнут?

(64) ну движения останутся, итоги - да -)

(65)если только перед этим регистры почистить...

up

(67) шо ап? все же разжевали уже

это все от того, что нетленная самописька

(69) Написанная в нетипичном самописьменном конфигураторе

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

>>>нужен алгоритм выхода из ситуации

если посла "разжевали" не видишь сам - приглашай специалиста....

(72)там кучи движений (в пб) которые вообще или мусорные или какие-то опорные данные странного движка базы, потому как не понятно что может означать движение с неуказанным складом, или NULL или id не существующего элемента, справочники складов в пб и цу идентичны, отчего и возникла мысль что цу почистили а на пб забили

(73) кривая миграция. Смотри сначала разницу по итогоам в ПБ и ЦБ, потом по какому-то конкретному товару движения в ПБ М ЦБ. Так ты найдешь документ или документы, которые не мигрируют куда надо. id не существующего элемента - случайно не в признаке партии?-)

Если файлы LDF отличаются, то не страшно. Если MDF - хуже

(74)"не поможет"©

(74)"id не существующего элемента - случайно не в признаке партии?-)"
в поле склад точно есть

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

шринк MDF делается и на перефирийки и на центральной?

(78) Тут до шринка еще куча всего... у него явно косяк в правилах миграции, оттуда - незакрытые регистры, оттуда в свою очередь тормоза...

(78)сравнение баз было скулем (мдф+лдф) после шринка обоих баз

я не понимаю чего автор за размер баз убивается, раз его задача перенести в УПП тока

(80) шринки разные бывают, ты точно уверен что шринк ФАЙЛА ДАННЫХ (а не лога) сделан?

ну и потом сравнивать лог вообще не имеет смысла, давай размеры мдф сразу после шринка

+(79) у меня в паре перифериек совершенно сознательно сделаны такие правила миграции, которые приводят к вышеупомянутым последствиям. И робот "чистит хвосты". Два месяца назад автозапуск робота убрали из шедулера. При открытии периода (второго по счнту без чистки) - "взрыв данных"... Было грустно ликвидировать это...

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

(79) с чего ты взял что аналитика не закрыта? размер RA может таким быть например если базе 10 лет и она ни разу не сворачивалсь...

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

(82)
USE [НашаГовБаза]
GO
DBCC SHRINKDATABASE(N'НашаГовБаза' )
GO

размеры в сабже, логи по что-то или 0 или 1 метр стали на тот момент

(83) у меня в снеговике при АО у "ненужных" движений активность снимается, но в 7.7 непонятно, как так сделать

(84) вы друг друга стОите...

(87) хирургией. В силу простоты модели клюшек - это несложно...
а вот сейчас прогеры думают, как реализовать _все_ сделанное - на снеговике. упираются в "ограничения платформы" :-))

(86) бекап базы был перед этим ?

(88)не думаю. просто я как бы специализируюсь на другом.

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

DECLARE @Database VARCHAR(255)  
DECLARE @Table VARCHAR(255)  
DECLARE cmd NVARCHAR(500)  
DECLARE @fillfactor INT

SET @fillfactor = 90

DECLARE DatabaseCursor CURSOR FOR  
SELECT name FROM MASTER.dbo.sysdatabases  
WHERE name NOT IN ('master','msdb','tempdb','model','distribution')  
ORDER BY 1  

OPEN DatabaseCursor  

FETCH NEXT FROM DatabaseCursor INTO @Database  
WHILE @@FETCH_STATUS = 0  
BEGIN  

  SET cmd = 'DECLARE TableCursor CURSOR FOR SELECT ''['' + table_catalog + ''].['' + table_schema + ''].['' +
 table_name + '']'' as tableName FROM ' + @Database + '.INFORMATION_SCHEMA.TABLES
 WHERE table_type = ''BASE TABLE'''  

  -- create table cursor  
  EXEC (cmd)  
  OPEN TableCursor  

  FETCH NEXT FROM TableCursor INTO @Table  
  WHILE @@FETCH_STATUS = 0  
  BEGIN  
      DBCC DBREINDEX(@Table,' ',@fillfactor)  
      FETCH NEXT FROM TableCursor INTO @Table  
  END  

  CLOSE TableCursor  
  DEALLOCATE TableCursor  

  FETCH NEXT FROM DatabaseCursor INTO @Database  
END  
CLOSE DatabaseCursor  
DEALLOCATE DatabaseCursor

и прирост размера это индексы

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

(89) ты табстрип подебил?

(90)всё описанное делается на копиях пока разработчик ведет себя по принципу или будет так как я хочу или я увольняюсь

(93) при чем тут копии?

перед шринком был бекап ?
модель восстановления базы какая ?

(95)простая, как часто делаются бэкапы не знаю, я все эти замеры делал на копиях баз (не на рабочих)

т.е. если будет ПБ = Центр = Х гб то тормоза автоматом уйдут? )

(97) Рискну предположить, что они будут примерно одинаковые

(96) ты бекап востанавливал наверно в не пустую базу?

1. могли остатся мусорные таблицы
2. сделай SHRINKFILE вместо SHRINKDATABASE разница есть http://www.askit.ru/custom/sql2005_admin/m4/04_09_02_db_shrinking.htm

(92) подибил... В классе метод определен неверно был...
так что почти сделал.

(100) я те там кинул мини пример в той ветке..

(99)процесс идет

USE [ГБ]
GO
DBCC SHRINKFILE (N'ГБ')
GO

(101)что за ветка?

(102) мы о своем...

к (102)
стало:
58 218 + 1 626
было:
76,3 ГБ

(104) Чего и следовало ожидать... (а еще могут быть мусорные таблицы....)

теперь давай переформулируй САБЖ и переозвучивай проблеммы

(105)ну если у тебя есть модераторские права можешь переименовать )

к (106) я пока ещё не осмыслил происходящее но ясно одно - записей с несуществующим или не не указанным складом быть не должно.

(107) записи то хоть где ? В итогах ? В движухе ?
В какой табличке смотришь и что именно ?

(108)итоги по регистру партий, или тмц или то и другое, если нужно могу уточнить

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

(110)да тут она ещё связана с самопиской на акцессе по обмену с терминалами, наверное нет возможности новую делать,

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

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

периодичность хранения остатков месяц