After you correct the possible dmp file problem, this is a way to ensure that the schema is remapped and imported appropriately. This will also ensure that the tablespace will change also, if needed: impdp system/ SCHEMAS=user1 remapschema=user1:user2 remaptablespace=user1:user2 directory=EXPORTDIR dumpfile=user1.dmp logfile=E: Data user1.log EXPORTDIR must be defined in oracle as a directory as the system user create or replace directory EXPORTDIR as 'E: Data'; grant read, write on directory EXPORTDIR to user2.
Hi you can even work on SH and supplier sales. This will be very good practice, Oracle has taken 'SH' schema.This supplier2 was from sibel (not sure).I even found this suppler2 training material from sibel. Before you begin. You can access Oracle database patches and patch sets at the Oracle Metalink Web page. For additional information about Oracle database terminology and concepts, refer to the Oracle Concepts document provided with your purchase of Oracle database. Oracle 11gR2 is supported with WebSphere Commerce Fix Pack 2 or later.
Identify the blocking session Oracle provides a view, DBABLOCKERS, which lists the SIDs of all blocking sessions. But this view is often, in my experience, a good bit slower than simply querying V$LOCK, and it doesn't offer any information beyond the SIDs of any sessions that are blocking other sessions. The V$LOCK view is faster to query, makes it easy to identify the blocking session, and has a lot more information. SQL select. from v$lock; ADDR KADDR SID TY ID1 ID2 LMODE REQUEST CTIME BLOCK - - - - - - - - - - AF9E2C4C AF9E2C60 479 TX 19 0 6 685 0 ADDF7EC8 ADDF7EE0 422 TM 88519 0 3 0 697 0 ADDF7F74 ADDF7F8C 479 TM 88519 0 3 0 685 0 ADEBEA20 ADEBEB3C 422 TX 19 6 0 697 1. Note the BLOCK column. If a session holds a lock that's blocking another session, BLOCK=1.
Further, you can tell which session is being blocked by comparing the values in ID1 and ID2. The blocked session will have the same values in ID1 and ID2 as the blocking session, and, since it is requesting a lock it's unable to get, it will have REQUEST 0. In the query above, we can see that SID 422 is blocking SID 479. SID 422 corresponds to Session 1 in our example, and SID 479 is our blocked Session 2. To avoid having to stare at the table and cross-compare ID1's and ID2's, put this in a query: SQL select l1.sid, ' IS BLOCKING ', l2.sid from v$lock l1, v$lock l2 where l1.block =1 and l2.request 0 and l1.id1=l2.id1 and l1.id2=l2.id2 SQL / SID 'ISBLOCKING' SID - - - 422 IS BLOCKING 479 1 row selected. There are many types of Oracle enqueues, here is a sample of the most common types: CF enqueue – The CF enqueue is a Control File enqueue (a.k.a. Enq: CF – contention) and happens during parallel access 6to the control files.
The CF enqueue can be seen during any action that requires reading the control file, such as redo log archiving, redo log switches and begin backup commands. CI Enqueue - The CI enqueue is the Cross Instance enqueue (a.k.a.
Enq: US - contention) and happens when a session executes a cross instance call such as a query over a database link. FB enqueue – This is the Format Block enqueue, used only when data blocks are using ASSM (Automatic Segment Space Management or bitmapped freelists). As we might expect, common FB enqueue relate to buffer busy conditions, especially since ASSM tends to cause performance problems under heavily DML loads. HV enqueue – The HV enqueue (a.k.a. Enq: HV - contention) is similar to the HW enqueue but for parallel direct path INSERTs.
HW enqueue – The HW High Water enqueue (a.k.a. Enq: HW – contention) occurs when competing processing are inserting into the same table and are trying to increase the high water mark of a table simultaneously. The HW enqueue can sometimes be removed by adding freelists or moving the segment to ASSM. KO enqueue – The KO enqueue (a.k.a. Enq: KO - fast object checkpoint) is seem in Oracle STAR transformations and high enqueue waits can indicate a sub-optimal DBWR background process. PE enqueue – The PE enqueue (a.k.a.
Enq: PE – contention) is the Parameter Enqueue, which happens after “alter system” or “alter session” statements. PS enqueue – The PS enqueue is the Parallel Slave synchronization enqueue (a.k.a enq: PS – contention), which is only seen with Oracle parallel query. The PS enqueue happens when pre-processing problems occur when allocating the factotum (slave) processes for OPQ.
RO Enqueue – The RO enqueue is the Reuse Object enqueue and is a cross-instance enqueue related to truncate table and drop table DDL operations. SQ enqueue – The SQ enqueue is the Sequence Cache enqueue (a.k.a. Enq: SQ – contention) is used to serialize access to Oracle sequences.
SS enqueue – The SS enqueue is the Sort Segment enqueue (a.k.a. Enq:SS – contention) and these are related to the sorting of large result sets. SS enqueue – The SS enqueues are Sort Segment enqueues (a.k.a. Enq: SS – contention), and occur when a process is performing a large sort operation. ST enqueue – The ST enqueue can be seen in a partitioned environment when a large number of partitions are created simultaneously. TC enqueue – The TC enqueue is related to the DBWR background process and occur when “alter tablespace” commands are issued. You will also see the TC enqueue when doing parallel full-table scans where rows are accessed directly, without being loaded into the data buffer cache.
TM enqueue – The TM enqueue related to Transaction Management (a.k.a. Enq: TM - contention) and can be seen when tables are explicitly locked with reorganization activities that require locking of a table. TQ enqueue – The TQ enqueue is the Queue Table enqueue (a.k.a. Enq: TQ - DDL contention) and happens during Data ump (export import) operations. TS enqueue – The TS enqueue is the temporary segment enqueue (a.k.a.
Enq: TS – contention) and these enqueues happen during disk sort operations. TT enqueue – The TT enqueue (a.k.a. Enq: TT – contention) is used to avoid deadlocks in parallel tablespace operations. The TT enqueue can be seen with parallel create tablespace and parallel point in time recovery (PITR) TX runqueue – The TX enqueue is the transaction enqueue (a.k.a.
Enq: TX – contention) and is commonly related to buffer busy waits, in conditions where multiple transaction attempt to update the same data blocks. Enq: TX - row lock contention enq: TX - allocate ITL entry enq: TX - row lock contention UL enqueue – The UL enqueue is a User Lock enqueue (a.k.a. Enq: UL – contention) and happens when a lock is requested in dbmslock.request. The UL enqueue can be seen in Oracle Data Pump. US Enqueue - The US enqueue happens with Oracle automatic UNDO management was undo segments are moved online and offline. Solving Waits on 'enq: TM - contention' by Dean R. On Jul 14 2008 at 4:55 AM in Wait Time Analysis Recently, I was assisting one of our customers of Ignite for Oracle trying to diagnose sessions waiting on the 'enq: TM - contention' event.
The blocked sessions were executing simple INSERT statements similar to: INSERT INTO supplier VALUES (:1,:2,:3); Waits on 'enq: TM - contention' indicate there are unindexed foreign key constraints. Reviewing the SUPPLIER table, we found a foreign key constraint referencing the PRODUCT table that did not have an associated index. This was also confirmed by the Top Objects feature of Ignite for Oracle because all the time was associated with the PRODUCT table. We added the index on the column referencing the PRODUCT table and the problem was solved. Cause After using Ignite for Oracle's locking feature to find the blocking sessions, we found the real culprit. Periodically, as the company reviewed its vendor list, they 'cleaned up' the SUPPLIER table several times a week.
As a result, rows from the SUPPLIER table were deleted. Those delete statements were then cascading to the PRODUCT table and taking out TM locks on it. Reproducing the Problem This problem has a simple fix, but I wanted to understand more about why this happens. So I reproduced the issue to see what happens under the covers. I first created a subset of the tables from this customer and loaded them with sample data. What is enq: TX - row lock contention Enqueues are locks that coordinate access to database resources. Enq: wait event indicates that the session is waiting for a lock that is held by another session.
The name of the enqueue is as part of the form enq: enqueuetype - relateddetails. The V$EVENTNAME view provides a complete list of all the enq: wait events. TX enqueue are acquired exclusive when a transaction initiates its first change and held until the transaction does a COMMIT or ROLLBACK. Several Situation of TX enqueue: - 1) Waits for TX in mode 6 occurs when a session is waiting for a row level lock that is already held by another session. This occurs when one user is updating or deleting a row, which another session wishes to update or delete.
This type of TX enqueue wait corresponds to the wait event enq: TX - row lock contention. The solution is to have the first session already holding the lock perform a COMMIT or ROLLBACK. 2) Waits for TX in mode 4 can occur if a session is waiting due to potential duplicates in UNIQUE index. If two sessions try to insert the same key value the second session has to wait to see if an ORA-0001 should be raised or not.
This type of TX enqueue wait corresponds to the wait event enq: TX - row lock contention. The solution is to have the first session already holding the lock perform a COMMIT or ROLLBACK. 3)Waits for TX in mode 4 is also possible if the session is waiting due to shared bitmap index fragment. Bitmap indexes index key values and a range of ROWIDs. Each ‘entry’ in a bitmap index can cover many rows in the actual table.
If two sessions want to update rows covered by the same bitmap index fragment, then the second session waits for the first transaction to either COMMIT or ROLLBACK by waiting for the TX lock in mode 4. This type of TX enqueue wait corresponds to the wait event enq: TX - row lock contention. Troubleshooting: for which SQL currently is waiting to, select sid, sqltext from v$session s, v$sql q where sid in (select sid from v$session where state in ('WAITING') and waitclass!= 'Idle' and event='enq: TX - row lock contention' and ( q.sqlid = s.sqlid or q.sqlid = s.prevsqlid)); The blocking session is, SQL select blockingsession, sid, serial#, waitclass, secondsinwait from v$session where blockingsession is not NULL order by blockingsession. Perform Without Waiting By Arup Nanda OTN Diagnose performance problems, using the wait interface in Oracle 10g.
John, the DBA at Acme Bank, is on the phone with an irate user, Bill, who complains that his database session is hanging, a complaint not unfamiliar to most DBAs. What can John do to address Bill's complaint? Acme Bank's database is Oracle Database 10g, so John has many options. Automatic Database Diagnostic Manager (ADDM), new in Oracle Database 10g, can tell John about the current overall status and performance of the database, so John starts with ADDM to determine whether what Bill's session is experiencing is the result of a databasewide issue. The ADDM report identifies no databasewide issues that could have this impact on Bill's session, so John moves on to the next option. One way to diagnose session-level events such as Bill's is to determine whether the session is waiting for anything, such as the reading of a block of a file, a lock on a table row, or a latch.
Oracle has provided mechanisms to display the waits happening inside the database since Oracle7, and during the last several years, the model has been steadily perfected, with more and more diagnostic information added to it. In Oracle Database 10g, which makes significantly improved wait event information available, diagnosing a session slowdown has become even easier. This article shows you how to use the wait events in Oracle Database 10g to identify bottlenecks. Session Waits How can John the DBA determine what's causing Bill's session to hang? Actually, the session is not hanging; it's waiting for an event to happen, and that's exactly what John checks for. To continue his investigation, John could use Oracle Enterprise Manager or he could directly access V$ views from the command line.
John has a set of scripts he uses to diagnose these types of problems, so he uses the command line. John queries the V$SESSION view to see what Bill's session is waiting for. (Note that John filters out all idle events.) select sid, username, event, blockingsession, secondsinwait, waittime from v$session where state in ('WAITING') and waitclass!= 'Idle'; The output follows, in vertical format. SID: 270 USERNAME: BILL EVENT: enq: TX - row lock contention BLOCKINGSESSION: 254 SECONDSINWAIT: 83 WAITTIME: 0 Looking at this information, John immediately concludes that Bill's session with SID 270 is waiting for a lock on a table and that that lock is held by session 254 (BLOCKINGSESSION). But John wants to know which SQL statement is causing this lock. He can find out easily, by issuing the following query joining the V$SESSION and V$SQL views: select sid, sqltext from v$session s, v$sql q where sid in (254,270) and (q.sqlid = s.sqlid or q.sqlid = s.prevsqlid); Listing 1 shows the result of the query. And there (in Listing 1) John sees it—both sessions are trying to update the same row.
Unless session 254 commits or rolls back, session 270 will continue to wait for the lock. He explains this to Bill, who, considerably less irate now, decides that something in the application has gone awry and asks John to kill session 254 and release the locks. Code Listing 1: V$SESSION and V$SQL query finds lock SID SQLTEXT - - 270 update accounts set balance = balance - 750 where accountno = 333 254 update accounts set balance = balance - 1000 where accountno = 333 Wait Classes After John kills the blocking session, Bill's session continues but is very slow.
John decides to check for other problems in the session. Again, he checks for any other wait events, but this time he specifically checks Bill's session. In Oracle Database 10g, wait events are divided into various wait classes, based on their type.
The grouping of events lets you focus on specific classes and exclude nonessential ones such as idle events. John issues the following against the V$SESSIONWAITCLASS view: select waitclassid, waitclass, totalwaits, timewaited from v$sessionwaitclass where sid = 270; The output, shown in Listing 2, shows the wait classes and how many times the session has waited for events in each class. It tells John that application-related waits such as those due to row locks have occurred 17,760 times, for a total of 281,654 centiseconds (cs)—hundredths of a second—since the instance started.
John thinks that this TIMEWAITED value is high for this session. He decides to explore the cause of these waits in the application wait class. The times for individual waits are available in the V$SYSTEMEVENT view. He issues the following query to identify individual waits in the application wait class (class id ): Code Listing 2: Waits summarized by wait classes WAITCLASSID WAITCLASS TOTALWAITS TIMEWAITED - - - - Other 7 Application 840 Configuration 834 27507 Concurrency 1599 400367 Commit Idle 5153315 Network 254534 3767 User I/O 2 System I/O 1 select event, totalwaits, timewaited from v$systemevent e, v$eventname n where n.eventid = e.eventid and waitclassid =; Listing 3 shows the output of this query. It shows that lock contentions (indicated by the event enq: TX - row lock contention) constitute the major part of the waiting time in the application wait class. This concerns John.
Is it possible that a badly written application made its way through to the production database, causing these lock contention problems? Code Listing 3: Waits in a specific wait class—'application' EVENT TOTALWAITS TIMEWAITED - - - enq: RO - fast object reuse 5 24 enq: TX - row lock contention 2275 280856 SQL.Net break/reset to client 15696 822 Being the experienced DBA that he is, however, John does not immediately draw that conclusion. The data in Listing 3 merely indicates that the users have experienced lock-contention-related waits a total of 2,275 times, for 280,856 cs. It is possible that mostly 1- or 2-cs waits and only one large wait account for the total wait time, and in that case, the application isn't faulty.
A single large wait may be some freak occurrence skewing the data and not representative of the workload on the system. How can John determine whether a single wait is skewing the data? Oracle 10g provides a new view, V$EVENTHISTOGRAM, that shows the wait time periods and how often sessions have waited for a specific time period. He issues the following against V$EVENTHISTOGRAM: select waittimemilli bucket, waitcount from v$eventhistogram where event = 'enq: TX - row lock contention'; The output looks like this: BUCKET WAITCOUNT - - 1 252 2 0 4 0 8 0 16 1 32 0 64 4 128 52 256 706 512 392 10 7 4096 843 The V$EVENTHISTOGRAM view shows the buckets of wait times and how many times the sessions waited for a particular event—in this case, a row lock contention—for that duration. For example, sessions waited 252 times for less than 1 millisecond (ms), once less than 16 ms but more than 1 ms, and so on. The sum of the values of the WAITCOUNT column is 2,275, the same as the value shown in the event enq: TX - row lock contention, shown in Listing 3.
The V$EVENTHISTOGRAM view shows that the most waits occurred in the ranges of 256 ms, 512 ms, and 4,096 ms, which is sufficient evidence that the applications are experiencing locking issues and that this locking is the cause of the slowness in Bill's session. Had the view showed numerous waits in the 1-ms range, John wouldn't have been as concerned, because the waits would have seemed normal.
Time Models Just after John explains his preliminary findings to Bill, Lora walks in with a similar complaint: Her session SID 355 is very slow. Once again, John looks for the events the session is waiting for, by issuing the following query against the V$SESSION view: select event, secondsinwait, waittime from v$session where sid = 355; The output, shown in Listing 4, shows a variety of wait events in Lora's session, including latch contention, which may be indicative of an application design problem. But before he sends Lora off with a prescription for an application change, John must support his theory that bad application design is the cause of the poor performance in Lora's session. To test this theory, he decides to determine whether the resource utilization of Lora's session is extraordinarily high and whether it slows not only itself but other sessions too. Code Listing 4: Waits experienced by a specific session EVENT SECONDSINWAIT WAITTIME - - - latch: cache buffers lru chain 172 0 latch: checkpoint queue latch 2 0 latch: cache buffers chains 607 0 buffer busy waits 500 0 db file sequential read 30247 0 db file scattered read 887 0 In the Time Model interface of Oracle Database 10g, John can easily view details of time spent by a session in various activities. He issues the following against the V$SESSTIMEMODEL view: select statname, value from v$sesstimemodel where sid = 355; The output, shown in Listing 5, displays the time (in microseconds) spent by the session in various places. From this output, John sees that the session spent 503,996,336 microseconds parsing (parse time elapsed), out of a total of 878,088,366 microseconds on all SQL execution (sql execute elapsed time), or 57 percent of the SQL execution time, which indicates that a cause of this slowness is high parsing.
John gives Lora this information, and she follows up with the application design team. List of Oracle 10g Hints for the Oracle Optimizer so that you can dictate the execution plan of a query/statement. Module Objectives Purpose In this module, you will learn how to use LogMiner to analyze your redo log files so that you can logically recover your database. General Information Note: System privileges are privileges that do not relate to a specific schema or object. General Information Note: While the data dictionary objects are named tab, as in table, the privileges that can be granted and revoked extend to other object types including functions, packages, and procedures. /www/doc/sql/usefulmisc.sql - $Id: useful-misc.sql,v 1.1.3.1 2001/08/29 05:31:19 andy Exp $ - - Useful stuff culled largely from Joe Trezzo's Oracle PL/SQL book. See also the other useful.sql files, for the longer code.
- by [email protected], 2000-07-17 - Note that a lot (but not all) of this stuff is already covered by - the current version of Cassandracle, but I haven't made any attempt - to compare the two or pare down this list. References: - - Trezzo, Joseph C.; Oracle PL/SQL Tips and Techniques; - Osborne/McGraw-Hill, 1999, www.osborne.com; ISBN: 0-07-882439-9. Very useful book, though fat and poorly organized. - - Code from Trezzo's book. - Greenspun, Philip; 'Tips for Using Oracle'; - - Useful Oracle shells: - $ORACLEHOME/bin/sqlplus - $ORACLEHOME/bin/svrmgrl - $ORACLEHOME/bin/lsnrctl - At aD, do NOT use lsnrctl to restart the listener!
Instead, use: - sudo /etc/init.d/ora8-net8 - If you do not, Oracle will not be able to find any external - libraries you may be using. (Something to do with Environment - variables, but I haven't looked into it.) - Oracle Error Messgage Index: - - You probably want to put these in your login.sql file. (When you start up sqlplus, it will execute any login.sql file it - find in your current directory.) set linesize 200 set pagesize 1000 set serveroutput on size 1000000 begin dbmsoutput.enable(1000000); end; / - To turn off interpretation of & in Sqlplus: set def off - To retrieve a view definition from the database: - Sqlplus truncates long type columns, so do: - select VIEWNAME, TEXTLENGTH from userviews where viewname = upper('yourviewnamehere'); - - Then, do 'set long n' in Sqlplus. Make sure n is = TEXTLENGTH. Set long 1000; select TEXT from userviews where viewname = upper('yourviewnamehere'); -. Regular Expressions. The OWAPATTERN pl/sql regexp package is part of the Oracle PL/SQL Web - Toolkit.
Install the whole toolkit with: - $ORACLEHOME/webdb30/admin/plsql/owa/owains.sql - or read about OWAPATTERN here: - - $ORACLEHOME/webdb30/admin/plsql/owa/pubpat.sql - $ORACLEHOME/webdb30/admin/plsql/owa/privpat.sql - Find the table, column, etc. For a constraint. Select uc.constraintname,uc.tablename,ucc.columnname,uc.SEARCHCONDITION from userconstraints uc, userconscolumns ucc where uc.constraintname = ucc.constraintname and ucc.columnname = 'LIMITPRICE' -and uc.tablename in ('ORDERS','ORDERSAUDIT'); - Get list of invalid objects. 207, 451 select STATUS,OBJECTTYPE,CREATED,LASTDDLTIME,TIMESTAMP,OBJECTNAME from userobjects -from dbaobjects where status!= 'VALID' order by timestamp -objectname; - Get list of disabled triggers. Trezzo pg.
452 - File: 95.sql SELECT owner, triggername, triggertype, triggeringevent, tableowner '.' tablename FROM dbatriggers WHERE status 'ENABLED' - AND owner = 'PLSQLUSER' ORDER BY owner, triggername; - According to Xuequn (Robert) Xu [email protected] 2000/12/01 in: - - The below queries do NOT show locks on packages. However you can - check the v$access view like this: select username, osuser, process, type, terminal, tochar(logontime, 'YYYY-MM-DD HH24:MI') as logontime, (sysdate-logontime).24 as hoursago from v$session order by hoursago desc, process; - Find Oracle locks: - Originally from Philip's Oracle tips document.
Usually very fast, but I've seen it hang on a really hosed Oracle - with hundreds of resource locks. Set linesize 180 column username format a18 column program format a32 column machine format a12 column nseconds format a6 select s.username,s.sid,s.serial#,ltrim(w.secondsinwait) as nseconds,process,machine,terminal,program from v$session s, v$sessionwait w where s.sid = w.sid and s.sid in (select sid from v$lock where lmode=6) order by s.username,s.sid,s.serial#; - alter system kill session 'SID,SERIAL#'; - Find Oracle locks and what they're doing. Set linesize 180 column username format a18 column program format a32 column machine format a12 column nseconds format a6 select s.username,s.sid,s.serial#,ltrim(w.secondsinwait) as nseconds,process,machine,terminal,program,sql.sqltext from v$session s, v$sessionwait w,v$sqltext sql where s.sid = w.sid and s.sid in (select sid from v$lock where lmode=6) and sql.address = s.sqladdress and sql.hashvalue = s.sqlhashvalue and upper(username) like 'MUNIVERSAL%' order by s.username,s.sid,s.serial#,sql.piece; - See which users are waiting for a lock. This is fast. SELECT s.username, s.serial#, s.lockwait FROM v$session s where s.lockwait is not null order by s.lockwait, s.username; - Who's waiting for a lock, and what SQL is he executing? - This is fast. SELECT s.username, s.serial#, s.lockwait,sql.sqltext FROM v$session s,v$sqltext sql where s.lockwait is not null and sql.address = s.sqladdress and sql.hashvalue = s.sqlhashvalue and upper(username) like 'MUNIVERSAL%' order by s.lockwait, s.username,sql.piece; - What are users currently doing?
Set linesize 180 SELECT s.username, s.serial#, sql.sqltext FROM v$session s, v$sqltext sql WHERE sql.address = s.sqladdress AND sql.hashvalue = s.sqlhashvalue -and upper(s.username) like 'USERNAME%' order by s.username,s.sid,s.serial#,sql.piece; - What users are currently locked, and what are they doing? - Really slow, I never let it finish. Trezzo pg. 475 - File: 921.sql SELECT s.username, s.serial#, l.id1, st.sqltext FROM v$session s, v$lock l, v$sqltext st - It's the joining v$session to v$lock that seems to really slow things down. WHERE s.lockwait = l.kaddr AND st.address = s.sqladdress AND st.hashvalue = s.sqlhashvalue; - What users are currently locked? - Really slow.
SELECT s.username, s.serial#, l.id1 FROM v$session s, v$lock l WHERE s.lockwait = l.kaddr; - Who is CAUSING a user to be locked? - Really slow - took almost 8 minutes to return 'no rows selected'. Trezzo pg. 476 - File: 922.sql SELECT a.serial#, a.sid, a.username, b.id1, c.sqltext FROM v$session a, v$lock b, v$sqltext c WHERE b.id1 IN ( SELECT DISTINCT e.id1 FROM v$session d, v$lock e WHERE d.lockwait = e.kaddr ) AND a.sid = b.sid AND c.hashvalue = a.sqlhashvalue AND b.request = 0; - Check init.ora parameters. Trezzo pg.
453 - File: 96.sql SELECT name, value, isdefault, issesmodifiable, issysmodifiable FROM v$parameter ORDER BY name; - Check some particular DBMSJOB related init.ora parameters. Trezzo pg. 576 - File: 129.sql SELECT name, value, isdefault, issesmodifiable, issysmodifiable FROM v$parameter WHERE UPPER(name) IN ('JOBQUEUEPROCESSES','JOBQUEUEINTERVAL') ORDER BY NAME; - What database objects are being accessed right now? - Returns a potentially massive list of stuff. Trezzo pg. 474 - File: 920.sql SELECT s.sid, s.username, a.owner, a.object, a.type FROM v$session s, v$access a WHERE s.sid = a.sid; - What statements are executing in each rollback segment? - Trezzo pg.
Comments are closed.
|
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |