数据库的用户表空间不足,用户表空间不是会自动增加么,那么往这个表空间上的表插入大量数据,这些表会被锁住么?
数据库两个Job,定为同时进行,大概同时对一张表进行写操作,会出现此表被锁么?
(数据库的Job执行失败,有异常(异常未处理的话),那这个Job下次执行会是什么时候,会再次执行先前那个时间的JOB么?)
另外如果应用程序连接数据库和JOB同时对一张表写操作,会导致死锁么,如果会的话,那要怎么避免
如果以上情况不足以导致表被锁住(都快一天了,手动执行这个procedure只需要10分钟,不会锁表这么长时间),
那么谁知道表被锁的所有可能原因(不可能导致死锁的,即自己没有遇到过的,请不要列出,以免混淆视听,谢谢)请高人指点,分不够再加,回答问题之一正确的或指出有回答错误的(滥竽充数的),一律给分

解决方案 »

  1.   

    表空间是不是自动增长的,要看你建表空间的时候如何指定的.一般插入不会锁表先确定一下你的表空间是不是自动增长的:
    wf@ORA10> select dbms_metadata.get_ddl('TABLESPACE','USERS') from dual;DBMS_METADATA.GET_DDL('TABLESPACE','USERS')
    -------------------------------------------------------------------------  CREATE TABLESPACE "USERS" DATAFILE
      'D:\ORACLE\PRODUCT\10.2.0\ORADATA\ORA10\USERS01.DBF' SIZE 5242880
      AUTOEXTEND ON NEXT 1310720 MAXSIZE 32767M
      LOGGING ONLINE PERMANENT BLOCKSIZE 8192
      EXTENT MANAGEMENT LOCAL AUTOALLOCATE SEGMENT SPACE MANAGEMENT AUTO
       ALTER DATABASE DATAFILE
      'D:\ORACLE\PRODUCT\10.2.0\ORADATA\ORA10\USERS01.DBF' RESIZE 10485760
      

  2.   

    dba用户,用的Oracle默认的Users表空间,是自动增长的
      

  3.   

    Oracle锁表
      

  4.   

    1.user表空间会自动增加
    2.job同时执行会表锁
    3.job出现异常,下次如何执行取决于你的程序额
    4. 应用程序与job对一张表操作,会导致死锁,
    避免的方法是事务控制。
    检查死锁SELECT   bs.username "Blocking User", bs.username "DB User",
             ws.username "Waiting User", bs.SID "SID", ws.SID "WSID",
             bs.serial# "Serial#", bs.sql_address "address", 
             bs.sql_hash_value "Sql hash", bs.program "Blocking App",
             ws.program "Waiting App", bs.machine "Blocking Machine",
             ws.machine "Waiting Machine", bs.osuser "Blocking OS User",
             ws.osuser "Waiting OS User", bs.serial# "Serial#",
             ws.serial# "WSerial#", 
             DECODE (wk.TYPE,
                     'MR', 'Media Recovery',
                     'RT', 'Redo Thread', 
                     'UN', 'USER Name',
                     'TX', 'Transaction',
                     'TM', 'DML', 
                     'UL', 'PL/SQL USER LOCK',
                     'DX', 'Distributed Xaction',
                     'CF', 'Control FILE', 
                     'IS', 'Instance State',
                     'FS', 'FILE SET',
                     'IR', 'Instance Recovery',  
                     'ST', 'Disk SPACE Transaction',
                     'TS', 'Temp Segment',
                     'IV', 'Library Cache Invalidation', 
                     'LS', 'LOG START OR Switch',
                     'RW', 'ROW Wait',
                     'SQ', 'Sequence Number',  
                     'TE', 'Extend TABLE',
                     'TT', 'Temp TABLE',
                     wk.TYPE 
                    ) lock_type,
             DECODE (hk.lmode,
                     0, 'None',
                     1, 'NULL', 
                     2, 'ROW-S (SS)',
                     3, 'ROW-X (SX)',
                     4, 'SHARE', 
                     5, 'S/ROW-X (SSX)',
                     6, 'EXCLUSIVE',
                     TO_CHAR (hk.lmode) 
                    ) mode_held,
             DECODE (wk.request,
                     0, 'None',
                     1, 'NULL', 
                     2, 'ROW-S (SS)',
                     3, 'ROW-X (SX)',
                     4, 'SHARE', 
                     5, 'S/ROW-X (SSX)',
                     6, 'EXCLUSIVE',
                     TO_CHAR (wk.request) 
                    ) mode_requested,
             TO_CHAR (hk.id1) lock_id1, TO_CHAR (hk.id2) lock_id2,
             DECODE
                (hk.BLOCK,
                 0, 'NOT Blocking',         /**//* Not blocking any other processes */ 
                 1, 'Blocking',             /**//* This lock blocks other processes */ 
                 2, 'Global',          /**//* This lock is global, so we can't tell */ 
                 TO_CHAR (hk.BLOCK)
                ) blocking_others
        FROM v$lock hk, v$session bs, v$lock wk, v$session ws
       WHERE hk.BLOCK = 1
         AND hk.lmode != 0 
         AND hk.lmode != 1
         AND wk.request != 0
         AND wk.TYPE(+) = hk.TYPE 
         AND wk.id1(+) = hk.id1
         AND wk.id2(+) = hk.id2
         AND hk.SID = bs.SID(+) 
         AND wk.SID = ws.SID(+)
         AND (bs.username IS NOT NULL)
         AND (bs.username <> 'SYSTEM')  
         AND (bs.username <> 'SYS')
    ORDER BY 1;
      

  5.   


    1,除了以上几位的看法,我觉得还有一种可能就是:表空自增的大小<一次批量导入数据所占据的容量,比方说,表空间一次增长500M,但是你一次批量导入的数据占据空间600M,那么就有可能出现楼主描述的问题。2,楼主最好把alert日志信息贴下,大家帮你分析下。
      

  6.   

    ls说的很有道理,不过现场库连不上了,后来发现现场的Users表空间文件不是自动增长的,
    只有6G,后来改成8G,并设置成可自动增长的重启数据库后,JOB继续上次没有成功的时间,执行成功了,但之后第二天再次执行到一半就把表锁住不走了
    两次数据库都down掉了,会有影响么另外我刚试了下,同时启动两个相同JOB不会造成死锁,操作也是交互的,一个JOB的操作总是等待另一个JOB执行完对那张表操作后,就继续了,只是一个JOB还是会延迟一段时间。还有个问题,EMD_MAINTENANCE.EXECUTE_EM_DBMS_JOB_PROCS(),这个JOB会影响我的JOB操作么
      

  7.   

    1.数据库两个Job,定为同时进行,大概同时对一张表进行写操作,会出现此表被锁么? 有dml,表上当然有锁。表上是3级tm锁。2.(数据库的Job执行失败,有异常(异常未处理的话),那这个Job下次执行会是什么时候,会再次执行先前那个时间的JOB么?)一个job到点执行失败,重新执行间隔为interval值,重试16次后停止。
     
    3.另外如果应用程序连接数据库和JOB同时对一张表写操作,会导致死锁么,如果会的话,那要怎么避免 要看你具体操作内容,死锁出现的时候也就是结束的时候。看你的描述,只是有等待而已。
    解决方式是从业务逻辑入手。