Oracle кто удалил таблицу
Часовой пояс: UTC + 3 часа
Правила форума
ВНИМАНИЕ! Прежде чем задавать вопрос, ознакомьтесь со ссылками ниже:
Вопросы по отличиям версий SAP, Add-On, EHP - сюда
Вопросы по SAP Front End (SAPlogon, SAPgui, guiXT и т.д.) - сюда
Вопросы по LSMW - сюда
Вопросы по архивации в SAP - сюда
Вопросы по SAP GRC - сюда
Вопросы по SAP Business Workplace (почте SAP) и SAP Office - сюда
Вопросы по miniSAP (SAP mini basis) - сюда
Вопросы по SAP HANA - сюда
Вопросы по лицензированию продуктов SAP - сюда
Кто удалил данные из таблицы
Добрый день!Подскажите, как узнать кто удалил данные из таблицы? Добрый день!
Подскажите, как узнать кто удалил данные из таблицы?
нууу, что сказать.
1. надо проверить а не включен ли на нее журнал изменения. SCU3
но даже если включен то радоваться рано, надо проверить параметр rec/client если он активирован то можно будет найти кто сделал каку.
2. если журнала нет то тогда совсем плохо. надо выяснить каким образом можно удалить данные из это таблицы, и в stat или stad посмотреть кто запускал транзакции или отчеты, которые позволяют удалить из нее данные.
3. возможно данные затерли запросом, посомтреть не переносили ли таблицу.
4. так же данные могли удалить на уровне базы, и кто эт осделал можно выяснить только если был включен аудит на оракле.
в общем таблички в сапе разные, и копать надо с разных сторон.
P.S. может я что-то упустил, тогда дополните меня
_________________
Легче нести ахинею, чем бревно.
Подскажите, как узнать кто удалил данные из таблицы?
3. возможно данные затерли запросом, посомтреть не переносили ли таблицу.
4. так же данные могли удалить на уровне базы, и кто эт осделал можно выяснить только если был включен аудит на оракле.
в общем таблички в сапе разные, и копать надо с разных сторон.
P.S. может я что-то упустил, тогда дополните меня
Ну еще можно через se16 в отладке(можно увидеть изменение переменных в SM21), можно через динамический анализ (в примерах) при открытом манданте, можно через самописную программу. Вообщем способов хватает в сапе. Через оракл довольно экзотично нужен логин на инстанцию оракла или на уровень ос.
Часовой пояс: UTC + 3 часа
Кто сейчас на конференции
Логотип © 2006 Андрей Горшков
Поддержка: Кирилл Андреев, 2011-…
For you to delete rows from a table, the table must be in your own schema or you must have the DELETE object privilege on the table.
For you to delete rows from an updatable materialized view, the materialized view must be in your own schema or you must have the DELETE object privilege on the materialized view.
For you to delete rows from the base table of a view, the owner of the schema containing the view must have the DELETE object privilege on the base table. Also, if the view is in a schema other than your own, you must have the DELETE object privilege on the view.
The DELETE ANY TABLE system privilege also allows you to delete rows from any table or table partition or from the base table of any view.
You must also have the SELECT object privilege on the object from which you want to delete if:
The object is on a remote database or
The SQL92_SECURITY initialization parameter is set to TRUE and the DELETE operation references table columns, such as the columns in a where_clause
Specify a comment that passes instructions to the optimizer on choosing an execution plan for the statement.
Use the FROM clause to specify the database objects from which you are deleting rows.
The ONLY syntax is relevant only for views. Use the ONLY clause if the view in the FROM clause belongs to a view hierarchy and you do not want to delete rows from any of its subviews.
Use this clause to specify the objects from which data is being deleted.
Specify the schema containing the table or view. If you omit schema , then Oracle Database assumes the table or view is in your own schema.
table | view | materialized view | subquery
Specify the name of a table, view, materialized view, or the column or columns resulting from a subquery, from which the rows are to be deleted.
When you delete rows from an updatable view, Oracle Database deletes rows from the base table.
You cannot delete rows from a read-only materialized view. If you delete rows from a writable materialized view, then the database removes the rows from the underlying container table. However, the deletions are overwritten at the next refresh operation. If you delete rows from an updatable materialized view that is part of a materialized view group, then the database also removes the corresponding rows from the master table.
If table or the base table of view or the master table of materialized_view contains one or more domain index columns, then this statements executes the appropriate indextype delete routine.
Oracle Data Cartridge Developer's Guide for more information on these routines
Issuing a DELETE statement against a table fires any DELETE triggers defined on the table.
All table or index space released by the deleted rows is retained by the table and index.
Specify the name of the partition or subpartition targeted for deletes within the object.
You need not specify the partition name when deleting values from a partitioned object. However, in some cases, specifying the partition name is more efficient than a complicated where_clause .
Specify the complete or partial name of a database link to a remote database where the object is located. You can delete rows from a remote object only if you are using Oracle Database distributed functionality.
If you omit dblink , then the database assumes that the object is located on the local database.
The subquery_restriction_clause lets you restrict the subquery in one of the following ways:
WITH READ ONLY Specify WITH READ ONLY to indicate that the table or view cannot be updated.
WITH CHECK OPTION Specify WITH CHECK OPTION to indicate that Oracle Database prohibits any changes to the table or view that would produce rows that are not included in the subquery. When used in the subquery of a DML statement, you can specify this clause in a subquery in the FROM clause but not in subquery in the WHERE clause.
CONSTRAINT constraint Specify the name of the CHECK OPTION constraint. If you omit this identifier, then Oracle automatically assigns the constraint a name of the form SYS_C n , where n is an integer that makes the constraint name unique within the database.
The table_collection_expression lets you inform Oracle that the value of collection_expression should be treated as a table for purposes of query and DML operations. The collection_expression can be a subquery, a column, a function, or a collection constructor. Regardless of its form, it must return a collection value—that is, a value whose type is nested table or varray. This process of extracting the elements of a collection is called collection unnesting .
The optional plus (+) is relevant if you are joining the TABLE expression with the parent table. The + creates an outer join of the two, so that the query returns rows from the outer table even if the collection expression is null.
In earlier releases of Oracle, when collection_expression was a subquery, table_collection_expression was expressed as THE subquery . That usage is now deprecated.
You can use a table_collection_expression in a correlated subquery to delete rows with values that also exist in another table.
collection_expression Specify a subquery that selects a nested table column from the object from which you are deleting.
Restrictions on the dml_table_expression_clause Clause This clause is subject to the following restrictions:
You cannot execute this statement if table or the base or master table of view or materialized_view contains any domain indexes marked IN_PROGRESS or FAILED.
You cannot insert into a partition if any affected index partitions are marked UNUSABLE .
You cannot specify the ORDER BY clause in the subquery of the DML_table_expression_clause .
You cannot delete from a view except through INSTEAD OF triggers if the defining query of the view contains one of the following constructs:
If you specify an index, index partition, or index subpartition that has been marked UNUSABLE , the DELETE statement will fail unless the SKIP_UNUSABLE_INDEXES initialization parameter has been set to true .
Use the where_clause to delete only rows that satisfy the condition. The condition can reference the object from which you are deleting and can contain a subquery. You can delete rows from a remote object only if you are using Oracle Database distributed functionality. Please refer to Chapter 7, "Conditions" for the syntax of condition .
If this clause contains a subquery that refers to remote objects, then the DELETE operation can run in parallel as long as the reference does not loop back to an object on the local database. However, if the subquery in the DML_table_expression_clause refers to any remote objects, then the DELETE operation will run serially without notification. Please refer to the parallel_clause in the CREATE TABLE documentation for additional information.
If you omit dblink , then the database assumes that the table or view is located on the local database.
If you omit the where_clause , then the database deletes all rows of the object.
t_alias Provide a correlation name for the table, view, materialized view, subquery, or collection value to be referenced elsewhere in the statement. This alias is required if the DML_table_expression_clause references any object type attributes or object type methods. Table aliases are generally used in DELETE statements with correlated queries.
This clause lets you return values from deleted columns, and thereby eliminate the need to issue a SELECT statement following the DELETE statement.
The returning clause retrieves the rows affected by a DML statement. You can specify this clause for tables and materialized views and for views with a single base table.
When operating on a single row, a DML statement with a returning_clause can retrieve column expressions using the affected row, rowid, and REFs to the affected row and store them in host variables or PL/SQL variables.
When operating on multiple rows, a DML statement with the returning_clause stores values from expressions, rowids, and REFs involving the affected rows in bind arrays.
expr Each item in the expr list must be a valid expression syntax.
INTO The INTO clause indicates that the values of the changed rows are to be stored in the variable(s) specified in data_item list.
data_item Each data_item is a host variable or PL/SQL variable that stores the retrieved expr value.
For each expression in the RETURNING list, you must specify a corresponding type-compatible PL/SQL variable or host variable in the INTO list.
Restrictions The following restrictions apply to the RETURNING clause:
The expr is restricted as follows:
For UPDATE and DELETE statements each expr must be a simple expression or a single-set aggregate function expression. You cannot combine simple expressions and single-set aggregate function expressions in the same returning_clause . For INSERT statements, each expr must be a simple expression. Aggregate functions are not supported in an INSERT statement RETURNING clause.
Single-set aggregate function expressions cannot include the DISTINCT keyword.
If the expr list contains a primary key column or other NOT NULL column, then the update statement fails if the table has a BEFORE UPDATE trigger defined on it.
You cannot specify the returning_clause for a multitable insert.
You cannot use this clause with parallel DML or with remote objects.
You cannot retrieve LONG types with this clause.
You cannot specify this clause for a view on which an INSTEAD OF trigger has been defined.
PL/SQL User's Guide and Reference for information on using the BULK COLLECT clause to return multiple values to collection variables
The error_logging_clause has the same behavior in DELETE statement as it does in an INSERT statement. Please refer to the INSERT statement error_logging_clause for more information.
Deleting Rows: Examples The following statement deletes all rows from the sample table oe.product_descriptions where the value of the language_id column is AR :
The following statement deletes from the sample table hr.employees purchasing clerks whose commission rate is less than 10%:
The following statement has the same effect as the preceding example, but uses a subquery:
Deleting Rows from a Remote Database: Example The following statement deletes specified rows from the locations table owned by the user hr on a database accessible by the database link remote :
Deleting Nested Table Rows: Example For an example that deletes nested table rows, please refer to "Table Collections: Examples".
Deleting Rows from a Partition: Example The following example removes rows from partition sales_q1_1998 of the sh.sales table:
Using the RETURNING Clause: Example The following example returns column salary from the deleted rows and stores the result in bind variable :bnd1 . The bind variable must already have been declared.
Возможно выполнение операций условного обновления, вставки и удаления данных в таблице базы данных.
Выполняется операция UPDATE , если строки существуют, и операция INSERT , если это новая строка:
исключает необходимость в отдельных обновлениях;
повышается производительность и простота использования;
удобна в приложениях хранилища данных.
Сервером Oracle поддерживается инструкция MERGE для операций INSERT , UPDATE и DELETE . Используя эту инструкцию, можно обновить, вставить или удалить строку по условию в таблице, таким образом исключая необходимость применения нескольких инструкций DML. Решение о выполнении обновления, вставки или удаления в целевой таблице основывается на условии в предложении ON .
Необходимо иметь объектные привилегии INSERT и UPDATE на целевую таблицу и объектную привилегию SELECT на исходную таблицу. Чтобы задать предложение DELETE для merge_update_clause , необходимо также обладать объектной привилегией DELETE на целевую таблицу.
Инструкция MERGE является детерминированной. Одну и ту же строку целевой таблицы невозможно обновить несколько раз в одной и той же инструкции MERGE .
Альтернативный подход состоит в использовании циклов PL/SQL и нескольких инструкций DML. Однако инструкцию MERGE удобно использовать и проще выразить в виде одиночной инструкции SQL.
Инструкция MERGE удобна в ряде приложений хранилища данных. Например, в приложении хранилища данных иногда возникает необходимость в работе с данными, поступающими из нескольких источников, часть из которых может быть дубликатами. Инструкция MERGE позволяет добавлять и изменять строки по определенному условию.
Синтаксис инструкции MERGE
Используя инструкцию MERGE , можно по определенному условию вставлять, обновлять и удалять строки в таблице.
Объединение строк
Используя инструкцию MERGE , можно обновлять существующие строки и вставлять новые строки по определенному условию. Применяя инструкцию MERGE , можно удалить устаревшие строки одновременно с обновлением строк в таблице. Чтобы сделать это, в синтаксис инструк- ции MERGE включите предложение DELETE со своим собственным предложением WHERE .
Предложение INTO - задает целевую таблицу, которая обновляется или в которую выполняется вставка.
Предложение USING - идентифицирует источник обновляемых или вставляемых данных; может быть таблицей, представлением или подзапросом.
Предложение ON - условие, по которому операция MERGE выполняет обновление или вставку.
WHEN MATCHED | WHEN NOT MATCHED - предписывает серверу, как реагировать на результаты условия объединения
Более подробно изложено в документации Oracle Database 11g SQL Reference (Справочник по SQL для базы данных Oracle 11g).
Добрый день! Работая разработчиком Oracle PL/SQL, часто ли вам приходилось видеть в коде dbms_output.put_line в качестве средства debug-а? Стоит признать, что к сожалению, большинство (по моему личному мнению и опыту) разработчиков Oracle PL/SQL не уделяет должного внимания логированию как к «спасательному кругу» в случае возникновения ошибок. Более того, большая часть разработчиков не совсем понимает зачем нужно логировать информацию об ошибках и самое главное, не совсем понимают что делать и как использовать эту информацию в будущем.
Предисловие
Данным постом хотел бы начать цикл статей посвященных «Логированию ошибок» в Oracle PL/SQL. В первую очередь донести мысль до многих разработчиков, о том как можно построить функционал фиксации, хранения логов в БД. На своем опыте продемонстрировать поэтапный процесс создания полноценного логирования в БД. Рассказать как нам удалось создать логирование ошибок, разработать единую нумерацию событий для их дальнейшей идентификации, как поверх логирования «натянуть» мониторинг событий, создать функционал позволяющий увидеть все текущие ошибки в БД в виде таблиц (с указанием частоты возникновения ошибок и кол-ва и т.д.), графиков (отразить динамику роста кол-ва ошибок) и правильно распределить ресурсы для устранения тех или иных ошибок.
Оговорюсь сразу, что на рынке возможно уже есть успешные существующие коммерческие продукты осуществляющие логирование гораздо лучше и качественнее хотя бы, потому что у них есть многолетний опыт внедрения и сопровождения своего продукта в различных компаниях. Я же хочу показать один из множества примеров реализации функционала логирования, которые вполне можно осуществить силами своих разработчиков.
Введение
Модель логирования позволяет реализовать:
Единый подход в обработке и хранении событий
Собственную нумерацию и идентификацию событий происходящих в БД (статья)
Единый мониторинг событий (статья в разработке)
Анализ событий происходящих в БД (статья в разработке)
Описанные выше характеристики указаны в порядке нумерации и каждый следующий пункт (шаг) есть улучшение и усложнение существующей модели. Описание этой модели будет сложно выполнить в рамках одной статьи, поэтому опишем их последовательно. Начнём с первого пункта.
Единый подход в обработке и хранении событий
Основной идеей "Единого подхода в обработке и хранении событий" заключается в создании одного одновременно простого и в тоже время очень сложного правила: "Все объекты базы данных (функции, процедуры) в обязательном порядке должны завершаться блоком обработки исключений с последующим логированием события". Простота заключается в том, что легко, в команде разработчиков, на словах договориться об исполнении данного правила. Сложность же заключается в том, что данное правило должно быть установлено на ранних этапах создания вашей БД и выполняться обязательно на протяжении всего жизненного цикла. Внедрить функционал логирования в уже существующие и действующие БД очень сложно (практически не возможно).
Все объекты базы данных (функции, процедуры) в обязательном порядке должны завершаться блоком обработки исключений с последующим логированием события. Для этого можно использовать шаблон процедуры (функции) описанный во второй статье.
Наверное сейчас кто-то из читателей может возразить: "Зачем в обязательном порядке?". А всё очень просто, если вы разработчик PL/SQL и вы не согласны с этим правилом, то вот вам пример. Посмотрите на свой текущий проект более внимательно. Скорее всего вы найдете какое-нибудь логирование событий реализованное кем-то, когда-то. Вспомните сколько раз вы обращались к этому логированию при решении багов. Именно в таких ситуациях, когда есть срочность по времени в исправлении бага, вы или ваши коллеги начинают использовать dbms_output.put_line в качестве экспресс-дебага (быстрый способ получения значений переменных используемых в коде). Согласитесь, что для исправления бага мало знать в какой процедуре, в каком запросе и на какой строке возникла ошибка, необходимо знать параметры запроса на которых возникает ошибка. И вот тут нам на помощь приходит "Логирование событий", потому что помимо места возникновения ошибки мы узнаем параметры вызова процедуры, в которой возникает ошибка и это очень упрощает исправление бага.
Первая статья посвящена базовому функционалу «Логирования событий». В простейшей реализации это одна общая таблица и пакет процедур для работы с ней. Для создания и демонстрации логирования, нам необходимо реализовать следующие объекты БД (весь список объектов с их исходными кодами представлен в Git):
Таблица messagelog - единая таблица логов. Именно в данной таблице будет храниться информация о дате и времени события, об объекте где происходит событие, типе события с указанием кода, текста и параметров. В нашем примере, столбец backtrace вынесен в отдельную таблицу messagelog_backtrace для удобства.
Примечание. Представленное ниже описание таблицы является демонстрационным с минимальным набором столбцов для создания простейшего функционала логирования. Наличие дополнительных столбцов и их тип данных может меняться в зависимости от целей и задач логирования.
Также, учитывайте пожалуйста, что создание партиции требует как минимум Oracle EE. Создание партиции вне указанной версии Oracle приведет к нарушению лицензионного соглашения.
Читайте также: