I have inserted some rows in vertica database using insert command on terminal.It shows when i read the record using select command.But i am not able to see record when connect to database using ODBC connection also i am able to find that row when restart the vertica.Please help me to solved out the problem.
Did you COMMIT; after you inserted the rows? It's a simple thing, but one that I've overlooked myself many times in the past.
To elaborate a bit beyond Bobby W's response.
When you perform an insert it will show the data to your current session. This allows a user to perform operations and use 'temporary' data and not affect/corrupt what other people are doing. It is session based data. That is why you can insert and see the data, but when connecting from a 2nd source, are unable to see it.
To 'commit' the data to the database you need to issue the COMMIT; statement as Bobby W mentioned.
Failing to issue COMMIT; is something I've also overlooked more than a few times.
To clarify, you can see the rows after you restart? Are you connecting to the database as the same user from ODBC and vsql?
By default Vertica ISOLATION level is READ COMMITTED mode which means other sessions read only data that is COMMITTED. If you've inserted but not committed, with this level, other sessions cannot read the data you've inserted
Related
I have a stored procedure which has been running for a long time and I don't find any entry for that in v$session_longops. Is there a way to check on the current status of that?
Also, am pretty new to oracle. So is there a way to check on the amount of data the proc is trying to load into a table just like work flow monitor in informatica?
I am a dev and am using Oracle 12c.
Check with a view called gv$session. Column sql_text should let you identify your session and column rows_processed should tell you how many rows, if any, have been processed.
You may need to ask your DBA to grant you access to that view.
I’ve been tasked with doing some housekeeping on an Oracle schema I have access to. In a nutshell, I’d like to drop any tables that have not been ‘used’ in the last 3 months (tables that haven’t been queried or had data manipulated in the last 3 months). I have read/write access to the schema but I’m not a DBA; I run relatively basic DML/DDL queries in Oracle.
I’m trying to figure out if there’s a way for me to identify old/redundant tables; here’s what I’ve tried (mostly unsuccessfully)
USER_TABLES was my first port of call, but the LAST_ANALYZED date in this table doesn’t seem to be the last modified/queried date I’m looking for
Googling has brought DBA_Hist tables to my attention, I’ve tried querying some of these (i.e. DBA_HIST_SYSSTAT) but I’m confronted with (ORA-00942: table or view does not exist)
I’ve also tried querying V$SESSION_WAIT, V$ACTIVE_SESSION_HISTORY and V$SEGMENT_STATISTICS, but I get the same ORA-00942 error
I’d be grateful for any advice about whether the options above actually offer the sort of information I need about tables, and if so what I can do to work around the errors I’m getting. Alternatively, are there any other options that I could explore?
Probably the easiest thing to do, to be 100% sure, is to enable auditing on the Oracle tables that you're interested in (possibly all of them). Once enabled, Oracle has an audit table (dba_audit_trail) that you can query to find if the table(s) have been accessed. You can enable auditing by issuing: AUDIT on . BY SESSION;
I chose "by session" so that you only get a single record per session, no matter how many times the session performs the operation (to minimize the records in the audit table).
Example:
audit select on bob.inventory by session;
Then you can query the dba_audit_trail after some time passes to see if any records show up for that table.
You can disable auditing by issuing the "noaudit" command.
Hope that helps.
-Jim
Recently, a very strange scenario has been reported from one of of our sites.
Based on our fields, we found that there should be some kind of delete that must have happenend for that scenario
In our application code, there is no delete for that table itself. So we checked in gv$sqlarea(since we use RAC) table whether there are any delete sql for this table. We found nothing.
Then we tried to do the same kind of delete through our PL/SQL Developer. We are able to track all delete through gv$sqlarea or gv$session. But when we use below query, lock, edit and commit in plsql developer, there is no trace
select t.*, t.rowid
from <table>
Something which we are able to find is sys.mon_mods$ has the count of deletes. But it is not stored for a long time, so that we can trace by timestamp
Can anyone help me out to track this down
Oracle Version: 11.1.0.7.0
Type : RAC (5 instances)
gv$sqlarea just shows the SQL statements that are in the shared pool. If the statement is only executed once, depending on how large the shared pool and how many distinct SQL statements are executed, a statement might not be in the shared pool very long. I certainly wouldn't expect that a one-time statement would still be in the shared pool of a reasonably active system after a couple hours.
Assuming that you didn't enable auditing and that you don't have triggers that record deletes, is the system in ARCHIVELOG mode? Do you have the archived logs from the point in time where the row was deleted? If so, you could potentially use LogMiner to look through the archived logs to find the statement in question.
I need to do a task but I have no idea how to do it.
Here is the problem:
I have about 1000 tables on a Oracle Database and many processes.
Each process does one or more SELECT on one or many tables.
Because it's almost impossible to look in the source code to find which process does which SELECT on which tables, I would like to have some kind of trigger on SELECT on every table.
The idea is that I will launch the processes one by one to be able to see which tables will query.
I know that there is no trigger on SELECT, but is there anything else?
I need to do this in a one shot, just to recover the necessary info, it will not run every day.
You could activate auditing. You can audit all SELECT with:
AUDIT SELECT TABLE;
You can specify BY SESSION so that only one record will be written to the audit trail per table accessed per session.
Your AUDIT_TRAIL parameter must be set to either DB or OS. If it is set to DB, the audit trail will be written to the SYS.AUD$ table.
Assuming that you can map a "process" in your terminology to a particular Oracle session, you could trace the Oracle session. That would show you all the SQL statements executed by that session.
You could also potentially do a SQL*Net trace from whatever the client machine is (note that the "client machine" in a three-tier environment is the application server). A SQL*Net trace tends not to be nearly as easy to work with, however.
visual studion 2008
oracle db 11.1.0.7
oracle client for .NET
I have a relatively simple query, that selects the rows from across multiple tables (up to 4) using joins. OracleDataAdapter returns no rows for the only dataset's table, but if I copy and paste that query in SQLDeveloper then I get the desired results.
I can get the data from other tables using the adapter with no problem, but it seems like it struggles with the bit longer selection query (string length is ~ 300 (not that much at all))
Connection string for the connection is 100% correct.
Any ideas? thank you...
Check that you using same oracle user to connect to database. Maybe FGAC hides data.
Check that there is no temporary tables in you query.
Solution by OP.
The problem was, that after I imported the data in the SQLDeveloper in one of the involved tables, this change hasn't been committed automatically as I've falsely presumed... I've figured this out after I edited some data in the same table within the SQLDeveloper, and it has failed with the message that the edit operation on uncommitted action is now allowed. The headache I had was in SQLDeveloper, not the DataAdapter.