제2의 비엔지니어 인생관을 꿈꾸며

Posted
Filed under Study
IT PRO로 밥벌이 하다 어찌어찌하여 DBA로 변신하여 중국에 프로젝트에 몇개월 일하게 되었습니다. 필자는 VPN을 자주 사용합니다. 자주 사용하는 이유는 SMB 파일 송수신을 편하게 하기 위한 방법이 우선이기도 하고 Hyper-V 의 회사망에 있는 여러대 서버를 터미널로 접속하기 귀찮아서 그냥 VPN으로 붙여서 로컬 노트북으로 관리할때?가 많아서입니다.
그리고 보통 회사망에서는 방화벽이 있어서 까탈스럽게 보안을 중요시 하는데는 왠간한 아웃바운드 포트는 다 차단해버리는게 문제이기도 합니다. 뭐 그냥 일만 하라는 소리죠. 그리고 웹사이트 로그 기록도 남기 때문에 필자는 그런 기록을 남기고 싶어하지 않아 별도로 SSL VPN을 사용합니다. 보통 회사에서는 뻘짓? 하지말라는 보안각서도 쓰기에 그냥 필수일수밖에 없습니다.
그래서 필자는 한국에 개인 인프라가 좀 있는 관계로 여러대의 가상화서버와 고정 및 유동아이피에 기가빗 라인이 있었기에 최근에 분석했던 내용을 포스팅하겠습니다.
중국.
인터넷 검열 빡셉니다. 구글, 페이스북, 티스토리,라인 및 카카오톡은 일부, 한국사람이 사용하던 모든것들이 그냥 다 못쓴다고 생각하면 됩니다. 답답하죠. 많이 답답합니다.
그래서 전 처음부터 PPTP/L2TP 를 스맛폰에서 붙여서 쓰기 시작했습니다. 직원들도 많기도 해서 계정을 많이 만들고 배포했죠. 딱 1주일 만에 블랙 되었습니다. 그때 감잡았습니다. 검열한다는것을요...
분석했습니다. 왠간한 VPN은 분명 다 스니핑 될것이다. PPTP/L2TP는 못쓴다는걸 알고 있어서 SSL 방식을 사용하기로 했습니다. 윈도우서버의 SSTP VPN은 443 포트 기본적인 SSL VPN의 정석입니다. 윈도우에 기본 내장되어 있어서 별도의 어플리케이션도 필요 없습니다.
사용자 삽입 이미지

윈도우 비스타/2008서버 시절에 처음에 SSTP VPN이란걸 내놓았습니다. 이게 정말 필요하던 이유가 아무 VPN이나 쓰면 좋은데 GRE47 라우팅 프로토콜이 안열리거나 지원 안되는곳에서는 정말 난감한 경우가 많기 때문입니다. 회사내부에 PPT를 열어야 할경우이거나 데모를 실행해야될 경우 그리고 클라우드에 접속해야될경우 PPTP/L2TP는 안되는곳이 좀 되는게 현실입니다. 그때되서 VPN 안되서 계획이 와르르 무너진다고 생각해보면 아찔하겠죠. 그런걸 MS가 잘 동감했는지 이런 SSTP란것을 선보였습니다. 그당시 이거 구축 못해서 MS 백모 부장님이 기술지원카드 던져주었던 기억이 아직도 새록새록 납니다. 인증서가 있어야되고 클라이언트에도 깔아야되고 기타등등 지금은 구글에 설명 잘나왔지만 그당시에는 그냥 MS만 바라볼수 밖에 없는 현실이였습니다.
사용자 삽입 이미지
기존 RRAS 에서 IIS에서 443 채널을 수신 인증해주고 나머지 라우팅을 처리해주는 기능입니다. 중국에서 차단되지 않는 VPN중 하나입니다. 물론 어플라이언스 기업형 SSL VPN도 차단되지는 않습니다. 그러나 그 VPN은 스마트폰을 지원하지 못한다는 단점이 존재합니다. 별도로 개발을 해야되는거죠. 하지만 SSTP는 앱이 유료/무료가 안드로이드만 배포를 하고 있습니다.
사용자 삽입 이미지
앱은 중국의 방화벽이 차단하는지 안하는지 테스트를 위하여 유료 결재하여 앱을 다운받았습니다. 차단 안하는걸 확인하고는 VPN을 무지 원하는 직원이 무료 apk를 찾아서 다운로드 하였더군요. 난 연구를 위해 결재했는데 왜 왜 왜~!!!
사용자 삽입 이미지

평균 14메가 이상 속도가 나와서 한국에서 사용하는것처럼 똑같다고 할수 있습니다. 한번 맛본 사람은 절대 이맛을 못잊어서 통신이라도 장애가 나면 해결해달라고 불만입니다. 그냥 쓰면서...
PC 및 안드로이드는 SSTP가 중국에서 사용할수 있는 유일한 VPN 입니다. 물론 IKEv2 프로토콜이 존재합니다만 너무 보안적이다보니 시원시원하게 터지지도 않고 UDP 프로토콜과 ESP 프로토콜을 사용하지 않은 필자에게는 그리 와닿지 않는 방식입니다.
왜 OPENVPN이 차단되는지 포트를 아무리 바꿔도 차단될수 밖에 없는지는 그리고 왜 SSTP는 차단되지 않는지는 내가 만약 중국의 인터넷을 통제하고 차단하고 싶은데 어떻게 해야될까?라고 접근하면 이해가 빠를수 있습니다. 필자는 취약한 보안을 뚫는것보단 차단하는것을 우선시하는 방법을 많이 찾고 있기 때문입니다.
중국의 VPN 차단은 원더풀 할정도로 자동화입니다. 인간들이 너무 많으니 사람이 통제하기보단 모든건 컴퓨터와 전산으로 처리할겁니다. CCTV로 용의자 및 범죄 검거율이 높은 이유도 다 이런데서 나오고 있습니다. 한국이 IT강국을 외쳤지만 중국은 이미 응용IT에 들어섰습니다. 모든 레퍼런스는 중국에서 나올지 모르겠습니다만 VPN 그것이 알고싶다 중국편 1탄은 여기서 마무리 하겠습니다.
2018/08/13 21:15 2018/08/13 21:15
Posted
Filed under Study

Change the Group Policy on your local client to use the vulnerable setting 

Run:  gpedit.msc

Go to à Computer Configuration -> Administrative Templates -> System -> Credentials Delegation -> Encryption Oracle Remediation

 

Open - Encryption Oracle Remediation à  choose Enable  à change protection levelàVulnerable à Apply

그룹정책편집기를 실행합니다.(gpedit.msc)

사용자 삽입 이미지
관리템플릿-시스템-자격증명위임-Oracle 수정 암호화 를 그림과 같이 변경해주면 모든 서버들을 업데이트 해야하거나 변경할 필요가 없습니다. 서버들을 5월자 업데이트를 완료하면 이문제가 사라지지만 이미 클라이언트PC가 업데이트가 되어 있기 때문에 클라이언트에서 변경을 해주는게 번거로운 작업을 피할수 있을거 같습니다.



2018/05/15 12:23 2018/05/15 12:23
Posted
Filed under MSSQL
● XACT_STATE() 와 @@TranCount
(2개의 명령어는 현재 세션에 존재하는 활성화된 사용자 트랜잭션을 확인하는데 사용하게된다.) 
select @@TranCount   :  현재 세션에 존재하는 활성화된 사용자 트랜잭션의 갯수
select XACT_STATE()  :  현재 세션에 존재하는 활성화된 사용자 트랜잭션의 유무 

트랜잭션은  Active User Transaction , Active Transaction (or Active Open Transaction) 으로 구분된다,해석하자면, 활성화된 사용자 트랜잭션 , 활성화된 트랜잭션일 뜻하는데, 조만간 트랜잭션을 다룰때 다뤄보기로 하고, 대신  마지막에 DBCC OPENTRAN 에 대해서 팁으로 알아보자.

아래는 XACT_STATE() 값 의미이다.(테트넷에서 퍼왔다.)

반환 값

의미

1

현재 요청에 활성 사용자 트랜잭션이 있습니다. 해당 요청에서는 데이터를 쓰고 트랜잭션을 커밋하는 등 모든 동작을 수행할 수 있습니다.

0

현재 요청에 대한 활성 사용자 트랜잭션이 없습니다.

-1

현재 요청에 활성 사용자 트랜잭션이 있지만 오류가 발생하여 트랜잭션이 커밋할 수 없는 트랜잭션으로 분류된 상태입니다. 해당 요청에서는 트랜잭션을 커밋하거나 저장점까지 롤백할 수 없고 트랜잭션의 전체 롤백만 요청할 수 있습니다. 요청에서 트랜잭션을 롤백할 때까지 모든 쓰기 작업을 수행할 수 없습니다. 트랜잭션을 롤백할 때까지 읽기 작업만 수행할 수 있습니다. 트랜잭션이 롤백된 후에는 요청에서 읽기/쓰기 작업을 모두 수행할 수 있으며 새 트랜잭션을 시작할 수 있습니다.

일괄 처리가 완료되면 데이터베이스 엔진에서 자동으로 커밋할 수 없는 활성 트랜잭션을 모두 롤백합니다. 트랜잭션이 커밋할 수 없는 상태가 되었을 때 오류 메시지가 전송되지 않은 경우 일괄 처리가 완료되면 오류 메시지가 클라이언트 응용 프로그램으로 전송됩니다. 이 메시지는 커밋할 수 없는 트랜잭션이 검색되어 롤백되었음을 보여 줍니다.

XACT_STATE와 @@TRANCOUNT 함수는 모두 현재 요청에 활성 사용자 트랜잭션이 있는지 여부를 검색하는 데 사용될 수 있습니다.@@TRANCOUNT를 사용하여 트랜잭션이 커밋되지 않은 트랜잭션으로 분류되었는지 여부를 확인할 수는 없습니다. 또한 XACT_STATE를 사용하여 중첩된 트랜잭션이 있는지 여부를 확인할 수 없습니다.(출처 : https://technet.microsoft.com/ko-kr/library/ms189797(v=sql.110).aspx)


자 이제 예제로 좀더 정확히 확인해보자 
참고, 아래는 예제 전체 풀 쿼리이다.





● XACT_STATE() 와 @@TranCount 예제  #1

먼저 샘플을 위해 Table 을 하나 작성하자. 
----------------------------------------------------------------------------------------------------------------------------------------------
Create table t_TranTest
(
      idx int primary key, 
      name varchar(50)
)

분하기 쉽게 트랜잭션에 A,B 명칭을 주었다, 2개의 중첩 트랜잭션을 설정하고 Trancount 와 XACT_STATE() 리턴값을 각각 확인해보자.

트랜잭션  Trancount XACT_STATE
A 1 1
A,B(중첩) 2 1
B 커밋 1 1
A 커밋 0 0

Trancount 는 현재 활성화된 트랜잭션의 갯수를 흐름대로 알려주고 ,
XACT_SATE 는  현재 활성화된 트랜잭션의 존재 유무에 대한 정보를 알려준다.

● XACT_STATE() 와 @@TranCount 예제  #2
이번엔 XACT_STATE 상태값이 -1 인상태 요약해서 말하자면 활성 사용자 트랜잭션이 commit 이 불가능한 rollback 만 가능한 상태의 트랜잭션이 발생했을겨우다. 정리하자면, 트랜잭션이 있긴 있는데, 프로세스에 오류가 발생해서rollback 말고는 여지가없을때의 상황을 말한다.

위의 t_TranTest 테이블을 드롭 & 재생하고 다시 실행해 보자


1. 예제를 위해 우선 SET XACT_ABORT ON 옵션을 활성화 시키자.
(이유는 OFF(디폴트) 상태에서는 오류난 구분만 오류를 발생시키고, 나머지는 모두 Commit 시키기때문이다 OFF 상태의 마지막 트랜잭션은 Commit 으로 끝나기때문에 Rollback이 나올 상황 연출이 안된다. 자세한건 전편 포스팅 참고)

2. 오류를 catch 하기 위해 Try ~ Catch 활용 한다.
(XACT_ABORT ON 상태에서는, 오류발생시 바로 rollback 시켜버린다. 하지만 우리는 지금 눈으로 확인해야하기 때문에 오류제어가 가능해져야한다. Try ~ cath 구문에서을 활용하면 바로 Rollback 되는것이 아니라 Catch 구문으로
제어가 넘어 온다.)

3. Begin tran 전에 ① insert 1개를 한다.
4. begin 안에서 ② insert 를 실행해 , PRIMARY KEY 제약 조건 오류를 강제로 발생 
5. ② 에서 발생한 오류로 제어가  Catch 문으로 넘어간다. 그리고 아래이 결과와 메시지 확인이 가능하다.





Messages 부분은 오류가나서 commit 할 수 없는 상황임에도 Commit Tran 을 적어줬기때문이다



위의 Commit Tran을 주석으로 처리하고, rollback 처리 해보자(오류가 나서 catch 왔으니 Rollback 이 당연하겠다.)


정상적으로 오류메세지없이 깔끔하게 처리된다.



 팁으로, 현재 서버에 활성화된 트랜잭션이 있는지에대한 정보를 확인할 수 있는 DBCC OPENTRAN 에 대해 알아보자

참고로 DBCC 시작하는 명령어들은, 현재 세션에만 국한된 명령어가 아닌 시스템 전체에 대한 서버 정보를 출력한다. 예를들면 위의 @@Trancount 나 xact_state 를 비롯해서 SET 기타 설정 명령어문들은 모두 현재 세션에서만 유효하다.(단, 시스템 전체에서, 가장 오래된 트랜잭션 1건만 출력) 
위의 쿼리를 다시한번 실행해보자
DBCC OPENTRAN() 으로 활성화되어 열려있는 트랜잭션에 대한 정보를 시스템 차원에서 접근한다.
아쉬울수 있겠지만, DBCC OPENTRAN() 은 트랜잭션 전체 대한 정보가 아닌 가장오래된 트랜잭션에 대한 정보만 1건만 출력한다. 여기서는 2회 출력 모두 트랜잭션 A 에 대한 정보만 출력한다.


Messages 탭에서 결과를  확인이 가능하다. 
다시한번 말하지만 , 다른세션에서도 조회가 가능하므로, DB 서버 관리자에게 유용할 수 있다. SPID 부터 시작시간 그리고 LSN(로그시퀀스번호) 까지 알 수 있다. SPID 만 알아도 다른 시스템 테이블 , 명령어 참고하면, 왠만한 정보는 금방 알아낼수있으리라 생각이 든다.

UID는 사용자 정보인데, 테크넷에 의하면 곧 사라질 정보라고한다, 의미없으니 무시하길..
2018/04/23 13:21 2018/04/23 13:21
Posted
Filed under MSSQL
이번에 포스팅할 내용은 Try ~ Catch 와 더불어 트랜잭션 관련 내용이 조금 포함된다. DB 에서 데이터 처리에 있어 트랜잭션은 이미 너무 많이 들었을것이다. 하지만, Try ~ Catch 에 종속된 문제는 아니다. 작업 처리의기본 범위의 문제이다. 자세한건 구글링을 통해 정독하자, 아래는 오류제어와 관련된 범주내에서 SET XACT_ABORT 개념과 함께 트랜잭션에
이야기 하게될 것이고, (다음 #3번에  트랜잭션 상태에 대해 알아보자)


● SET XACT_ABORT
SET XACT_ABORT OFF : 오류를 일으킨 Transact-SQL 문만  롤백 , 되고 다음 라인 작업처리를 계속함
SET XACT_ABORT
ON   : T-SQL 문에서 런타임 오류가 발생할 경우 전체 트랜잭션이 종료된 후 해당범위  롤백 

일반적을 SSMS 에서 쿼리창을 열면 기본 설정은 XACT_ABort 는   OFF  상태이다. 바꿔말하면 , 오류를 읽으킨 쿼리만 롤백 시키고 나머지는 모두 실행한다는 뜻이다. 백문이불여일견, 예제를 보자

SET XACT_ABORT ON / OFF 전체 쿼리 샘플 (다운로드)


● SET XACT_ABORT OFF 예제 (기본 : OFF)
( SET XACT_ABORT OFF  - 오류를 일으킨 Transact-SQL 문만, 롤백 되고 다음 라인 처리작업을 이어서 계속함

먼저 샘플을 위해 Table 을 하나 작성하자. 
----------------------------------------------------------------------------------------------------------------------------------------------
Create table t_XACTTest
(
      idx int primary key,
      name varchar(50)
)

위 에서도 언급했지만 기본 XACT_ABORT  는 OFF 이다.
( SET XACT_ABORT OFF  - 
오류를 일으킨 Transact-SQL 문만, 롤백 되고 다음 라인 처리작업을 계속함 )

⑤ 의 경우 idx 가 primary key로 설정되어있기때문에 중복된 값을 허락하지 않아 오류가 발생한다.


예상대로 ⑤ 라인에서 오류가 발생했다. 오류이유도 예상대로이다. 하지만 그 뒤로 남은 ⑥, ⑦ 쿼리들은 이어서 실행됨


결과적으로 오류가 발생한 ⑤ 번만 제외하고, 모두 정상적으로 실행되었다.





그럼 이제 트랜잭션으로 묶어보자
현재 상태는 여전히 SET XACT_ABOART OFF (기본) 상태이다

오류가능성이 있는 쿼리부분을 트랜잭션으로 묶어보아도 같은 현상이다, ⑤번 쿼리만 오류발생 후 아래 쿼리 까지 계속실행하여 commit 시킨다.  

Begin Tran ~ Commit Tran 의 영향이 없는것 처럼 보인다.

그럼 Begin Tran  ~ Rollback Tran 으로 해보자 ?

정상적으로 ④ ⑤ ⑥ 쿼리에 대해 롤백 됬다.
결론은, 트랜잭션의 영향을 받는다 오류난 쿼리만 , 진행하지 안을뿐


● SET XACT_ABORT ON 예제
(T-SQL 문에서 런타임 오류가 발생할 경우 전체 트랜잭션이 종료된 후 롤백 됩니다. )

SET XACT_ABORT ON   : 
T-SQL 문에서 런타임 오류가 발생할 경우 전체 트랜잭션이 종료된 후  롤백  됩니다.

위의 예제를 그대로 활용하여 ON 을 설정하여 실행해보자.  
----------------------------------------------------------------------------------------------------------------------------------------------
Delete from  t_XACTTest  -- 일단 테이블을 비운다.
SET XACT_ABORT ON  --  설정변경
(T-SQL 문에서 런타임 오류가 발생할 경우 전체 트랜잭션이 종료된 후 롤백 됩니다. )


예상대로,  ⑤ 의 경우 idx 가 primary key로 설정되어있기때문에 중복된 값을 허락하지 않아 오류가 발생한다.


그런데 ON 설정의 경우, 오류가 발생한 ⑤ 시점 후 부터는 모두 처리하지 않았다
결국 오류직전 쿼리 까지는 모두 실행이 된다.
①,②,③,④,⑤ 까지 실행은 했지만 ⑤는 오류로 인해 반영이 안된 상태로 ⑥,⑦ 도  XACT_ABORT ON 의 영향을받아 실행되지 않았다. ( 결과 3Row 출력)

그럼 이제 트랜잭션으로 묶어보자
현재 상태는 여전히 SET XACT_ABOART ON  상태이다 

⑤번의 오류로 인해 Begin Tran 
~ Commit Tran 구간이 모두 롤백이 되었다.

정리하자면,
SET XACT_ABORT ON / OFF는 현재 세션의 업무처리 중 오류가 발생하면 어떻게 해야될까? 에 대한 설정 방법중 하나 이다. 하지만 개인적인 생각에는, 설정을 단독으로는 잘 사용하지 않을꺼같다. 왜냐하면, 말그대로 환경에 대한 설정이지 제어에 대한 방법을 제공하지 않기 때문이다. 

하지만, 상단에서 처리된 어떤 업무가, 하단에 영향을 미친다고 생각해보자.
상단에서 오류가 발생하면 , 하단에서는 처리하면  안되는, OFF 상태면 상관없이 뭔가 처리를 하게 될테니 위험하다, 데이터의 연관성이나 끊김 데이터가 발생할 수 도 있다.  그럴경우 SET XACT_ABORT ON 설정 후 , 1차 안정장치를 해두고,Try ~ Catch 나, XACT_STATE() 등 을 활용하면, 
2중으로 안전하게 구현하는데 도움이 되지 않을까 싶다.
2018/04/20 15:43 2018/04/20 15:43
Posted
Filed under MSSQL
프로그래밍의 전유물 Try ~ Catch 를 MSSQL 에서도 꽤 오래전(MSSQL 2005 부터 지원)부터 사용 할 수 있게 되었다. 과연 DB 프로그래밍에서, Try ~ Catch 가 필요할까? 잠깐 살펴보자면, 어플리케이션용 프로그래밍언어와 DB용 프로그래밍언어는 목적이 좀 다르다. (구지 딴지를 걸면 할말은 없지만 본인 생각이다)

▶ DB는 CRUD (Insert,Select,Update,Delete) 에 집중된 처리를 할 수 있게해주어야한다.
▶ 그러므로, DB에 호출되어저, 넘어오는데이터는 사실 Validation 이 대부분 끝난 데이터 들이어야 한다.
(예를들면, 뭐,.. Type , Length , 유효성 등등  필드 조건 / 업무에 맞는 Spec )

하지만, 제어에 따라 DB단(DB 프로그래밍)에서 뭔가 다시한번  데이터를 체크하거나, 제어 처리해야 수월한 경우가 발생한다. 그러므로 MSSQL 에서의  Try ~ Catch 를 비롯한 기타 오류처리 변수 및 함수에 대한 지원은 반갑지 아니 할 수 없다.(반갑다.--)

● Try ~ Catch (Begin Try ~ End Try Begin Catch  ~ End Catch)
Begin Try
    // 오류 발생의 여지가 있거나, 예외가 날 가능성이 있는 코드
End Try
Begin Catch
   // 오류가 났을때 처리
End Catch

일반 어플리케이션 언어와 구문과 비슷한 문법을 가지고 있다.
물론 Exception 객체나 finally 그리고 예외 구분에 따른 catch  구문을 다중적으로 가질수 없는 축약식 느낌이긴하다.

여기서 중요한 점은 모든 오류를 Try ~ Catch가 잡아내지 못한다는 점이다.
MSSQL 의 Try ~ Catch 가 인지 할 수 있는 오류 심각도는 10 이상이고. 연결을 끊는,또는 강제 중단의 오류를 예외처리 Catch 하지 못한다. 

이번엔, Try ~ catch 를 활용하여 , 오류 처리 및 예외처리를 위해 필요한 함수에 대해 알아보자

● 오류 상태 체크 함수 
select @@Error -- 오류 코드를 출력한다.
select Error_Number()       -- 오류 코드 출력 = @@Error 과 같다.
select Error_Line()             -- 오류난 소스의 라인을 출력한다.
select Error_Message()     -- 오류 메세지를  출력한다.
select Error_Procedure()   -- 오류난 프로시져명을 출력한다.
select Error_Severity()      -- 오류의 심각도를 출력하한다.

select Error_State()           -- 오류의 상태를 출력한다.

위의 상태값을 눈으로 확인하기위해 , 아래 프로시져를 작성해 보자

[예제] 

Create proc sp_Test
as
Begin Try  
     EXECUTE SP_Nothing;   // SP_Nothing 는 없는 프로시저 이다.
End Try  
Begin Catch
    SELECT   
        @@Error as Error ,
        Error_Number()  as Number,
        Error_Line() as Line,
        Error_Message() as [Message],
        Error_Procedure() as [Procedure],
        Error_Severity() as severity,
        Error_State() as state  
End Catch


  Exec sp_Test  -- 실행해보자  
일단 오류 오류번호 와 심각도 , 상태 숫자는 우린 뭔지 모르겟지만,
그것을 제외하고도 ( getdate() 만 추가한다면,) 언제 , 어디서 , 어떤 오류가 , 몇 라인에 났는지 쉽게알 수 있다.


참고로 Error 함수들을 다 외우지 않아도 된다.(역쉬 편리한, 인텔리센스 ㅠ_)


이제 try  ~ catch 구문이 편리하게 오류 예외처리를 해주므로 너무 편리해졌지만, 안타깝게도 모든 오류를 처리해주지 않는다. 위에서 잠껀 언급한대로,  오류 심각도는 10 이상이고. 연결을 끊는,또는 강제 중단의 오류를 예외처리 Catch 하지 못한다. 예를들면 실행중 연결이 끊기거나, 실행중인 프로시져를, Kill 하거나, 하면 Catch 를 타지 못한다.

더 아이러니한건 어떤게 오류 레벨이 어떻고 어떤지, 오류 레벨로 기억하기란, 개발자 입장에서는, 다 알고 있기도 난해하다.
아래 샘플로 감을 한번 잡아보자.


● Try ~ Catch 예제

원래 예제도 되도록 복사해서  테스트 해볼수 있도록 Text 로 작성하려고 노력하지만, 이번엔 빠른 작성을  스크린샷으로 대신하고, 아래 샘플 쿼리를 첨부해 놓도록 하겠다.



----------------------------------------------------------------------------------------------------------------------------------------------
# 조건 1 : 존재하지 않는 프로시셔 -   예외처리 성공(ㅇ) 

※ 존재하지 않는 프로시져 호출시 정상적으로 예외처리를 한다. 이번에 테이블로  해보자!


----------------------------------------------------------------------------------------------------------------------------------------------
# 조건 2 : 존재하지 않는 테이블 -
  예외처리 오류(X) 
※ 존재하지 않는 테이블 쿼리시 예외처리를 못한다.ㅠ  그럼 함수를 호출해 보자 해보자


----------------------------------------------------------------------------------------------------------------------------------------------
#조건 3 : 존재하지않는 함수 - 
 예외처리 오류(X) 

※ 역시 안된다. 없는 개체의 호출은 프로시져 호츨만 성공하고, 나머지 테이블 


----------------------------------------------------------------------------------------------------------------------------------------------
# 조건 4 : 존재하지 하지만 사용할 수 없는 동의어(Synonym)
 -   예외처리 오류(X) 

※ 시놈님(동의어) 도 역시 안된다.


결국 없는 개체의 예외처리는
테이블,  함수, 동의어(시놈님) 모두 오류 , 프로시져만 성공 , 존재 하지도 않는 개체를 쿼리에작성할 일은 없지만 어쨋던 프로시져만 성공했다. 그럼 논리적인 오류를 작성 해보자.


자. 그럼 이제, 논리 오류에 대해 예외를 확인해보자.


----------------------------------------------------------------------------------------------------------------------------------------------# 조건 5 :  예제로 잘나오는 몫 0 으로 나누기 :
  예외처리 성공(ㅇ) 

----------------------------------------------------------------------------------------------------------------------------------------------
# 조건 6 :  유니크 컬럼에 중복 값 넣기:
  예외처리 성공(ㅇ) 




----------------------------------------------------------------------------------------------------------------------------------------------
# 조건 7 :  타입 다르게 넣기 :  
 예외처리 성공(ㅇ)  → idx 가 int 형인데 'b' 문자열 값을 넣어봤다.

※ 생각보다 논리적인 오류 처리는 잘 된다? 그렇타면 ,,

----------------------------------------------------------------------------------------------------------------------------------------------# 조건 8 : 우리가 흔히하는 실수,  테이블 제공 컬럼수와 다르게 데이터 입력 -   예외처리 오류(X) 

----------------------------------------------------------------------------------------------------------------------------------------------
# 조건 9 : 우리가 흔히하는 실수,  명령어 오타-   예외처리 오류(X) 
→ 눈에 띄게하기위해 values 부분을 valueInsert 로 해 보았다.
※ 역시 안된다 , 생각보다 많은걸 오류 처리를 못하는거 같이 보인다. 이외에도 쿼리 문법이 아닌 if 문 이나 case 등의
명령어 문법에 대해서도 예외처리가 안된다.

예제를 가만히 생각해 보자, 아 뭐지? 처리되는게 예외처리하는게 생각보다 얼마 없네? 라고 생각이 들 수 도있다.


자 그럼 이제 어플 개발언어로 돌아와서 생각해보자.


프로그램의 작성은 코딩 → 컴파일 → 실행 과정을 거친다. 물론 내부적으로  작성한 코딩이 맞는 문법 및 명령어 체크작업, 객체 및 변수의 존재 유무 및 초기화 문제 등등 , 기타 여러가지 문제점을 "코딩 → 컴파일" 과정에서 모두 소화 & 체크해서 개발자로 하게끔 수정을 한다.(컴파일 언어인 경우다) 

하지만 인터프리터나 , SQL 처럼 컴파일따로  실행따로 구분되어진 언어가 아닌, 실행과 동시에 컴파일과 문법 파싱작업이 동시에 이루어지는 스크립트 언어들은, 아무래도 개발에 특화된 언어에 비해 개발환경이 뛰어나지는 않타. 지극히 정상적일수도있다.

정리하자면, 만약 프로시져를 작성한다고 가정했을때, 어차피 위에서  예외처리가 안되는 상황의 쿼리 작성문들을, 프로시저에 작성하여, 생성 & 수정 한다면, 그 과정에서 최소한의 문법파싱 같은 작업이 이루어 지므로 없는 테이블을 작성하거나,  없는 함수를 쓰거나 하는 오류를 범 할 확률이 거의 없겟다. (반대로 예외처리가 되는 예제들은, 런타임시 값들에 의해 오류가 날 확률이 높다는 반증이다)

결론은, 객체 관련 오류보다 (심각도가 10 보다 높은오류) 논리적인 오류, 그러니까 값에 의해 발생되는 예외를 처리하도록 만들어지는게 사실상 맞다는 말이다.

역으로 생각해보면 , 없는 프로시져가 예외처리가 된다는게 오히려 의외의 결과 일수가 있다.
(하지만 프로시저 경우 작성시 try 안에 없는 프로시져 쿼리를 작성하면  프로시저는 만들어지지만, 아래와 같은 문구가 출력되면서 만들어진다.)

" 모듈 '생성되는 프로시저명'은(는) 누락된 개체 '호출될프로시져(없는프로시져)'에 종속되어 있습니다. 이 모듈은 그래도 만들어지지만 해당 개체가 있어야 실행될 수 있습니다.  "
2018/04/19 10:34 2018/04/19 10:34