Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Oracle Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 2 3 [4] 5 6 7   вперед  Ctrl      все
 Re: Нужен совет по архитектуре базы!  [new]
Падонак
Member [заблокирован]

Откуда: из лесу
Сообщений: 1775
contr
Падонак
как только объемы подрастут,
то один бух начнет проводить что-то массивное,
у другого будет "заблокировано", или "ждите завершения транзакции"
начнутся звонки

Если бы этим проблемы ограничивались, все было бы просто шоколадно :)
Например, схема "не DBA" подразумевает автокоммит.


признаться, не уловил
можно поподробнее?


Я эта, че хотел сказать,
что блокировать таблицу не хорошо, и лучше этого не делать, т.к. _практика показывает_, что это жопа
эту жопу можно лехко увидеть в программе 1С предприятие


А согласен с "не DBA" в том, что некоторые товарищщи любят в догму упереться, и всё им как об стену горох, "а вот меня так учили"


Если "не DBA" таблицу блокирует, и у него все работает, и проблем не возникает, да ради б-га,
пусть хоть пицот таблиц блокирует

В блокировочных СУБД люди работают и ниче вроде, живут :)
28 июл 06, 04:00    [2935891]     Ответить | Цитировать Сообщить модератору
 Re: Нужен совет по архитектуре базы!  [new]
Вячеслав Любомудров
Member

Откуда: Владивосток
Сообщений: 18482
Я думаю, contr больше упирает на то, что "у тебя работает, флаг тебе в руки, но не надо других учить плохому"
28 июл 06, 04:07    [2935892]     Ответить | Цитировать Сообщить модератору
 Re: Нужен совет по архитектуре базы!  [new]
Падонак
Member [заблокирован]

Откуда: из лесу
Сообщений: 1775
с этим я, безусловно, согласен

переезжаю в Москву.
ищу работу.
28 июл 06, 04:07    [2935894]     Ответить | Цитировать Сообщить модератору
 Re: Нужен совет по архитектуре базы!  [new]
Ааз
Member

Откуда: Москва/Протвино
Сообщений: 4274
Падонак
В блокировочных СУБД люди работают и ниче вроде, живут :)
Ну ясень пень! Не интересно челу заниматься БД. Ему интересно "кешировать". Самому, панимаешЪ, изобретать велосипедов. А база должна быть как простое файло. Положил, забрал. Ежели СУБД умна черезчур - берем кувалдометр (aka LOCK TABLE) и превращаем ее простой и понятный девайс. А то развелось тут теоретиков пальцегнутых и тупых догматиков :-). Низьзя да низьзя. Я, мол, пользую и чё? Пипл хавает... :-)

Всего
28 июл 06, 04:14    [2935896]     Ответить | Цитировать Сообщить модератору
 Re: Нужен совет по архитектуре базы!  [new]
contr
Member

Откуда:
Сообщений: 1909
Падонак
contr
Падонак
как только объемы подрастут,
то один бух начнет проводить что-то массивное,
у другого будет "заблокировано", или "ждите завершения транзакции"
начнутся звонки

Если бы этим проблемы ограничивались, все было бы просто шоколадно :)
Например, схема "не DBA" подразумевает автокоммит.
признаться, не уловил
можно поподробнее?
Предложите механизм проведения документа за "доли секунды" с освобождением эксклюзивной табличной блокировки без автокоммита :)
Падонак
_практика показывает_, что это жопа
Мне импонирует Ваш лаконичный, но ёмкий стиль :)
Падонак
А согласен с "не DBA" в том, что некоторые товарищщи любят в догму упереться, и всё им как об стену горох, "а вот меня так учили"
Конкретнее пожалуйста.
Догма - вешь необсуждаемая. А мы вроде как пытались обсуждать.
И даже заходить с разных сторон. К сожалению, уважаемый оппонент реагировал повторяя одни и те же заклинания, что лишило обсуждение смысла.
Падонак
Если "не DBA" таблицу блокирует, и у него все работает, и проблем не возникает, да ради б-га, пусть хоть пицот таблиц блокирует

Лично я в сказки давно не верю... Вспомните хотя бы 1С предприятие :)
28 июл 06, 04:15    [2935897]     Ответить | Цитировать Сообщить модератору
 Re: Нужен совет по архитектуре базы!  [new]
contr
Member

Откуда:
Сообщений: 1909
Ааз

Ааз, ICQ 11420*** - не работает?
28 июл 06, 04:19    [2935899]     Ответить | Цитировать Сообщить модератору
 Re: Нужен совет по архитектуре базы!  [new]
Падонак
Member [заблокирован]

Откуда: из лесу
Сообщений: 1775
contr
Падонак
А согласен с "не DBA" в том, что некоторые товарищщи любят в догму упереться, и всё им как об стену горох, "а вот меня так учили"
Конкретнее пожалуйста.
Догма - вешь необсуждаемая. А мы вроде как пытались обсуждать.
И даже заходить с разных сторон. К сожалению, уважаемый оппонент реагировал повторяя одни и те же заклинания, что лишило обсуждение смысла.


Конкретику я умышленно вкладывать не хотел.

Догматики чаще вредят больше, чем те, кто может предложить приемлемое решение, которое может идти в разрез с общепринятой догмой.
28 июл 06, 04:33    [2935901]     Ответить | Цитировать Сообщить модератору
 Re: Нужен совет по архитектуре базы!  [new]
Sergey M
Member

Откуда: г. Барнаул
Сообщений: 5462
не DBA

...
Модифицируйте пример с FOR UPDATE блокировкой для правки документа, который эту историю перестраивает. Сравните с кодом с TABLE LOCK. Раза в два больше кода - раза в полтора дороже разработка. А веть это самый простейший, буквально детский пример.
...

Грамотеи блинЪ..

Издеваетесь, над нами, наверное
Да пусть его хоть километры будут, этого кода.
Кстати, не будет его в два раза больше, если разрабатывать и реализовывать по нормальному а не по индусски..


не DBA

Поскольку у него складской учет, видимо одна из следующих задач - будет кеширование резервов и, возможно долгов. Еще, возможно, учет по партиям с новым кешем. А код все растет и растет, начинают лезть баги по кешам, в которых забыл/неправильно проставил блокировку.

Так и не надо кешировать все подряд и не прийдется баги в кэшах ловить

не DBA

Но зачем "платить дважды" и тратить на все это вдаое-втрое больше времени если результат (веорятнее всего, зависит от конкретной предметной области), если производительность систем TABLE LOCK и FOR UPDATE будет одинакова в условиях данного конкретного заказчика? Пресловутая "масштабируемость" этих денег не стоит...

Oracle хорош именно тем что он предназначен в общем то именно для масштабируемых систем

Если заказчик готов выложить кучу килобаксов за лицензионный оракл и железо для него не думаю что ему нужна система для двух клерков, скорее как раз масштабируемость ему и нужна. Иначе бы заказал программу на Визуал фоксе или на access
28 июл 06, 07:55    [2936029]     Ответить | Цитировать Сообщить модератору
 Re: Нужен совет по архитектуре базы!  [new]
Падонак
Member [заблокирован]

Откуда: из лесу
Сообщений: 1775
кто-нибудь объясинт, что в данной теме означает термин "кэширование"?


переезжаю в Москву.
ищу работу.
28 июл 06, 08:20    [2936112]     Ответить | Цитировать Сообщить модератору
 Re: Нужен совет по архитектуре базы!  [new]
Sergey M
Member

Откуда: г. Барнаул
Сообщений: 5462
Я всегда думал что кэш - это нечто, время доступа к которому минимально и куда ложатся некоторые предварительно вычисленные или извлеченные данные, которые могут с высокой вероятностью понадобиться в ближайшее время дабы за ними долго и далеко не лазить и / или не вычислять на лету.
28 июл 06, 08:45    [2936173]     Ответить | Цитировать Сообщить модератору
 Re: Нужен совет по архитектуре базы!  [new]
Падонак
Member [заблокирован]

Откуда: из лесу
Сообщений: 1775
тебе необходимо сузить сознание :)

много кто употребляет термин кэширование в данной теме, но я не уверен, что все говорят об одном и том же

Конкретно под "кэшированием остатков" можно подразумевать с десяток разных вещей,
начиная от размещения этих остатков в keep,
заканчивая временными, или pl/sql таблицами


переезжаю в Москву.
ищу работу.
28 июл 06, 08:53    [2936192]     Ответить | Цитировать Сообщить модератору
 Re: Нужен совет по архитектуре базы!  [new]
не DBA
Member

Откуда: Москва
Сообщений: 77
Sergey M
Я всегда думал что кэш - это нечто, время доступа к которому минимально и куда ложатся некоторые предварительно вычисленные или извлеченные данные, которые могут с высокой вероятностью понадобиться в ближайшее время дабы за ними долго и далеко не лазить и / или не вычислять на лету.
именно. На первой странице этой ветки - пример простейшего кеша.
28 июл 06, 09:05    [2936252]     Ответить | Цитировать Сообщить модератору
 Re: Нужен совет по архитектуре базы!  [new]
Ааз
Member

Откуда: Москва/Протвино
Сообщений: 4274
contr
Ааз, ICQ 11420*** - не работает?
Работает, но иногда. Обычно, когда я в офисе...

Всего
28 июл 06, 10:38    [2936742]     Ответить | Цитировать Сообщить модератору
 Re: Нужен совет по архитектуре базы!  [new]
не DBA
Member

Откуда: Москва
Сообщений: 77
Падонак
то один бух начнет проводить что-то массивное,
у другого будет "заблокировано", или "ждите завершения транзакции"
начнутся звонки
Табличные блокировки предлагались мной при проведении первичных документов. Они по определению "массироваными" не бывают - транзакция идет доли секунды, оценка сверху - секунда, я же не на форме блокирую таблицу а на сервере, в методе вызваном нажатием кнопочи save. Проблемы могут начаться если сотня "бухов" начнёт активно плодить документы. Но на это система и не расчитывается изначально.

Далее, если второй бух случайно напоролся на транзакцию первого, заблокировавшего таблицу, никаких "заблокировано" ему не посыпится - его транзакция просто подвиснет на строчке lock table и будет ждать до commit транзакции первого буха. Если время выполнения транзакции доли секунды никто ничего никогда не заметит, и никаких звонков не будет даже если вдруг случайно 10 клерков нажали save в одну и ту же долю секунды.

Ну а если Вы говорите о транзакциях которые выполняются минуты и десятки минут и лопатят кучу данных - это отдельный вопрос...1) А построчное блокирование в этом случае не даст ли тот же результат что и табличное? 2) Насколько такие операции собираются быть штатными и частыми?
28 июл 06, 10:40    [2936759]     Ответить | Цитировать Сообщить модератору
 Re: Нужен совет по архитектуре базы!  [new]
Падонак
Member [заблокирован]

Откуда: из лесу
Сообщений: 1775
1.
>> при проведении первичных документов. Они по определению "массироваными" не бывают

дурак ты :)

2. подвисание сесии еще хуже, чем "заблокировано"

3. перепроведение всех документов за период еще бывает

переезжаю в Москву.
ищу работу.
28 июл 06, 10:49    [2936816]     Ответить | Цитировать Сообщить модератору
 Re: Нужен совет по архитектуре базы!  [new]
Маньяк
Member

Откуда: оттуда
Сообщений: 287
Bely
Маньяк
а что касается фиксации остатков, то может быть просто вешать какой-нить джоб, чтобы в полночь пересчитывались остатки и создавалась таблица, но тогда допустим в пересчитанный период никого не пущать вносить изменения,
ну т.е. закрыли месяц и все тут

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

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

То что поставили в очередь после пересчета остатков - будет обработано в следующий раз.

PS: при пересчете остатков - не забудь написать процедуру, которая будет исправлять первичные документы "далеко в истории".
Принял кто-нибудь год назад ошибочно на склад сотни две несуществующих ноутбуков, а заметили это только вчера.
И пойдет тогда закат солнца вручную... перерасчет всех остатков за все периоды...

Сложного в этом ничего нет, но учесть это стоит.


по поводу поставить в очередь не очень понял, можно подробнее
я планировал, что в какое-то время Х я запускаю некий скрипт (вернее на базе создаю джоб), который пересчитывает все остатки и на это время изменения в системе будут запрещены, т.е. будет select for update
естественно скрипт будет запускаться не в пиковое рабочее время

а что касается изменений задним числом, то это придумал делать так
если что-то изменили, то в таблице по этой товарной позиции на это количество по всем периодам изменить остаток - это и называется "закат солнца вручную" ?



основная проблема на сегодняшний день -это понять
28 июл 06, 10:57    [2936888]     Ответить | Цитировать Сообщить модератору
 Re: Нужен совет по архитектуре базы!  [new]
pamir
Member [скрыт]

Откуда:
Сообщений: 27433
Маньяк

по поводу поставить в очередь не очень понял, можно подробнее

Не знаю, что имел ввиду автор, но могу описать вариант решения, с которым сталкивался я.
Есть таблица остатков. При проведении очередного документа она должна модифицироваться.
1. Идет попытка заблокировать запись для соответствующего счета. Если блокировка удачна - без проблем модифицируем ее.
2. Если нет - время не ждет - создаем запись в этой таблице с каким-нибудь флажком, что это временная запись, а не основная. и пишем туда то, что должны были добавить или отнять от основной суммы.
3. То, что я не написал в п1. Если запись заблокировали, то основная запись модифицируется не только нужной нам суммой, но и подтягивает временные строки в основную сумму, а их убивает.

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

Вот и все.
Кстати, будет интересно услышать критику такого метода.
28 июл 06, 11:04    [2936948]     Ответить | Цитировать Сообщить модератору
 Re: Нужен совет по архитектуре базы!  [new]
не DBA
Member

Откуда: Москва
Сообщений: 77
Падонак
1.
>> при проведении первичных документов. Они по определению "массироваными" не бывают

дурак ты :)
интереснее было бы слышать ответы в форме "ты дурак потому что...".
Падонак
2. подвисание сесии еще хуже, чем "заблокировано"
чем хуже? Загрузка такова что "затыкания" базы кучей документов в очереди произойти в принципе не может - запас стократный или даже тысячекратный. Время выполнения транзакции не заметно больше чем в системе с "параллельным" проведением документов. чем хуже то?
Падонак
3. перепроведение всех документов за период еще бывает
это и есть та самая транзакция на минуты и демятки минут о которой я писал. Повторю вопросы
1) а построчная блокировка в таких больших транзакциях не приведет к тому же результату что и блокировка всех таблиц? Ведь лопатица куча данных...
2) Это штатная функциональность которой пользуются каждый день или она нужна в редких случаях для правки каких-то ошибок?
3) Легко ли в такой функциональности вынести в начало кода блокировку для всех меняемых (и наверное читаемых тоже?) строчек?

от ответа на эти и другие вопросы зависит приняте решение - можно ли в такой ф-ти блокировать таблицу
28 июл 06, 11:06    [2936967]     Ответить | Цитировать Сообщить модератору
 Re: Нужен совет по архитектуре базы!  [new]
pamir
Member [скрыт]

Откуда:
Сообщений: 27433
ps. Подтягивание временных строк в основную можно сделать и на джобе. Нужно смотреть по ситуации.
28 июл 06, 11:06    [2936973]     Ответить | Цитировать Сообщить модератору
 Re: Нужен совет по архитектуре базы!  [new]
Sergey M
Member

Откуда: г. Барнаул
Сообщений: 5462
не DBA
это и есть та самая транзакция на минуты и демятки минут о которой я писал. Повторю вопросы
1) а построчная блокировка в таких больших транзакциях не приведет к тому же результату что и блокировка всех таблиц? Ведь лопатица куча данных...

как правило не приведет, никто же не перепроводит документы за все прошедшие 10 лет
не DBA

2) Это штатная функциональность которой пользуются каждый день или она нужна в редких случаях для правки каких-то ошибок?

это в общем-то не штатная операция, но и исключительной ее назвать нельзя в любом случае нежелательно чтобы эта операция блокировала возможность нормальной работы операторов/кассиров

не DBA

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

select for update написать что-ли ?? вроде не сложно. А читать пускай читают
28 июл 06, 11:18    [2937070]     Ответить | Цитировать Сообщить модератору
 Re: Нужен совет по архитектуре базы!  [new]
Elic
Member

Откуда:
Сообщений: 29976
contr
contr
FOR UPDATE
Разумеется, имелось ввиду
FOR UPDATE OF Qty;
- к statement restart надо относиться с уважением.
Это надуманный перегиб. RTFM FOR UPDATE OF ...:
SQL Reference
The columns in the OF clause only indicate which table or view rows are locked.
28 июл 06, 11:25    [2937139]     Ответить | Цитировать Сообщить модератору
 Re: Нужен совет по архитектуре базы!  [new]
KRED
Member

Откуда: München/Augsburg (Germany)
Сообщений: 595
contr
KRED
Спасибо ребята читал это уже совершенно давно и хорошо понимаю что значит уровни изоляций и как в какий базах они происходят.
Но я писал о ОЛТП транзакции в оракле , заметь в оракле.
Хм... А я куда сослал? Мне казалось, что в oracle concepts... :)
KRED
SELECT .... FOR UPDATE - блокиреут выбранные записи на чтение до конца текущей транзакции . то есть
SELECT x into y from table where id = z for update x; БЛОКИРУЕТ СТРОКУ НА ЧТЕНИЕ ДО КОНЦА ТРАНЦАКЦИИ ..
Похоже, Вам имеет смысл освежить в памяти содержимое той доки :)
"На чтение" в oracle строку заблокировать нельзя.


eto vam nygno osvegit pamyat ... ya i sam povolsya chto nelza, nelza ... tolko chto proveril na 9.2.X.X mogy echo proverit 10.2.X.X ili na RACe ... BLOKIRYET NA CHTENIE
Inache chem togda bydet otlichatsya operator SELECT ot SELECT FOR UPDATE ?

SQL> create table kred_t (pk varchar(200),val varchar(200));

Tabelle wurde angelegt.

SQL> create unique index kred_t_pk on kred_t (pk);

Index wurde angelegt.

SQL> insert into kred_t values('1','KRED');

1 Zeile wurde erstellt.

SQL> insert into kred_t values('2','RED');

1 Zeile wurde erstellt.

SQL> commit;

Transaktion mit COMMIT abgeschlossen.

SQL> select val from kred_t where pk = '1' for update;

VAL
--------------------------------------------------------------------------------

KRED

SQL> update kred_t set val = 'KRED+' where pk = 1;

1 Zeile wurde aktualisiert.

SQL> commit;

Transaktion mit COMMIT abgeschlossen.


SQL> select val from kred_t where pk = '1' for update;

VAL
----------------------------------------------------------------------------

KRED+

SQL> commit;

Transaktion mit COMMIT abgeschlossen.

SQL>

cnachalo bil pervii SELECT FOR UPDATE potom vtoroi zapustil poka pervaya transaczia ne zakonchilas....
28 июл 06, 11:27    [2937159]     Ответить | Цитировать Сообщить модератору
 Re: Нужен совет по архитектуре базы!  [new]
KRED
Member

Откуда: München/Augsburg (Germany)
Сообщений: 595
contr
Падонак
ну он же написал "как" :)

Не потакайте.
Есть вещи, которые должен знать каждый девелопер :)


oO komy to tyt nygno eto raspechatat pary raz i na steny kak oboi pribit -:)
28 июл 06, 11:29    [2937174]     Ответить | Цитировать Сообщить модератору
 Re: Нужен совет по архитектуре базы!  [new]
KRED
Member

Откуда: München/Augsburg (Germany)
Сообщений: 595
contr
Вячеслав Любомудров
А еще девелопер должен знать, что утверждение
contr
"На чтение" в oracle строку заблокировать нельзя.
в общем случае неверное

Продемонстрируете?


cmotri vishe ya prodemonstriroval ... !
28 июл 06, 11:30    [2937186]     Ответить | Цитировать Сообщить модератору
 Re: Нужен совет по архитектуре базы!  [new]
Маньяк
Member

Откуда: оттуда
Сообщений: 287
pamir
ps. Подтягивание временных строк в основную можно сделать и на джобе. Нужно смотреть по ситуации.


да еще один ламерский вопрос
еще ни разу не создавал job-ов на базе
насколько они загружают базу? надо ли предусматривать какие-то дополнительные ресурсы
28 июл 06, 11:33    [2937207]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 2 3 [4] 5 6 7   вперед  Ctrl      все
Все форумы / Oracle Ответить