Unique Life

출처: http://rapapa.net/?p=311

Mysql DB를 다룰 때 초보 수준에서 약간 중급으로 넘어가면서 흔히들 많이 어려워 하는 것이 Join 구문입니다.

먼저, 아래와 같은 테이블 두개가 있다고 합시다.

+————+————–+——+
| name | phone | pid |
+————+————–+——+
| Mr Brown | 01225 708225 | 1 |
| Miss Smith | 01225 899360 | 2 |
| Mr Pullen | 01380 724040 | 3 |
+————+————–+——+

+——+——+———————-+
| pid | spid | selling |
+——+——+———————-+
| 1 | 1 | Old House Farm |
| 3 | 2 | The Willows |
| 3 | 3 | Tall Trees |
| 3 | 4 | The Melksham Florist |
| 4 | 5 | Dun Roamin |
+——+——+———————-+

두 테이블은 pid 칼럼으로 엮여 있습니다.

먼저 두 테이블을 pid가 같은 것을 조건으로 일반적인 Join을 걸면 결과는 아래와 같습니다.

+———–+————–+———————-+
| name | phone | selling |
+———–+————–+———————-+
| Mr Brown | 01225 708225 | Old House Farm |
| Mr Pullen | 01380 724040 | The Willows |
| Mr Pullen | 01380 724040 | Tall Trees |
| Mr Pullen | 01380 724040 | The Melksham Florist |
+———–+————–+———————-+

pid가 같은 조건이 있는 줄은 두 테이블 모두에서 모조리 나오게 됩니다.
어느테이블이 기준이랄 것이 없이 양쪽에서 줄들이 추가되는 형국이죠. 이 때 서로 같은 것이 존재하지 않는 줄은 아예 출력이 되지 않습니다.

반면, Left 혹은 right join은 기준 테이블, 즉 반드시 출력되는 테이블을 잡아 줍니다.
위의 SQL 구문에서 Left Join을 걸어 보면 아래와 같은 결과가 나옵니다.

+————+————–+———————-+
| name | phone | selling |
+————+————–+———————-+
| Mr Brown | 01225 708225 | Old House Farm |
| Miss Smith | 01225 899360 | NULL |
| Mr Pullen | 01380 724040 | The Willows |
| Mr Pullen | 01380 724040 | Tall Trees |
| Mr Pullen | 01380 724040 | The Melksham Florist |
+————+————–+———————-+

이 때 Left Join이기 때문에 왼쪽 테이블이 기준이 됩니다.
따라서, 왼쪽 테이블의 모든 Row가 결과값에 반드시 한줄 이상 나오는 보장을 받게 됩니다. 왼쪽 테이블(demo_people)에 해당하는 오른쪽 테이블의 pid가 여러개일경우 위와 같이 여러줄이 나옵니다.

반면, right join은 left join과 반대로 기준이 오른쪽 테이블입니다.
오른쪽 테이블은 반드시 한줄 이상 나오는 보장을 받게 되는 것이죠.
결과 값을 한번 보시죠.

+———–+————–+———————-+
| name | phone | selling |
+———–+————–+———————-+
| Mr Brown | 01225 708225 | Old House Farm |
| Mr Pullen | 01380 724040 | The Willows |
| Mr Pullen | 01380 724040 | Tall Trees |
| Mr Pullen | 01380 724040 | The Melksham Florist |
| NULL | NULL | Dun Roamin |
+———–+————–+———————-+

왼쪽 테이블(demo_people)에 해당 pid 값이 같은 줄이 없어도,
오른쪽 테이블(demo_property)이 모두 나와야 하기 때문에, null, null 값이 출력되게 된 것입니다.

INNER JOIN은 JOIN과 같고,
LEFT OUTER JOIN은 LEFT JOIN과 같고,
RIGHT OUTER JOIN은 RIGHT JOIN과 같습니다.

출처: http://egloos.zum.com/linguistics/v/1996343

critical log checklist.pdf

출처: https://zeltser.com/security-incident-log-review-checklist/

http://www.tecmint.com/linux-directory-structure-and-important-files-paths-explained/

-> Linux Directory Structure and Important Files Paths Explained

This cheat sheet presents a checklist for reviewing critical logs when responding to a security incident. It can also be used for routine log review. It was authored by Dr. Anton Chuvakin and Lenny Zeltser. To print, use the one-sheet PDF version; you can also edit the Word version for you own needs. If you like this, take a look at my other IT cheat sheets.

General Approach

1. Identify which log sources and automated tools you can use during the analysis.
2. Copy log records to a single location where you will be able to review them.
3. Minimize “noise” by removing routine, repetitive log entries from view after confirming that they are benign.
4. Determine whether you can rely on logs’ time stamps; consider time zone differences.
5. Focus on recent changes, failures, errors, status changes, access and administration events, and other events unusual for your environment.
6. Go backwards in time from now to reconstruct actions after and before the incident.
7. Correlate activities across different logs to get a comprehensive picture.
8. Develop theories about what occurred; explore logs to confirm or disprove them.

Potential Security Log Sources

• Server and workstation operating system logs
• Application logs (e.g., web server, database server)
• Security tool logs (e.g., anti-virus, change detection, intrusion detection/prevention system)
• Outbound proxy logs and end-user application logs
• Remember to consider other, non-log sources for security events.

Typical Log Locations

• Linux OS and core applications: /var/log
• Windows OS and core applications: Windows Event Log (Security, System, Application)
• Network devices: usually logged via Syslog; some use proprietary locations and formats

What to Look for on Linux

What to Look for on Windows

What to Look for on Network Devices

What to Look for on Web Servers

 출처: http://blackbull.tistory.com/9

MySQL에서의 Sub Query의 더러운 진면목을 경험해 본 기억이 있기에,
(하루 온종일 돌려도 결과가 안 나와서 걷어찰 뻔 했다는...-_-;;)
요즘 모든 Sub Query들을 JOIN을 이용하여 해결하기 위해 노력한다.

그런데!!! 두둥!!
이런 뒌장.... 평소에 잘 돌아가던 코드가 Oracle에서는 안 돌아가더라....
'!$!@%$%!#$ㅆㄲㄸㅎㄹㅇㅎ!#!@#' 라고 욕을 잔뜩 하고 난 다음..
고민이 들더라..

많은 양의 데이터를 Migration 하기 위해 미리 짜 놓은 Query가,
쓰레기가 되는 상황이 벌어졌으니....
'뭐.. 아직은 시간이 남았으니 해결책을 마련해 보자.'
라고 하다가,

언제나처럼, 내 옆에 계시는 '고수'님의 파워를  빌어 내었다..

물론, 설명을 듣고 난 후에 오라클을 향해 다시 한 번
'*@$@#$@ㅎㅎㄲㄸㅎㅃㅎㄸㄲㅎ#$!$'
라고 해주는 것 또한 잊지 않았다눙~~

아.. 그런데 욕하다 보니 생각났다....
'내가 무식한 거구나 --;; !$%!$#%#$#!@#ㅇㅀㄶㄸ'

뭐 각설하고, 본론으로 가보장.

********************************************************************
[MySQL 에서의 사용 예]
UPDATE table_a a INNER JOIN table_b b ON (a.id = b.id)
SET       a.value = 'MySQL이 아직 공짜라 좋다!!'
WHERE  a.check_point = 'N';
********************************************************************
요럴 경우, 우리의 훌륭한 MySQL은 별다르게 다른 작업을 해주지 않아도,
참 일을 잘해준다.
즉, 쪼인을 건 상태임에도 불구하고, 알아서 해당 테이블의 값을 잘 넣어준다는 말씀.

그런데, 오라클을 함 보장.
********************************************************************
[Oracle 에서의 사용 예]
UPDATE table_a a INNER JOIN table_b b ON (a.t_id = b.t_id)
SET       a.t_value = 'Oracle 아따따 뿌우겐!!'
WHERE  a.t_check_point = 'N';
********************************************************************
요러면... 에러난다..
왜? UPDATE 구문에 들어갈 녀석의 JOIN이 되지 않기 때문이다.
Oracle 曰... 'SET 어딨냐?' --;;

그럼... 일보 후퇴하여, 궁극 병기 서브쿼리의 형식으로 쥐어짜 보자.
********************************************************************
[Oracle 에서의 사용 예]
UPDATE (SELECT a.t_value, a.t_check_point
             FROM table_a a INNER JOIN table_b b ON (a.t_id = b.t_id)
             ) x
SET       x.t_value = 'Oracle 아따따 뿌우겐!!'
WHERE  x.t_check_point = 'N';
********************************************************************
쓰읍... 결과는?  당근 된다..

그럼 한 가지 더...

저번에 오라클 10g AdminWorkshop 과정 때 강사님께,
'혹시 위와 같은 상황에서, 실제로 업데이트가 가능한 컬럼들을 알 수 있을까요?'
라고 여쭈어보니, 하루 있다 말씀 주신 것이...

'오라클에는 ALL_UPDATABLE_COLUMNS, USER_UPDATABLE_COLUMNS 라는 테이블이 있다.'

ALL_UPDATABLE_COLUMNS는 생성된 VIEW의 속성값 변경 가능 여부를
표시하는 시스템 테이블이고, USER_UPDATABLE_COLUMNS는 유저에게 종속된 VIEW의
속성 변경 가능 여부를 표시해준다.

하지만, 저것만으로는 매번 뷰를 생성해서 확인해 봐야 하는 중노동(?)이 필요하다.
뭔가 다른 방법은 없을까?

http://download.oracle.com/docs/cd/B28359_01/server.111/b28310/views001.htm#i1006232

상기 링크를 보면, Updatable Join View 가 되기 위해서는 반드시 해당 View가
Key-preserved Table이여야 하다고 한다.

흠... 그거만 있으면 되는건가?