Здравствуйте, OLEGus1, Вы писали:
OLE>>TABLE1 попал в бэкап. OLE>>Пользователь сохранил транзакцию TABLE1+TABLE2. Допустим, изменил TABLE1.NAME и TABLE2.IDTABLE1 OLE>>TABLE2 попал в бэкап. OLE>Щас придеретесь, что пример не показателен. OLE>Ладно: произошло: OLE>insert into TABLE1 OLE>и insert into TABLE2
Жжошь!
-- Пользователи не приняли программу. Всех пришлось уничтожить. --
[Sorry, skipped] OLE>> TABLE1 попал в бэкап. OLE>> Пользователь сохранил транзакцию TABLE1+TABLE2. Допустим, изменил TABLE1.NAME и TABLE2.IDTABLE1 OLE>> TABLE2 попал в бэкап. OLE>> Ура!
КД> О боже, парень, пиши еще !
Да. Конкретная патология и товарища...
И он ещё кому-то что-то советует/не советует...
"OLEGus1" <5096@users.rsdn.ru> wrote in message news:1957084@news.rsdn.ru... > Щас придеретесь, что пример не показателен. > Ладно: произошло: > insert into TABLE1 > и insert into TABLE2
А теперь курим ман по транзакциям до просвтеления Пока транзакция не commited, gbak читает прошлые версии записей существовавшие до старта транзакции, неважно одну таблицу она затрагивает или сто.
Здравствуйте, OLEGus1, Вы писали:
П>>А что, РК принципиально неюзабилен? Если действительно очень надо? OLE>Очень надо и продукт разные вещи. "Очень надо" — это обычный костыль. М$ часто такие вещи практикует.
Так тебе шашечки?
OLE>Нет подмены понятий. Есть простой и надежный механизм (сибес) бэкапа и восстановления (к слову сказать, ни разу не пришлось делать).
А, ну тогда понятно почему вопрос о времени восстановления был обойден стороной.
OLE>Для данной задачи-не советовал и не советую.
Ну аргументируй уже наконец, что такого абсолютно несовместимого ты видишь в нем с данной конкретной задачей? А то все больше какие-то страшные истории про казлов и костыли. Почему у людей при аналогичных перечисленным параметрах работает, а у данного конкретного человека — не будет? Что за тайное знание такое у тебя есть о его системе?
OLE>Юзерам не повредит. Ситуация: юзер транзакцией во время бекапа поменял две таблички. Но одна табличка уже забекапилась, а вторая еще не забекапилась.
Ух, как интересно! И что же будет?
П>>Да, с последующим тестовым восстановлением. OLE>Так и представляю... Набольшой базе процесс gbak и восстановления может занять не одни сутки вообщето.
А на очень большой — столько же займет простое копирование. Но такие базы FB никто и не советовал. И к чему эти передергивания?
OLE>Ранняя стадия-это от нескольких часов?
Да. Сравни с "вообще никогда" для случая, когда невосстановимость не отслеживается. А она, как уже выяснили, может случиться на любой СУБД.
Здравствуйте, wellwell, Вы писали:
W>"OLEGus1" <5096@users.rsdn.ru> wrote in message news:1957084@news.rsdn.ru... >> Щас придеретесь, что пример не показателен. >> Ладно: произошло: >> insert into TABLE1 >> и insert into TABLE2
W>А теперь курим ман по транзакциям до просвтеления Пока транзакция не commited, gbak читает прошлые версии записей существовавшие до старта транзакции, неважно одну таблицу она затрагивает или сто.
Люди, держите меня
-- Пользователи не приняли программу. Всех пришлось уничтожить. --
Здравствуйте, OLEGus1, Вы писали:
OLE>Здравствуйте, Alex.Che, Вы писали:
AC>>Да. Конкретная патология и товарища... AC>>И он ещё кому-то что-то советует/не советует...
OLE>хм... я что то не так написал?
Все так. Именно так как я и ожидал, когда задал вопрос. Я жму вашу руку. Зачот.
-- Пользователи не приняли программу. Всех пришлось уничтожить. --
Привет, OLEGus1!
Вы пишешь 15 июня 2006:
AC>> Да. Конкретная патология и товарища... AC>> И он ещё кому-то что-то советует/не советует...
O> хм... я что то не так написал?
— Лучше мне промолчать, — подумала Алиса.
На этот раз, так как она не произнесла ни слова, никто нечего не сказал,
но, к величайшему ее удивлению, все хором подумали:
— Лучше промолчи! (С)
Здравствуйте, OLEGus1, Вы писали:
OLE>хм... я что то не так написал?
JFYI: gbak — это обычный клиент, который при запуске стартует свою собственную читающую транзакцию и завершает ее после окончания бэкапа. Все чтения идут в ее контексте. Дальше объяснять или понятно?
PS На всякий случай, т.к. предвижу крик на эту тему: читающие транзакции в FB не блокируют базу.
Здравствуйте, Пацак, Вы писали:
П>Почему у людей при аналогичных перечисленным параметрах работает, а у данного конкретного человека — не будет? Что за тайное знание такое у тебя есть о его системе? П>Но такие базы FB никто и не советовал. И к чему эти передергивания?
Вот тебе две твои жефразы.
А база у человека, судя по всему будет не из небольших (к тому же их 6). И многочасовой бэкап ему обеспечен.
П>Да. Сравни с "вообще никогда" для случая, когда невосстановимость не отслеживается. А она, как уже выяснили, может случиться на любой СУБД.
Может. Но причины разные.
Здравствуйте, Пацак, Вы писали:
П>Здравствуйте, OLEGus1, Вы писали:
OLE>>хм... я что то не так написал?
П>JFYI: gbak — это обычный клиент, который при запуске стартует свою собственную читающую транзакцию и завершает ее после окончания бэкапа. Все чтения идут в ее контексте. Дальше объяснять или понятно?
Более того, транзакция с уровнем изоляции "повторяемое чтение". То есть хоть "обизменяйся" и "обкоммиться".
Не, какой аблом для этого, не побоюсь этого слова, реального пацана
-- Пользователи не приняли программу. Всех пришлось уничтожить. --
Здравствуйте, Пацак, Вы писали:
П>Здравствуйте, OLEGus1, Вы писали:
OLE>>А база у человека, судя по всему будет не из небольших (к тому же их 6). И многочасовой бэкап ему обеспечен.
П>Многочасовой <> многодневный
1сутки=24 часа. 24 часа это много часовой? Для кучи немаленьких баз эта цифра реальна. П>Короче опять передергивания вместо конкретных ответов.
Передергиванья как раз у тебя.
OLE>>Может. Но причины разные. П>Зато результат один.
Результат тоже разный. При неопределенном невосстанавливающемся бэкапе у ФБ такое будет и на следующих, в отличие от тогоже постгреса.
Здравствуйте, Пацак, Вы писали:
П>>>Многочасовой <> многодневный OLE>>1сутки=24 часа. 24 часа это много часовой?
П>...но не многодневный — о том и речь. OLE>>При неопределенном невосстанавливающемся бэкапе у ФБ такое будет и на следующих П>Вот именно поэтому и нужен процесс, который отследит это сразу после возникновения.
OLE>>, в отличие от тогоже постгреса. П>А, ну да — у постгреса бэдблочный винт, на который делается бэкап за это время самопроизвольно самопочинится.
Здравствуйте, Коваленко Дмитрий, Вы писали:
КД>Жжошь!
Хлеб купил?
4. Подключение пользователей во время процедуры восстановления
Если Вы не заблокируете доступ пользователей к базе данных в процессе её восстановления командой gbak -r[eplace] , то они будут иметь возможность, подключившись, осуществить некоторые действия по изменению данных, что, в свою очередь, приведет к порче базы данных.
OLE>4. Подключение пользователей во время процедуры восстановления
OLE>Если Вы не заблокируете доступ пользователей к базе данных в процессе её восстановления командой gbak -r[eplace] , то они будут иметь возможность, подключившись, осуществить некоторые действия по изменению данных, что, в свою очередь, приведет к порче базы данных.
OLE>Все. Терь точно ушел.
Пока!
Так ты даже не различаешь бэкап и рестор!
Удивил. А как много написал.
Да, и почитай про уровни изолированности транзакций.
Здравствуйте, OLEGus1, Вы писали:
H_I>>Да как с добрым утром... Не далее, как две недели назад ковырял такой сервак. 5-й рейд, вылетел один диск. И все! Приходи кума любоваться... OLE>Возможно, но опять же это исключительный случай.
При чем тут исключения? Я говорю о том, что такое может случиться с любым серваком. И ни FB, ни SyBase, ни Oracle, ни какой либо другой не застрахован от таких казусов. И делать регулярные бэкапы, причем на разные устройства и машины, жизненно необходимо. Причем, бэкапить как БД, так и диски машин, на которые эти бэкапы пишутся. Элементарные требования к сохранности данных.
OLE>Тут как раз просто. Если помнишь, у Експерта коннекты хранятся в списке. А визуальность этого списка весьма неинформативна.
Да ну?! А кто мешает каждому коннекту задать внятное описание? У меня вот таковые заданы. И я не путаюсь в них. И в боевую БД лезу только тогда, когда сделан ее полный бэкап, и этот бэкап проверен на восстановимость. А заодно тогда, когда в базе не остается ни одного юзера. Да и, насколько мне известно, рестор никогда не пройдет, если к БД не открыт единственный и эксклюзивный коннект.
OLE>Инструмент хорош-согласен. Что напрягает-исключения выпадающие иногда не пойми на что, ну и невозможность работы с фильтрами на большимие таблицы.
Ни разу не сталкивался... Таблица в три миллиона записей фильтруется секунд 5 на двухголовой машине с двумя гигами оперативы. Может быть, что на менее сильной машине и будут тормоза. Не проверял за отсутствием таковой...
OLE>Хотя у других СУБД и такого зачастую нет.
Да ну... У того же Oracle с использованием PL/SQL Developer при наложении фильтра на неиндексированный столбец тормоза — будь здоров... И у MS SQL тоже... Так что — не показатель. Как пример — кусочки кода из вполне боевой БД Oracle размером в 32 гига...
Вот такая вьюха:
CREATE OR REPLACE VIEW V_RQ_DATA AS
select RQ."ID",RQ."STATUS",RQ."CLIENT_ID",RQ."CREDIT_SUBTYPE_ID",RQ."DEPARTMENT_ID",
RQ."TERMINAL_ID",RQ."S_CURRENCY_TYPE_ID",RQ."R_DATE",RQ."OWS_APPL_FL",RQ."ISSUE_CARD_NUMBER",
RQ."R_UID",RQ."CONTRACT_DATE",RQ."RQ_ID",RQ."CLIENT_TYPE",RQ."COMMENT_SB",
RQ_EXCLUSIVE.GET_RQ_ATTR_N(RQ.ID,'HOUSE_DATE') HOUSE_DATE,
...
from RQ
WHERE RQ.DEPARTMENT_ID IN (SELECT DEPARTMENT_ID FROM PERMISSIONS P WHERE NAME = 'ACCESS')
AND RQ.CREDIT_SUBTYPE_ID IN (SELECT CREDIT_SUBTYPES_ID FROM PERMISSION_CT)
AND RQ.RQ_ID IS NOT NULL
Здесь вместо ... надо бы вставить еще 600 вызовов функции RQ_EXCLUSIVE.GET_RQ_ATTR_N(), да мне жаль места и трафика.
Сама функция RQ_EXCLUSIVE.GET_RQ_ATTR_N имеет вид:
FUNCTION GET_RQ_ATTR(pRQ_ID NUMBER,
pAttr_Type VARCHAR2) RETURN varchar2
is
BEGIN
FOR R IN (SELECT ATTR_VALUE
FROM RQ_ATTR
WHERE RQ_ID = pRQ_ID
AND ATTR_TYPE = pAttr_Type)
LOOP
RETURN R.ATTR_VALUE;
END LOOP;
RETURN NULL;
END;
Таблица RQ содержит порядка 8 миллионов записей, таблица RQ_ATTR — около 38 миллионов... Я бы, конечно, проектировщика убил медленной смертью в кислотной бочке за такое. Но — что имеем, как говорится... Так вот, 4-х процессорный сервак с 8 гигами оперативы на борту первые 20 записей из этой вьюхи выбирает аж за полторы минуты... Это я к тому, что инструмент разработчика (IBExpert или любой иной) вообще к скорости выборки данных не имеет никакого отношения...
Пока транзакция не commited, gbak читает прошлые версии записей существовавшие до старта транзакции, неважно одну таблицу она затрагивает или сто.
