[ОТВЕТИТЬ]
28.11.2007 05:19
avl2007
 
Может кто уже знает запрос или запросы в ОРАКЛ, которым выполняется проверка перед расчетом товародвижения?
"База данных не может выть заблокирована".

Хочется до запуска td_a.exe проверить и что-нибудь предпринять, например сессии пользователей пострелять, может что-то еще почистить... Или даже вообще td.exe не запускать.
28.11.2007 07:30
stalker
 
Цитата:
avl2007 Может кто уже знает запрос или запросы в ОРАКЛ, которым выполняется проверка перед расчетом товародвижения?
"База данных не может выть заблокирована".

Хочется до запуска td_a.exe проверить и что-нибудь предпринять, например сессии пользователей пострелять, может что-то еще почистить... Или даже вообще td.exe не запускать.
а что мешает просто базу перезапустить перед td ?
28.11.2007 10:41
kadr
 
Цитата:
stalker а что мешает просто базу перезапустить перед td ?

То что очистится SQL Area и при начале работы будет затрачиваться много ресурсов на новый разбор sql-предложений
28.11.2007 11:44
avl2007
 
Неправильно это - ОРАКЛ каждый день дергать. Только он, родной, все правильно в кэше разложил, шаред пул настроил как надо и пр. А тут его - рестарт! Да и бакап надо горячий делать, т.е. снимать полный дамп, заодно и результат его становится известен. В общем, хочется без остановки оракла обойтись.
28.11.2007 11:54
avl2007
 
Благодарю, inna! вполне подходит этот селект
28.11.2007 11:57
avl2007
 
И еще, можно ли td.exe научить не делать рестарт сервисов супермага? Или я чего-то не понимаю?
28.11.2007 12:08
OlegON
 
Цитата:
avl2007 И еще, можно ли td.exe научить не делать рестарт сервисов супермага? Или я чего-то не понимаю?
По td есть раздел "Мои программы", рестартовать сервисы надо, чтобы не лочили базу, никаких проблем это не вызывает, если уж очень хочется - можно запускать его на другой машине, он тогда не сможет остановить сервисы (впрочем перенос тогда, наверное, упадет). Он останавливает только сервисы СМ, а не базы. Дамп для бекапа я бы снимал только на очень "тихой" и маленькой базе, иначе никакие consistent=y не помогут, для других целей я бы использовал (и использую) RMAN. Что касается перезапуска сервиса базы, то ничего страшного в ней нет, от лишних подключений и пр. застрявших вещей это избавляет, все кеши от расчета до расчета в себе будут хранить кучу нужных для ежедневной работы, а не расчета ТД данных, так что то, что они опустошатся, скорее всего только в плюс системе. Более того, я винду бы все таки почаще ребутил.
Сам использую Linux, базу практически не перезапускаю, ТД считаю каждый день.
28.11.2007 13:04
avl2007
 
2003 сервер вполне устойчивая система и перегружать часто нет необходимости. Consistent=y для "бурной" и большой базы зависит только от размера undo, и еще там параметр есть, по которому schrink роллбэк сегментов происходит - у него умолчание 3 часа, так его просто увеличить надо. А rman - это правильно, дампы - это временное решение, вот только перевод на 9-ку закончу и сделаю обязательно. Archivelog, incremental level 0 - еженедельно, 1 - каждый день - ну, как учили. Вот только сервис супермага при рестарте в момент расчета товародвижения зависает с периодичностью 1 раз в 10 дней. Возможно накат СП2 на виндоуз поможет...
Да залоченные сессии юзеров в оракле "убить" достаточно или надо эту табличку SSLOCKS тоже почистить?
28.11.2007 13:26
OlegON
 
Цитата:
avl2007 2003 сервер вполне устойчивая система и перегружать часто нет необходимости.
Я использую винду уже много лет и тоже поклонник этой системы. Однако настаиваю, что в наших условиях, когда на ней крутятся вещи вроде Сервера СМ или, упаси, почтовик, хотя бы раз в неделю ее нужно перегружать.
Цитата:
avl2007 Вот только сервис супермага при рестарте в момент расчета товародвижения зависает с периодичностью 1 раз в 10 дней.
Не встречал ни разу. Только через mmc повисал, сервис - ни разу.
Цитата:
avl2007 Да залоченные сессии юзеров в оракле "убить" достаточно или надо эту табличку SSLOCKS тоже почистить?
По хорошему, убитые сессии чистят sslocks, но таблицу бы почистить, только не грохни сессию самого Супермаг-сервера.
28.11.2007 13:34
inna
 
У меня после того, как настроила почтовики на файловый обмен, на тех магазинах где связь не очень почтовики стали подвисать и не останавливаться по команде. В этом случае TD действительно не может заблокировать базу. Может можно и в серевере лицензий тоже что то так настроить, что он не будет стопиться?
29.11.2007 14:10
avl2007
 
Спросить хочу:
Насколько актуален вот этот скрипт переноса без участия клиентской части СМ?

declare
p pls_integer;
begin
p := supermag.core.startsmapp;
Core.LockObject('1','DB','1');
SMRunTransfer( sysdate, sysdate);
Core.LockObject('0','DB','1');
commit;
end;

Только он требует полной блокировки.

Сегодня попробовал на работающем магазине, вроде все гладко прошло, но что-то опасаюсь...
06.12.2007 19:39
deucel
 
Цитата:
avl2007 declare
p pls_integer;
begin
p := supermag.core.startsmapp;
Core.LockObject('1','DB','1');
SMRunTransfer( sysdate, sysdate);
Core.LockObject('0','DB','1');
commit;
end;
Тоже самое делает и СМ.
07.12.2007 13:55
isi
 
Интересно, а если блокировку базы убрать перед переносом, как это будет работать? Ни кто не пробовал? Можно ведь подвинуть даду запрета редактирования документов и тогда точно ничего в БД не проскочит, так можно избавится от полной блокировки БД, сейчас нет под рукой тестовой БД, но у кого есть, попробуйте
10.12.2007 03:07
isi
 
Я про блокировку при переносе, а не при расчете. Разницу улавливаешь?
Смысл -> уйти от полной блокировки БД. Так проверит кто нить или нет?
10.12.2007 07:12
Mtirt
 
Так Олег там тоже писал о ПЕРЕНОСЕ. Расчет и так идет при работающих пользователях...
10.12.2007 08:50
kadr
 
Цитата:
isi Я про блокировку при переносе, а не при расчете. Разницу улавливаешь?
Смысл -> уйти от полной блокировки БД. Так проверит кто нить или нет?
А что тут проверять-то? блокировка сделана для гарнтии того что в момент переноса не будут изменяться документы. Если ты сможешь гарантировано обеспечить неизменяемость документов, которые переносятся, то почему бы и нет, но гарантировать неизменяемость документов можно только не пустив пользователей в БД, т.к. даже простановка оснований, из периода для переноса, в расходных накладных может кардинально изменить всю картину товародаижения
11.12.2007 02:51
isi
 
Цитата:
kadr А что тут проверять-то? блокировка сделана для гарнтии того что в момент переноса не будут изменяться документы. Если ты сможешь гарантировано обеспечить неизменяемость документов, которые переносятся, то почему бы и нет, но гарантировать неизменяемость документов можно только не пустив пользователей в БД, т.к. даже простановка оснований, из периода для переноса, в расходных накладных может кардинально изменить
проверял?
Цитата:
kadr всю картину товародаижения
Вот и просил проверить работает перенос без блокровки БД или нет, а каким способом я обеспечу себе неизменность документов, это не важно, можно тупо в smlocks запись создать о том что работает почтовик и он сам отвалится, потом удалив её, сам подключится + дата запрета может помочь, каков процент возможно изменившихся документов за 30 минут переноса? В размере сети магазинов с оборотом сотни миллионов в месяц разброс в несколько тысяч не важен для аналитический отчетов.
Да и на сколько я понимаю перенос делается именно на указанную дату, так что даже простановка оснований я думаю много не изменит. (если конечно не стоит галка по расчету не определенной себестоимости по будущим периодам)

Все эти манипуляции позволят обеспечить нормальную автономность переноса и расчета себестоимости.


Да и ещё хотел сказать по поводу форума (прошу прощения за оффтоп). Последнее время либо без основательные споры на 10 страниц, либо ганение новеньких. Повторяется история SQL.RU (кто пробовал задавать впоросы там лет 5 назад и сейчас меня поймет). Вам не кажеться что данный форум призван помогать и делиться опытом? Что было проще проверить (у кого есть возможность) мою мысль? Я больше не о чем не просил.
11.12.2007 07:49
OlegON
 
Перенос работает и при работающих пользователях, со всеми нюансами, о которых говорилось выше. Проверял. По поводу оффтопа предлагаю перейти в другой раздел.
11.12.2007 07:55
Mtirt
 
Прошу прощения, если кого-то обидела.
Что касается переноса без блокировки.
Непросто всё это проверить, и вот почему: очень сложно понять, какие изменения нужно производить во время тестового переноса, чтобы четко уяснить, что можно делать в дальнейшем, а что - нельзя. Может быть тебе будет проще самому сформулировать необходимые условия, и проделать всё это на тестовой базе?

Еще пара комментариев по написанному выше.
Цитата:
Можно ведь подвинуть даду запрета редактирования документов и тогда точно ничего в БД не проскочит, так можно избавится от полной блокировки БД, сейчас нет под рукой тестовой БД, но у кого есть, попробуйте
Если имеется ввиду дата запрета редактирования в адм.модуле, то следует иметь ввиду, что, при установке этой даты, документы из закрытого периода принимаются почтовым сервером, в истории документов ставится пометка "Документ принят в закрытом периоде". Так что полностью застраховаться от изменений базы в данном случае не удастся.

Цитата:
В размере сети магазинов с оборотом сотни миллионов в месяц разброс в несколько тысяч не важен для аналитический отчетов
Не знаю как у других, но у меня данные бух.учета строятся на аналитических таблицах СМ2000. И разброс в несколько тысяч для меня губителен с этой точки зрения.
Если я применяю схему, когда я в течении месяца я делаю перенос без блокировок, а в конце месяца - с блокировкой, то данные расхождения останутся, так как расчет товародвижения оставляет уже привязанные основания. Остается вариант полностью очищать таблицы расчета товародвижения для бухгалтерских остатков. Но тогда, лично у меня, перенос будет идти очень долго... Что тоже не хорошо.
11.12.2007 09:32
isi
 
Цитата:
Mtirt Если имеется ввиду дата запрета редактирования в адм.модуле, то следует иметь ввиду, что, при установке этой даты, документы из закрытого периода принимаются почтовым сервером, в истории документов ставится пометка "Документ принят в закрытом периоде". Так что полностью застраховаться от изменений базы в данном случае не удастся.
Для этого можно "отшить" почтовик способом, описанным в пердыдущем моем посте

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


Часовой пояс GMT +3, время: 10:50.

 

Форум сделан на основе vBulletin®
Copyright ©2000 - 2018, Jelsoft Enterprises Ltd. Перевод: zCarot и OlegON
В случае заимствования информации гипертекстовая индексируемая ссылка на Форум обязательна.