How to monitor and log all the SQL insert commands - sql

I am using Oracle SQL Dev 2.1.1.64
I work with application that uses oracle database for storage.
Is there any way in SQL Dev. to monitor and log all the insert commands that are "coming" from the web application into database? Can you tell me how to do that?

audit insert table by <web-application-user> by access
should get you started.
Be sure to set the parameters audit_trail and audit_file_dest as you need them.
After that, you find the operations either in sys.aud$ or in the directory specified by audit_file_dest.
There is also fine grained auditing into which you might take a look, but from your question, using fine grained auditing (FGA) would seem to be overkill.

You can write a trigger for the tables you want to monitor. If you are only interested on the insert queries coming from the Web Application, you can check on the trigger for some specific username/schema accessing the table, and use that username as your web application credentials.
Alternatively you can also use Oracle's AUDIT feature. It requires a little bit of Oracle Database Administration knowledge to implement though...

You could query v$SQL, but you would need to have the relevant GRANTS to enable you to do this.
For long running sessions you can also monitor progress using v$session_longops
hope this helps you.

Create a trigger that writes to a journaling table whenever a change of data in the table happens (insert, update, delete).
Before delete, after insert, after update triggers are what you want.
It won't specifically log only the web application, but if you log the user making the change you will be able to filter on that when viewing the data.

Related

A master trigger

friends, I need your help,
I have a problem, I need to create a trigger that stores in a table all the interaction (access, insert, update, etc) that runs with the database; that saves who(user), when and what did (the query that was executed) in oracle.
Thanks in advance
You gave very few information on what you actually need, but you seem to be looking for the AUDIT functionality, that is available in Oracle 11g (that you tagged your question with).
From the docs :
Auditing is the monitoring and recording of selected user database actions. In standard auditing, you use initialization parameters and the AUDIT and NOAUDIT SQL statements to audit SQL statements, privileges, and schema objects, and network and multitier activities.
Check out this documentation, or this other one

I would like to set up a notification trigger when new data is added to a remote server. What is the best approach?

I'm a little lost and need some guidance on how to approach this feature I'd like to add.
Many operations I use require retrieving data from a remote server. My goal is to be able to receive an email notification if new data has been added to the remote server.
I thought about creating a stored procedure that uses "openquery" and compare data to a local table with a conditional statement that will send out an email if there are differences. Then scheduling a job that will execute this stored procedure frequently. But this does not feel elegant at all...
If I understood your question correctly, all depends on the permissions.
If I was the owner of the system
Find out which job is adding data to the system. Modify the process (ETL/ SQL job etc.) to send you an email. (best way)
If you have create permissions on the remote system
Create an after insert trigger, see the first example here. Refer to this link as well. (2nd best way)
If you have just permissions to create linked server
Whatever you wrote/ you can bring the data from the server (just the primary keys from the table) and keep on checking that by creating a job for new primary keys if any by copying the data to local.
How to choose between these two: depends on the size of data. Second method mentioned in point 3 will work even without a linked server.
But you will have to run this again and again, I can't think of any other way. Set up a SQL job/ ETL to do this for you.

Ensure that a SQL query is READ-only

What would be the best way to ensure that a SQL query won't alter the data of a database?
In my scenario, you don't have access to the database layer and can only do this logic on the application layer.
Would you recommend using a gem, a ruby custom script?
You can manage the permissions of the users so that they have access for reading the database but they don't have access to alter the database (i.e. not able to insert, update and delete). If you are using mysql, for instance, you can easily do this in phpmyadmin or equivalent tool.
Update based on your change. Even if you only have access through the application you are still connected to the database as a user who has or does not have privileges to update, delete, insert or select and as such the only way to ensure no such queries are executed is to alter that user's permissions.
A simple but far from foolproof method is to employ a blacklist of words that cannot be in the query, such as insert, update, etc.
Alternatively, you could use a parser on the sql query that will provide you with the necessary information to derive whether or not to allow the query.
I would take option 1 only as a last resort or if your checking needs are relatively simple.
On the database layer, make sure that the user the Rails app is accessing the database as only has the access that you desire, perhaps only SELECT.
Sequel has support for read only slave databases with a writable master database. Read-only slaves handle SELECT queries, other queries are done by the master database.
Maybe you can just setup master database as nil?
Another approach could be using hooks (before_save) to prevent writing to the database.

How to make live changes to SQL server express

I've been developing an asp.net web app using VS studio. I'm using SQL Server Express.
During development I have been testing my web app on my server.
Every time that I need to update my database I would simply delete my old database (located on my server) and upload my new DB. Since I'm only testing, and my app has no users, it hasn't been a problem.
Problem:
Once my site goes live I don't know how to make changes to my DB. Obviously I wont be able to simply delete it as it will contain user data. So how do people typically update a live DB. That is, lets say my site is live and now I need to add more tables and stored procedures to my DB. How would i do this on a live site?
To make changes to a production database, you'd:
Try to schedule an outage when the least number of users will be affected, posting information so users are aware prior to
Use data definition language (DDL) scripts to make the changes to the database tables, and potentially data manipulation language (DML) scripts to massage existing data into what the changes need.
The scripts necessary for step 2 should have been tested in Development and Test/QA environments to ensure as few issues as possible are experienced in the Production system. Backups that allow you to restore the database to previous versions of the application are required for both the Development and Test/QA environments.
You either need to:
Update your database at a time when no-one will be using the site. OR
Ensure that your updates do not affect the operation of the site.
The second option involves giving any new non-NULLable columns sensible defaults, ensuring that all INSERT statements use column lists (e.g. INSERT INTO dbo.MyTable (col1, col2, col3) VALUES (...)) and ensuring that new stored procedure parameters have defaults. This is not an exhaustive list, but a good start.
Mostly we create release scripts whereby the changes are scripted out and repeatable. So you will see things like
IF NOT EXISTS( SELECT * FROM INFORMATION_SCHEMA.COLUMNS
WHERE TABLE_NAME = 'myTableName'
AND COLUMN_NAME = 'myColumnName')
BEGIN
ALTER TABLE myTableName
ADD myColumnName varchar(50)
END
You can tell which objects have changed with stuff like:
SELECT
[name],
create_date,
modify_date
FROM sys.tables
ORDER BY
modify_date DESC
Some people use RedGate software to compare the 2 different database, but there is a cost to that.
It depends on that kinds of changes you want to make to your live database.
In your question you only talk about adding new tables and stored procedures.
As long as you only add new stuff (tables, sprocs, or even new columns to existing tables) you don't have to do anything special, because SQL Server can do this while the database is in use and the changes don't affect your users because their version of your app doesn't even know about your newly added stuff.
On the other hand, it gets way more complicated if you change or even delete existing stuff.
There is a great chance that this will be a breaking change for your app, as it will probably stop working when tables look different than it expects or if it tries to access tables/sprocs that don't exist anymore.
(Even if you only add new stuff like I said in the beginning - you will probably want to update your app anyway, so it can actually USE the new stuff in the database)
So you probably will need to make your database changes AND deploy a new version of your app as well, both at the same time.
I'm no ASP.NET expert, but as far as I know it's not possible to update an ASP.NET app without all active users getting kicked out.
So in this case you would have to do what OMG Ponies already said: choose a time when the least possible number of users is affected, and/or inform your users early enough about the scheduled outage.

Log changes made to all fields in a table to another table (SQL Server 2005)

I would like to log changes made to all fields in a table to another table. This will be used to keep a history of all the changes made to that table (Your basic change log table).
What is the best way to do it in SQL Server 2005?
I am going to assume the logic will be placed in some Triggers.
What is a good way to loop through all the fields checking for a change without hard coding all the fields?
As you can see from my questions, example code would be veeery much appreciated.
I noticed SQL Server 2008 has a new feature called Change Data Capture (CDC). (Here is a nice Channel9 video on CDC). This is similar to what we are looking for except we are using SQL Server 2005, already have a Log Table layout in-place and are also logging the user that made the changes. I also find it hard to justify writing out the before and after image of the whole record when one field might change.
Our current log file structure in place has a column for the Field Name, Old Data, New Data.
Thanks in advance and have a nice day.
Updated 12/22/08: I did some more research and found these two answers on Live Search QnA
You can create a trigger to do this. See
How do I audit changes to sq​l server data.
You can use triggers to log the data changes into the log tables. You can also purchase Log Explorer from www.lumigent.com and use that to read the transaction log to see what user made the change. The database needs to be in full recovery for this option however.
Updated 12/23/08: I also wanted a clean way to compare what changed and this looked like the reverse of a PIVOT, which I found out in SQL is called UNPIVOT. I am now leaning towards a Trigger using UNPIVOT on the INSERTED and DELETED tables. I was curious if this was already done so I am going through a search on "unpivot deleted inserted".
Posting Using update function from an after trigger had some different ideas but I still believe UNPIVOT is going to be the route to go.
Quite late but hopefully it will be useful for other readers…
Below is a modification of my answer I posted last week on a similar topic.
Short answer is that there is no “right” solution that would fit all. It depends on the requirements and the system being audited.
Triggers
Advantages: relatively easy to implement, a lot of flexibility on what is audited and how is audit data stored because you have full control
Disadvantages: It gets messy when you have a lot of tables and even more triggers. Maintenance can get heavy unless there is some third party tool to help. Also, depending on the database it can cause a performance impact.
Creating audit triggers in SQL Server
Log changes to database table with trigger
CDC
Advantages: Very easy to implement, natively supported
Disadvantages: Only available in enterprise edition, not very robust – if you change the schema your data will be lost. I wouldn’t recommend this for keeping a long term audit trail
Reading transaction log
Advantages: all you need to do is to put the database in full recovery mode and all info will be stored in transaction log
Disadvantages: You need a third party log reader in order to read this effectively
Read the log file (*.LDF) in sql server 2008
SQL Server Transaction Log Explorer/Analyzer
Third party tools
I’ve worked with several auditing tools from ApexSQL but there are also good tools from Idera (compliance manager) and Krell software (omni audit)
ApexSQL Audit – Trigger based auditing tool. Generated and manages auditing triggers
ApexSQL Log – Allows auditing by reading transaction log
Under SQL '05 you actually don't need to use triggers. Just take a look at the OUTPUT clause. OUTPUT works with inserts, updates, and deletes.
For example:
INSERT INTO mytable(description, phone)
OUTPUT INSERTED.description, INSERTED.phone INTO #TempTable
VALUES('blah', '1231231234')
Then you can do whatever you want with the #TempTable, such as inserting those records into a logging table.
As a side note, this is an extremely easy way of capturing the value of an identity field.
You can use Log Rescue. It quite the same as Log Explorer, but it is free.
It can view history of each row in any tables with logging info of user, action and time.
And you can undo to any versions of row without set database to recovery mode.