inner side

보통 매우 큰 인덱스를 Range/Full/Skip scan을 한 후 테이블 Access를 수항하면, 엄청난 양의 Single Block Read가 발생합니다. 

클러스터링 Fact에 따라, Index Leaf Block 의 Rowid 갯수에 따라 Table lookup 발생하면서 Table Block Read가 발생합니다. (내 예측이 맞았는듯.. 인덱스는 이진 트리로 구성하고..거기에 실제 파일 데이터를 연결 리스트or 리스트

형식으로 배치한듯..)
순차적 수행 플랜의 경우, 쿼리 성능은 Single Random table Read가 얼마나 빠른가에 좌우 되었습니다.

만약 단일 블록 하나를 읽는데 5ms 이 필요하다면, 1000 block을 읽는데 약 5초 정도가 소요됩니다. 
다만 여기에서도 스토리지 시스템이 동시 IO 요청을 처리할 수 있으며, 최종 사용자 세션이 필요한 블록을 동시에 수행하는 어떤 방법이나, 병렬로 처리할 수 잇따면, 
OS와 스토리지와의 연결 상에서 부하가 될 수 있겠지만 사용자는 더 짧은 시간에 결과를 받아 볼 수 있습니다.

오라클은 어떻게 IO를 최적화했는가?

현재까지 제가 아는 한, 오라클은 12.1 버전 이전에서도 몇가지 교묘한 방법으로 IO를 다루어 왔습니다. 아래는 그 몇몇가지 방법입니다.

- Nested Loop Join 에해서 오라클에 사용자에 대한 몇가지 전략이 사용됨 : NL-Join Batching 과 Table Access를 Join 밖으로 이동시켰습니다.

     --NL-JOIN Batching (http://docs.oracle.com/cd/E11882_01/server.112/e41573/optimops.htm#PFGRF94642)
     
     11g에서는 Physical IO의 지연을 감소시키기 위하여 NL Join 에 대한 새로운 방식을 소개합니다. 
     Table Block 이나, index Block이 Buffer Cache에 존재하지 않지만, Join 에 필요한 경우 Physical IO가 필요합니다. 
     오라클 데이터베이스 11g는 한번에 하나씩 처리하는 대신 여러 Physical IO 요청을 묶어 Vector IO를 사용하여 처리할 수 있습니다.
     

이전 버전의 Exeution Plan에서 한 line으로 나타났던 Nested Loop Join의 Row source가 두번의 Nested Loop Join Row source로 나타나게 되었습니다. 
     이 경우, Oracle 데이터베이스는 첫번째 NL Join Row source를 Inner 쪽 인덱스와 Outer 쪽 Table에 Join 으로 할당합니다. 
     두번째 Row Source는 index에 저장된 Rowid를 포함한 첫번째 join 결과 set과 Inner 쪽 Table사이의 Join 에 할당합니다.
     
     즉, 
     SELECT e.first_name, e.last_name, e.salary, d.department_name
      FROM hr.employees e, hr.departments d
       WHERE d.department_name IN ('Marketing', 'Sales') <-어제 봤던 부분..  IN(a or b)키워드= 풀스캔..
       AND e.department_id = d.department_id;
       
    이 쿼리의 플랜은 
      ------------------------------------------------------------------------------------------------
      | Id  | Operation                    | Name              | Rows  | Bytes | Cost(%CPU)| Time      |
      -------------------------------------------------------------------------------------------------
      |   0 | SELECT STATEMENT             |                   |    19 |   722 |     3   (0)| 00:00:01 |
      |   1 |  NESTED LOOPS                |                   |       |       |            |          |
      |   2 |   NESTED LOOPS               |                   |    19 |   722 |     3   (0)| 00:00:01 |
      |*  3 |    TABLE ACCESS FULL         | DEPARTMENTS       |     2 |    32 |     2   (0)| 00:00:01 |
      |*  4 |    INDEX RANGE SCAN          | EMP_DEPARTMENT_IX |    10 |       |     0   (0)| 00:00:01 |
      |   5 |   TABLE ACCESS BY INDEX ROWID| EMPLOYEES         |    10 |   220 |     1   (0)| 00:00:01 |
      -------------------------------------------------------------------------------------------------
 
      Predicate Information (identified by operation id):
      ---------------------------------------------------
         3 - filter("D"."DEPARTMENT_NAME"='Marketing' OR "D"."DEPARTMENT_NAME"='Sales')
         4 - access("E"."DEPARTMENT_ID"="D"."DEPARTMENT_ID")
         
         
         
        로 수행됩니다. 

http://prayyou.egloos.com/viewer/1799600

*******************************************************************

statement vs preparestatement

http://translate.googleusercontent.com/translate_c?depth=1&hl=ko&prev=/search%3Fq%3Dstatement%2Bvs%2Bpreparedstatement%26newwindow%3D1%26espv%3D210%26es_sm%3D93&rurl=translate.google.co.kr&sl=en&u=http://stackoverflow.com/questions/3271249/difference-between-statement-and-preparedstatement&usg=ALkJrhg7XYWCDIhZNBVwbSd1ll4UI_YUqg

DiverManger.getConnection() 에서 하는 짓..

//  Worker method called by the public getConnection() methods.

548

    private static Connection getConnection(

549

        String url, java.util.Properties info, ClassLoader callerCL) throws SQLException {

550

        /*

551

         * When callerCl is null, we should check the application's

552

         * (which is invoking this class indirectly)

553

         * classloader, so that the JDBC driver class outside rt.jar

554

         * can be loaded from here.

555

         */

556

        synchronized(DriverManager.class) {

557

          // synchronize loading of the correct classloader.

558

          if(callerCL == null) {

559

              callerCL = Thread.currentThread().getContextClassLoader();

560

           }

561

        }

562

563

        if(url == null) {

564

            throw new SQLException("The url cannot be null", "08001");

565

        }

566

567

        println("DriverManager.getConnection(\"" + url + "\")");

568

569

        // Walk through the loaded registeredDrivers attempting to make a connection.

570

        // Remember the first exception that gets raised so we can reraise it.

571

        SQLException reason = null;

572

573

        for(DriverInfo aDriver : registeredDrivers) {

574

            // If the caller does not have permission to load the driver then

575

            // skip it.

576

            if(isDriverAllowed(aDriver.driver, callerCL)) {

577

                try {

578

                    println("    trying " + aDriver.driver.getClass().getName());

579

                    Connection con = aDriver.driver.connect(url, info);

580

                    if (con != null) {

581

                        // Success!

582

                        println("getConnection returning " + aDriver.driver.getClass().getName());

583

                        return (con);

584

                    }

585

                } catch (SQLException ex) {

586

                    if (reason == null) {

587

                        reason = ex;

588

                    }

589

                }

590

591

            } else {

592

                println("    skipping: " + aDriver.getClass().getName());

593

            }

594

595

        }

596

597

        // if we got here nobody could connect.

598

        if (reason != null)    {

599

            println("getConnection failed: " + reason);

600

            throw reason;

601

        }

602

603

        println("getConnection: no suitable driver found for "+ url);

604

        throw new SQLException("No suitable driver found for "+ url, "08001");

605

    }

java.sql 
인터페이스 ResultSet

모든 슈퍼 인터페이스:

Wrapper

기존의 서브 인터페이스의 일람:

CachedRowSet , FilteredRowSet , JdbcRowSet , JoinRowSet , RowSet , SyncResolver , WebRowSet

<pre>public interface ResultSet

extends Wrapper

</pre>

데이타베이스의 결과 세트를 나타내는 데이터의 테이블로, 일반적으로, 데이타베이스에 조회하는 문장을 실행하는 것에 의해 생성됩니다.

ResultSet 객체는, 커서가 데이터의 현재의 행을 지시하도록(듯이) 유지합니다. 초기 상태에서는, 커서는 최초의 행의 선두에 배치됩니다. next 메소드에 의해, 커서는 다음의 행으로 이동합니다. next 는,ResultSet 객체에 그 이상행이 없는 경우에 false 를 돌려주므로,while 루프에 사용해 결과 세트를 반복 처리 할 수가 있습니다.  

디폴트의 ResultSet 객체는 갱신 불가로, 커서는 순서 방향에게만 나아갑니다. 따라서 이 객체는, 최초의 행으로부터 마지막 행으로 향해 1 회만 실행할 수 있습니다. 스크롤 또는 갱신, 혹은 그 양쪽 모두가 가능한 ResultSet 객체를 생성할 수 있습니다. con 가 유효한 Connection 객체인 다음의 코드 fragment는, 스크롤 가능해 외로 행해진 갱신을 반영하지 않는 결과 세트, 및 갱신 가능한 결과 세트의 작성 방법을 나타내고 있습니다. 다른 옵션에 대해서는,ResultSet 의 필드를 참조해 주세요.

Statement stmt = con.createStatement(ResultSet.TYPE_SCROLL_INSENSITIVE,ResultSet.CONCUR_UPDATABLE);ResultSet rs = stmt.executeQuery("SELECT a, b FROM TABLE2");// rs will be scrollable, will not show changes made by others,// and will be updatable 

아래 java 도큐의 resultset 명세중.. '렬명' 이 alias(별칭) 과 동일한 의미.

getter 메소드에서는, JDBC 드라이버가 기본적인 데이터를 getter 메소드로 지정된 Java 형으로 변환해, 적절한 Java 의 값을 돌려줍니다. JDBC 스펙에는,ResultSet getter 메소드로 가능한 SQL 형으로부터 Java 형에의 매핑을 나타내는 테이블이 있습니다.  

getter 메소드에의 입력으로서 사용되는 렬명에서는, 대문자와 소문자는 구별되지 않습니다. 렬명으로 getter 메소드가 불려 가 복수의 열이 같은 이름을 가지는 경우는, 최초로 일치하는 열의 값이 돌려주어집니다. 렬명의 옵션은, 결과 세트로 생성되는 SQL 쿼리로 렬명이 사용되는 경우에 사용되도록(듯이) 설계되고 있습니다. 쿼리로 명시적으로 명명되지 않는 열의 경우에는, 열번호를 사용하는 것이 가장 좋은 방법입니다. 렬명을 사용하는 경우, 프로그래머는 목적의 열을 일의에 가리키는 것을 보증하도록 주의해 주세요. 이것은, SQL AS 절을 사용해 실현될 수 있습니다

포지션 1: 서버 클라이언트 개발 팀원 및 팀장 

업무내용 

:클라이언트 어플리케이션 개발팀

- GEM(Globally Executable MHP)/BD-J 표준에 따른 Java 어플리케이션 개발 
- Android 환경에서 동작하는 드리머 클라이언트 어플리케이션 개발  

업무내용 

- 서버 서비스 어플리케이션 개발팀원

- server-side application developer
- Cloud 기반 Server-side Java 어플리케이션 개발 
- 안정적이고 효율적으로 동작하는 서버 시스템 개발

주요 업무
1) Blu-ray, networked/IP-based media players등의 TV connected device에서 동작하는 드리머 서비스의 back-end system 개발. 
2) cloud 기반으로 전세계를 대상으로 서비스할 드리머 서버시스템의 지속적인 성능향상 작업

자격조건 Knowledge : .
 - Deep understanding of Java servlet/Jsp
 - Deep understanding of RDBMS.
 - Deep understanding of open standard based development

Skill : 
 -  Expert in OO design and implementation using Java
 -  Expert in java networking application development.
 -  Expert in enterprise application architecture.

업무내용 

- 서버 서비스 어플리케이션 개발팀원

- server-side application developer
- Cloud 기반 Server-side Java 어플리케이션 개발 
- 안정적이고 효율적으로 동작하는 서버 시스템 개발

주요 업무
1) Blu-ray, networked/IP-based media players등의 TV connected device에서 동작하는 드리머 서비스의 back-end system 개발. 
2) cloud 기반으로 전세계를 대상으로 서비스할 드리머 서버시스템의 지속적인 성능향상 작업

자격조건 Knowledge : .
 - Deep understanding of Java servlet/Jsp
 - Deep understanding of RDBMS.
 - Deep understanding of open standard based development

Skill : 
 -  Expert in OO design and implementation using Java
 -  Expert in java networking application development.
 -  Expert in enterprise application architecture.

Most of the time, client code cannot do anything about SQLExceptions. Do not hesitate to convert them into unchecked exceptions. Consider the following piece of code:

public void dataAccessCode()

{    

try{        ..some code that throws SQLException    }

catch(SQLException ex)

{        ex.printStacktrace();    }}

This catch block just suppresses the exception and does nothing. The justification is that there is nothing my client could do about an SQLException. How about dealing with it in the following manner?

public void dataAccessCode()

{    

try{        ..some code that throws SQLException    }

catch(SQLException ex){        

throw new RuntimeException(ex);    }}<--그젠가 상위클래스던,인터페이스던.. abstract으로 사용자가 재정의

해야할 Thread의 run() 같은 메서드에서 예외를 throw해야할 상황이 있을때 선생님께서 런타입으로 캐스팅

해서 넘기면 된다고 말씀하심.

This converts SQLException to RuntimeException. If SQLException occurs, the catch clause throws a newRuntimeException. The execution thread is suspended and the exception gets reported. However, I am not corrupting my business object layer with unnecessary exception handling, especially since it cannot do anything about an SQLException. If my catch needs the root exception cause, I can make use of thegetCause() method available in all exception classes as of JDK1.4.

If you are confident that the business layer can take some recovery action when SQLException occurs, you can convert it into a more meaningful checked exception. But I have found that just throwingRuntimeException suffices most of the time.

What is wrong with following code?

public class DuplicateUsernameException    extends Exception {}

It is not giving any useful information to the client code, other than an indicative exception name. Do not forget that Java Exception classes are like other classes, wherein you can add methods that you think the client code will invoke to get more information.

We could add useful methods to DuplicateUsernameException, such as:

public class DuplicateUsernameException    extends Exception  <-마찬가지로 배운것~(주문에 대한

재고수량 정보 리턴)

{    public DuplicateUsernameException         (String username){....} 

   public String requestedUsername(){...}    

public String[] availableNames(){...}}

The new version provides two useful methods: requestedUsername(), which returns the requested name, and availableNames(), which returns an array of available usernames similar to the one requested. The client could use these methods to inform that the requested username is not available and that other usernames are available. But if you are not going to add extra information, then just throw a standard exception:

throw new Exception("Username already taken");

Best Practices for Using Exceptions

The next set of best practices show how the client code should deal with an API that throws checked exceptions.

1. Always clean up after yourself <- 내가예전에 고민했던 결론 (자기의 업무 영역에 따른 책임분할)

If you are using resources like database connections or network connections, make sure you clean them up. If the API you are invoking uses only unchecked exceptions, you should still clean up resources after use, with try - finally blocks.

public void dataAccessCode(){

    Connection conn = null; 

   try{        conn = getConnection();    

    ..some code that throws SQLException    

}catch(SQLException ex)

{        ex.printStacktrace();    }

 finally{        DBUtil.closeConnection(conn);    }}

class DBUtil{    public static void closeConnection        

(Connection conn){        try{            conn.close();        } 

catch(SQLException ex){            

logger.error("Cannot close connection");          

  throw new RuntimeException(ex);        }   

 }}

DBUtil is a utility class that closes the Connection. The important point is the use of finally block, which executes whether or not an exception is caught. In this example, the finally closes the connection and throws a RuntimeException if there is problem with closing the connection.

2. Never use exceptions for flow control <- 내가 요 유혹에 빠지기도 했었음..

Generating stack traces is expensive and the value of a stack trace is in debugging. In a flow-control situation, the stack trace would be ignored, since the client just wants to know how to proceed.

In the code below, a custom exception, MaximumCountReachedException, is used to control the flow.

public void useExceptionsForFlowControl() 

{    

try {        while (true) 

{            increaseCount();        }   

 } catch (MaximumCountReachedException ex) 

{    }    //Continue execution

}

public void increaseCount()    throws MaximumCountReachedException 

{    if (count >= 5000)        throw new MaximumCountReachedException();

}

The useExceptionsForFlowControl() uses an infinite loop to increase the count until the exception is thrown. This not only makes the code difficult to read, but also makes it slower. Use exception handling only in exceptional situations.

3. Do not suppress or ignore exceptions <-몇일 전 까지 core api익셉션을 무조건 누르려고 했었음(현재는 발생

When a method from an API throws a checked exception, it is trying to tell you that you should take some counter action. If the checked exception does not make sense to you, do not hesitate to convert it into an unchecked exception and throw it again, but do not ignore it by catching it with {} and then continue as if nothing had happened.

4. Do not catch top-level exceptions <-- 노력해볼꼐요 -_-;  구현 과정중에 이것저것 신경쓸께 너무 많아져서

Unchecked exceptions inherit from the RuntimeException class, which in turn inherits from Exception. By catching the Exception class, you are also catching RuntimeException as in the following code:

try{..}catch(Exception ex){}

The code above ignores unchecked exceptions, as well.

5. Log exceptions just once

Logging the same exception stack trace more than once can confuse the programmer examining the stack trace about the original source of exception. So just log it once.