» СУБД Oracle (Оракл - для поиска:)).

Можно ли не пересоздавая последовательность,
с помощью alter sequence установить lastnumber в 1,
при этом оставив minvalue тоже 1 (а не 0)?

На сколько я знаю, чтобы обнулить sequence, ее надо пересоздать заново (по крайней мере в Oracle 8)

Ну я так понимаю, если я секьюенсы посбрасываю, то оно конечно начнёт со значения "1", но ведь когда оно дойдёт до существующего значения 1000, просто будет писать поверх или я ошибаюсь?

lYY
В 9-ке ничего не изменилось:
Цитата:

To restart the sequence at a different number, you must drop and re-create it.

dene14
Совершенно верно - сиквенс ничего не знает о значениях в таблице, поэтому после пересоздания обычно необходимо "догнать" ее до максимального значения, которое имеется в таблице (или создать с опцией START WITH)

lYY,vshersh

Код: declare
New_LAST_NUMBER integer := 1;
increment_by integer;
begin
execute immediate 'alter sequence SEXPRESS.AUTOINC_SEQ nocache';
begin
select New_LAST_NUMBER-1-SEXPRESS.AUTOINC_SEQ.nextval into increment_by from dual;
if increment_by<>0 then
execute immediate
'alter sequence SEXPRESS.AUTOINC_SEQ minvalue 0 increment by '||increment_by;
select SEXPRESS.AUTOINC_SEQ.nextval into increment_by from dual;
end if;
exception
when others then
null;
end;
execute immediate 'alter sequence SEXPRESS.AUTOINC_SEQ increment by 1 cache 10';
end;

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

Ламеру нужна помощь!
Хранилище данных. Таблица фактов(primary) и таблица измерений(foreign).
Для одного события, каждой строке ключа таблицы фактов должна соответствовать
строка из таблицы измерений(ключи уникальные!). Как это сделать??

Хотел сгенерировать последовательность (*.nextval в подчинённой таблице, а затем
*.currval в главной), так оказалось что sequence существует в пределах только
одной сессии. Как это делают нормальные люди???

Добавлено:
Тут выше pit23 уже спрашивал о чём-то подобном, но у меня отношение один-к-одному. Тоесть два уникальных ключа, и значения последовательностей для таблиц должны совпадать.

Я добавлю то что знаю про процедуры. Они хранятся в базе в откомпелированном виде. Если ты будешь из клиента выполнять запрос идентичный хранимой процедуре, то она будет выполнятся дольше, чем откомпилированная процедура. Я сам не спец в оракле, так что если что извиняйте...

Цитата:

так оказалось что sequence существует в пределах только
одной сессии

- а вот про это поподробней

Форумчане, как правильно качать с сайта оракла, я зарегистрировался в ОТН, при закачке ввожу имя пользователя и пароль, а далее получается качать только браузером -а у меня канал хлипкий, хотелось бы менеджером каким-нить качать, возвожно ли это?

PS: сорри если оффтоп, ткните носом куда писать...

deadbitch
как вариант предлагаю попробовать оперу (Opera), у нее есть возможность докачки

Добавлено:
ЗЫ, но только она не всегда позволяет корректно продолжить закачку

посмотри еще топики по reget-y, flashget-y

slaj1

Цитата:

deadbitch
как вариант предлагаю попробовать оперу (Opera), у нее есть возможность докачки

Добавлено:
ЗЫ, но только она не всегда позволяет корректно продолжить закачку

посмотри еще топики по reget-y, flashget-y

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

Утилита wget - мой выбор как на Linux, так и под Windows

_http://www.gnu.org/software/wget/
для Windows см. _http://www.christopherlewis.com/WGet/default.htm

Качаю так:

wget -c -v --load-cookies=coockies.txt hттp://downloads.oracle.com/BIG_file.zip


Разумеется, путь к свежим кукам (с зарегестрированной сессией на OTN) надо прописать отдельно или скопировать их в директорию wget.
Если интересны другие утилиты и пути, то можно поискать на форумах oracle.com, где этот вопрос также регулярно поднимается и обсуждается.

P.S.: ммм... кста, на sql.ru это я на ваш вопрос ответил?

Всем добрый день!

В Оракле есть такая штука как ссылка на БД (database link). Создавая её, указываешь к какой базе подсоединяешься (FOO.FOO), под каким пользователем (CONNECT TO), с каким паролем (IDENTIFIED BY) и на какой сервер (USING). Это была теория вкратце.
А теперь вопрос. Как создать ссылку на БД, чтобы через неё можно было подсоединяться к удалённой БД под разными пользователями?
Проблема в том, что, создав ссылку и указав пользователя, можно подсоединяться к схеме указанного пользователя. А вот если понадобилась схема другого пользователя... Также нельзя создать две разные ссылки, потому что их имена должны совпадать с именем БД, а два объекта с одним именем существовать не могут.

Вот такая вот проблемка, кто-нибудь сталкивался и решал её? Желательно решение не в ущерб безопасности.

А если создать публичный db-link?
CREATE PUBLIC DATABASE LINK DEV2.US.ORACLE.COM
USING 'dev2';

При подключении к экземпляру dev2 в сессии пользователя (например dev_user), вы будете иметь доступ к тем объектам БД dev2, к которым выданы права пользователю dev_user. Естественно, в базе dev2 заранее должны быть выданы гранты к объекты той или иной схемы.

С точки зрения безопасности, это не есть хорошо.

Если число таких "удаленных" объектов не велико, то можно пойти по пути создания набора синонимов на удаленные объекты.

StelmD
Публичная или непубличная ссылка на БД просто является либо личной для пользователся, её создавшей, либо общей для всех пользователей в локальной БД.
dev_user в примере тогда должен быть глобальным пользователем, чтобы всё прокатило.

---

Получается, что действительно надо мутить глобальных пользователей и раздавать им права; либо в ссылке указывать такого пользователя, который имеет там доступ к необходимым объектам.
А никак нельзя сначала подключиться к удалённой БД какой-нибудь командой, а потом использовать ссылку?

smf
CREATE DATABASE LINK LINK_TO_USER1 CONNECT TO USER1 IDENTIFIED BY psw1
using 'DEB';
CREATE DATABASE LINK LINK_TO_USER2 CONNECT TO USER2 IDENTIFIED BY psw2
using 'DEB';
создаются 2 db-link-а с разными именами
select * from table1@LINK_TO_USER1 - выбираем объекты 1-го юзера
select * from table1@LINK_TO_USER2 - выбираем объекты 2-го юзера
(Проверено на версии 9.2, 10.2)
Проблема решена?

smf
А нужно ли вообще использовать линки?
Судя по описанию проблемы (необходимость соединения под разными пользователями) нет смысла вообще использовать dblink, а нужно просто соединятся с этой БД под конкретным пользователем (возможно, в отдельной сессии). Механизм зависит от приложения, где используется и цели соединения с разными СУБД.
Возможно, стоит настроить репликацию данных, либо в JOB'е рабочая БД будет соединятся с несколькими другими БД по персональным линкам и регулярно подкачивать данные в собственные таблицы?

Помогите советом.
Имеется двухзвенное приложение (клиент-сервер). Необходимо реализовать аудит - при работе приложения с БД и изменении данных в определенных таблицах и в них определенных полей фиксировать факт создания/изменения/удаления данных ("тогда-то было изменено такое-то поле в такой-то строке в такой-то таблице"). Возможно, захочется фиксировать не просто факт, но и сами изменяемые данные ("было такое-то знаечние, стало такое-то").

Штатный AUDIT в Oracle слишком прост (не всё что надо фиксирует, трудно настроить тонко, например только на изменение в определенных таблицах определенных полей определенными пользователями) и сложен одновременно (трудно проанализировать информацию, трудно перенастроить ручками в случае изменения структуры БД). Кстати, готовых средств дял управления AUDIT-ом тоже не нашел (скажем PL/SQL Developer про него ни духом, в последней версии).

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

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

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

p.s. Вопрос интересует касательно Oracle 9i, но не бязательно.

royt
Честно говоря, про готовые решения ничего не слышал.
Насколько мне известно, возможно в принципе только два подхода - через стандартный аудит и через собственные триггеры. Кстати, уважаемый мною мэтр Том Кайт обоснованно ратует именно за первый способ.
Если сервер Oracle 10g, то в нем аудит более продвинутый. Есть и триггера на БД, срабатывающие не только при DML, но и при DDL. Есть Fine granted access через sys_context, правда мы его пока не применяли, хотя штука мощная (это вроде было начиная с сервера 8i).

А вообще, по поводу пожеланий, следует задаться вопросом: А оно надо именно в каком виде? А если надо, то для чего? Ловить-то кого? Если пограммеров, то это сложнее и здесь другие подходы, а если юзверей, то по нашему опыту могу сказать, что в 99% случаев хватает поля типа UPDATED_BY в каждой таблице, в которое триггером прописывается кто и в какое время изменил запись. Для особых случаев заводим INSERTED_BY. На критические таблицы создаем таблицы истории изменения, в которые записывается кто, когда и что менял (муторно, а что делать?).
По поводу частого изменения структуры данных могу сказать одно: в продуманной системе структуры меняются крайне редко и, в основном, в сторону добавления одного-двух непринципиальных полей. А если модель данных не проработана, то это означает, что система в "стадии осмысления идеи" и на этом этапе fine audit попросту не нужен.
Для построения модели данных ОБЯЗАТЕЛЬНО нужно использовать какое-нибудь CASE-средство типа Power Designer или хотя бы ErWin. Иначе, когда число таблиц приближается к тысяче, то уследить за моделью без CASE, мягко говоря, тяжеловато.

royt
Сделал аудит на основе триггеров.
Все просто замечательно.
Не понимаю зачем еще что-то выдумывать?

ORACLE 9i (Пользователь: SYS)
Пытаюсь поставить базу командами:

CREATE USER CRIM IDENTIFIED BY CRIM;
GRANT CONNECT TO CRIM;
GRANT RESOURCE TO CRIM;

На 2-х последних ошибка:
ORA-01919: role 'CONNECT' does not exist
ORA-01919: role 'RESOURCE' does not exist

В чем может быть проблема?
При передыдущей установки того-же само произошел скачек напряжения и комп перегрузился.
Скрипты запускаю через SQL Navigator.

bandyn
Выполни под сисом запрос:

Код: SELECT * FROM dba_roles

alexsob
В принципе я сам за AUDIT обеими руками, но приходится работать в 9-ке - а там трудно (или даже невозможно) настроить аудит например конкретных колонок в конкретной таблице. Причем хотелось бы, чтобы работало примерно так (чтобы не было слишком большой избыточности информации):
если в такой-то таблице что-то делается с колонками скажем 1, 2 и 5, то в аудите появляется одна (!) строка с информацией об этом - а не отдельные строки на каждую колонку. Причем, если что-то делается только с колонками 1 и 5, то в строке аудита и должны упоминаться только колонки, что подвергаются изменениям. Насколько я понял, такого сделать нельзя, по крайней мере в девятке. Или я не прав?

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


Цитата:

А оно надо именно в каком виде? А если надо, то для чего?

Надо для аудита работы с важными и конфиденциальными данными - видеть, в случае разборок, кто чего менял. А также отслеживать, просто кто с чем работал. "Ловить" надо пользователей программы, не программеров/админов (хотя в идеале конечно ловить бы всех, но пока хотя бы ограничиться пользователями). Еще такой момент - хотелось бы отслеживать не только совершенные изменения (и попытки чтения некоторых объектов), но и неудавшиеся попытки (т.е. фиксировать в логе что была попытка изменения, но она не удалась), а триггерами это опять же сделать непросто.

Кстати, а Вы не могли бы привести иcходный код вашего UPDATED_BY (можно в PM)? Чтобы представлять, что и как можно вообще. Я честно говоря в оракле еще не слишком гибко мыслю, не знаю всех возможностей - чего и как можно в триггере "поймать" (например, если триггер навешен сразу на INSERT+UPDATE+DELETE - то как в триггере определить, какая именно из этих трех операций производится, ну и т.д. В общем проще сразу взглянуть на код триггера - уж из него думаю всё пойму без доп. вопросов, разберусь если что).

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


Цитата:

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

Именно, что муторно... Пугает не то, что надо ручками работать, а то, что можно где-то чего-то недосмотреть. А вот если была бы какая визуальная тулза - покликал по нужным таблицам и колонкам, поставил галочки, указал какие операции аудитить - и на, получай audit- или triggers-скрипт. А незадействованные объекты сразу видны. В идеале примерно так себе представляю.

Если же писать ручками. Представим ситуацию: написали мы ручками скрипт (с помощью AUDIT или тригерров). Пускай структура базы достаточно большая, чтобы держать ее всю в голове - до сотни таблиц, в каждой от 5 до 20 колонок. Как после написания скрипта убедиться, что мы ничего не пропустили??? Трудно это - легко где-нибудь недосмотреть. Особенно если например на каждый INSERT/UPDATE/DELETE придется отдельные триггеры писать - их число вырастает сразу в несколько раз.


Цитата:

По поводу частого изменения структуры данных могу сказать одно: в продуманной системе структуры меняются крайне редко

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


Цитата:

Для построения модели данных ОБЯЗАТЕЛЬНО нужно использовать какое-нибудь CASE-средство типа Power Designer или хотя бы ErWin

Это само собой. Вот и для аудита хотелось бы найти готовый инструмент.

ps. За сообщение спасибо, потдвердились почти все мои предположения, это тоже ценно.

Добавлено:
pochti
Цитата:

Сделал аудит на основе триггеров. Все просто замечательно. Не понимаю зачем еще что-то выдумывать?

А можно посмотреть на пример триггера? Чтобы сразу понимать, какие вопросы задавать... Много тонких моментов по триггерам. Часть озвучил выше.

royt
Попробую ответить по-порядку:

UPDATED_BY - это просто varchar2 поле в каждой таблице.
Должно меняться триггером before insert or update for each rows на таблицу.
Если есть желание различать вставку или изменение, то в тексте можно сделать примерно так:
...
if INSERTING then
:new.updated_by := 'Вставка: '||
to_char(sysdate,'DD/MM/YY HH24:MI ')||
substr( adm_lib.get_user, 1, 15 );
-- adm_lib.get_user - функция, возвращающая имя пользователя по-русски
elsif UPDATING then
:new.updated_by := 'Изменение: '||
to_char(sysdate,'DD/MM/YY HH24:MI ')||
substr( adm_lib.get_user, 1, 15 );
end if;
...

2.Если ловим попытки изменений, тогда можно сделать так:

1. Создаем лог-таблицу истории изменений.
2. Создаем функцию, работающую в режиме автономной транзакции типа:
PROCEDURE save_history
(
p_table IN varchar2, -- количество и типы параметрой как фантазия позволит
p_oper IN varchar2
)
IS
PRAGMA AUTONOMOUS_TRANSACTION; -- указывает, что транзакция автономна
BEGIN
-- тут тоже как фантазия укажет
insert into лог_таблица (table_name, oper_desc)
values (p_table, p_oper);

commit; -- !!!
END;

3. Создаем триггер типа before insert or update or delete for each rows на нужную таблицу и в тексте примерно так:
...
if INSERTING then
v_oper := 'Попытка вставки строки: '||
to_char(sysdate,'DD/MM/YY HH24:MI ')||
substr( adm_lib.get_user, 1, 15 );
elsif UPDATING then
if UPDATING("отслеживаемое_поле_1") then -- можно и так: :new.поле1 <> ld.поле1
v_oper := 'Попытка изменения поля Поле1: ';
end if;
if UPDATING("отслеживаемое_поле_2") then
v_oper := v_oper || ' Попытка изменения поля Поле2: ';
end if;
-- ну и т.д.
v_oper := v_oper || to_char(sysdate,'DD/MM/YY HH24:MI ')||
substr( adm_lib.get_user, 1, 15 );
elsif DELETING then
v_oper := 'Попытка удаления строки: '||
to_char(sysdate,'DD/MM/YY HH24:MI ')||
substr( adm_lib.get_user, 1, 15 );
end if;
--
save_history('таблица',v_oper);
...

Если теперь ловим факт изменений данных, то аналогичный триггер но after insert or update or delete for each rows, только вызываем аналогичную, но другую функцию, которая не в автономной транзакции и не содержит commit.

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

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

royt
Как-то это все на фантастику смахивает, 100 таблиц х 20 колонок = 2000 колонок,
умножим на количество строк и обращений пользователей - получаются мегабайтные логи, ну и как их отслеживать? Никакого времени не хватит, чтобы это все отследить.
Я не прав?
Что это за секретная база и такое страшное недоверие к пользователям, зачем вообще нужна такая система? Если такая секретная система, то отдельно надо профессионалам разрабатывать систему безопасности.
Отрубить всех пользователей, чтоб не лезли

royt в принципе alexsob вполне досконально ответил

vshersh

Цитата:

Код:SELECT * FROM dba_roles


и посмотри есть ли там эти роли?

CONNECT, RESOURCE - таких ролей нет!

bandyn
значит скрипт создания системных объектов БД у тебя не выполнился

alexsob
Цитата:

А если и есть, то после изменения структуры его придется инициализировать заново.

Вот именно - при наличии готового инструмента эта обуза пускай лежала бы на нем. Вы ведь не видите проблемы, чтобы иногда запустить в каком-нибудь в ERwin-е reverse engineering и, например, внести в структуру базы небольшие изменения, сравнить с другой и т.д.

За триггер спасибо, про INSERTING/UPDATING/DELETING как раз хотел услышать, остальное очевидно. Ловить надо и попытки, и успешно выполнившиеся изменения. Но с триггерами некрасиво например следующее: если была "попытка" (вставить/удалить/изменить), и она завершилась успешно - то в логе лучше бы оставить только сообщение об свершившемся изменении, а о попытке можно удалить как избыточное. Можно конечно наворотить обработку (удаление ненужных записей) в триггере "after insert...", но слишком уж навороченно получается (либо писать код триггеров отдельно под каждую таблицу и ее поля, либо все это как-то передавать через параметры и писать небольшую инфраструктуру- от чего нагрузка на сервер хоть и немного, но еще больше возрастает). Кроме того, если ловить и попытки и успешные изменения - получается на каждое изменение будет срабатывать два триггера (до и после) - еще нагрузка... (по-хорошему бы обрабатывать результат запроса только один раз...) В общем, я думал может придумали какое-то элегантное решение, но чуда не свершилось.
Все равно, большое спасибо за ответ.

: Кстати, вопрос: допустим, в случае успешного завершения пользовательской транзации фиксируем этот факт, и при этом хотим удалить строку с информацией "Была предпринята попытка...", созданную в триггере INSERT - так вот как эффективнее найти эту строку? Т.е. если писать триггеры BEFORE и AFTER - как лучше "связать" между собой строки, формируемые этими триггерами (в рамках одной пользовательской/глобальной транзакции), по каким данным? Может существует какой-то "transaction id" (его можно было бы вставить в триггере BEFORE)?

lYY
Цитата:

Как-то это все на фантастику смахивает, 100 таблиц х 20 колонок = 2000 колонок

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


Цитата:

Что это за секретная база и такое страшное недоверие к пользователям, зачем вообще нужна такая система? Если такая секретная система, то отдельно надо профессионалам разрабатывать систему безопасности.

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

Про workspace может еще кто чего скажет. Вроде его каким-то образом можно приспособить, но все материалы на английском - осваивается медленно.