새 문서 목록

2025년 10월 24일 (금) 13:00 ‎카디널리티 와 셀렉티비티 (역사 | 편집) ‎[6,546 바이트] ‎Oracle (토론 | 기여) (새 문서: == Cardinality (카디널리티) 와 Selectivity (선택도) {{핵심 |제목= * Cardinality (카디널리티) ** 특정 연산이나 조건에서 반환되는 예상 행의 개수 ** 절대적인 수치 (행 개수) ** 실행 계획의 “Rows” 컬럼에 표시됨 *:-------------- * Selectivity (선택도) ** 전체 행 중에서 조건을 만족하는 행의 비율 ** 상대적인 비율 (0 ~ 1 사이의 값, 또는 0% ~ 100%) ** 조건의 “선택적” 정도를 나타...)
2025년 10월 22일 (수) 15:17 ‎테스트3 (역사 | 편집) ‎[134 바이트] ‎Jhwang327 (토론 | 기여) (새 문서: 글쓰기 테스트1 제목1 제목2 제목3) 태그: 시각 편집
2025년 10월 21일 (화) 13:05 ‎Hash join Probe 단계 처리과정 (역사 | 편집) ‎[7,193 바이트] ‎Oracle (토론 | 기여) (새 문서: == hash join Probe단계 처리 과정 == * 질문 : 해시조인에서 Probe 단계에서 해시바킷을 사용 하니요? *: ==> 아니요! Probe 테이블의 컬럼은 해시 버킷에 저장되지 않습니다. * 예제 <source lang=sql> SELECT e.emp_id, e.name, e.salary, d.dept_name FROM employees e -- ← Build 테이블 (작은 테이블) JOIN departments d -- ← Probe 테이블 (큰 테이블) ON e.dept_id = d.dept_id </source> === 해시 버킷에 저장...)
2025년 10월 21일 (화) 10:51 ‎해시 버킷의 저장구조 (역사 | 편집) ‎[21,292 바이트] ‎Dbstudy (토론 | 기여) (새 문서: == Oracle Hash Join의 내부 구조== * 해시 버킷의 저장 구조 === 해시 버킷에 저장되는 내용 === * 해시 버킷에는 '''주소 정보가 아닌 실제 데이터 행(row data)''' 이 저장됩니다. <source lang=python> # 해시 테이블 구조: #[해시 버킷 배열] Bucket 0 → [emp_id=101, name='김철수', dept_id=10] → [emp_id=501, name='이영희', dept_id=10] → NULL Bucket 1 → [emp_id=202, name='박민수', dept_id=20] → NULL Bucket...)
2025년 10월 2일 (목) 15:53 ‎인덱스 클러스터링 팩터 (역사 | 편집) ‎[7,122 바이트] ‎Oracle (토론 | 기여) (새 문서: 좋은 질문입니다! 명확하게 정리해드리겠습니다. ## 정답: **인덱스의 Clustering Factor**입니다! Clustering Factor는 **인덱스의 속성**이지, 테이블의 속성이 아닙니다. --- ## 개념 정리 ### 📊 Clustering Factor는 인덱스별로 존재 ```sql -- Clustering Factor는 DBA_INDEXES 뷰에 있음 (테이블 뷰가 아님!) SELECT index_name, -- 인덱스 이름 table_name, -- 참조하는 테이블...) 태그: 시각 편집: 전환됨
2025년 10월 2일 (목) 13:43 ‎클러스터링 팩터 (역사 | 편집) ‎[9,173 바이트] ‎Oracle (토론 | 기여) (새 문서: {{SQL|제목=CLUSTERING_FACTOR|내용=## CLUSTERING_FACTOR란? **인덱스와 테이블 데이터의 물리적 정렬 상태를 나타내는 통계 정보**입니다. 인덱스 키 순서와 테이블 블록의 물리적 배치가 얼마나 일치하는지를 측정합니다.|본문=## 값의 의미 ### 📊 범위 - **최소값**: 테이블의 블록 수 (완벽하게 정렬된 경우) - **최대값**: 테이블의 행 수 (완전히 무작위로 분산된 경우) ### 해석...) 태그: 시각 편집
2025년 9월 29일 (월) 14:43 ‎오라클 컬럼저장 방식 개선 (12c 업그레이드) (역사 | 편집) ‎[12,147 바이트] ‎Dbstudy (토론 | 기여) (새 문서: ==컬럼 default not null 변경시 컬럼저장 방식 개선== {{핵심 |제목= 오라클 12c이후 부터는 not null 컬럼 추가시 물리적인 저장을 하지 않지 메터정보를 참고하도록 변경되었다. :: - 12c부터는 NOT NULL 여부와 관계없이 DEFAULT 값이 있는 컬럼 추가 시 메타데이터만 저장되며, 실제 데이터가 UPDATE될 때 비로소 물리적으로 저장됩니다. |내용= 오라클 공식 레퍼런스 내용 참조 :::#...) 태그: 시각 편집
2025년 9월 25일 (목) 14:38 ‎테스트폼1 (역사 | 편집) ‎[178 바이트] ‎Dbstudy (토론 | 기여) (새 문서: {{SQL|제목=11111|내용=2222|본문=333|언어=444|예제=555|이전글=666|다음글=777|관련1=888|관련2=999|질문1=aaaa|답변1=bbb|질문2=ccc|답변2=ddd|분류=eeee}}) 태그: 시각 편집
2025년 9월 25일 (목) 14:25 ‎책책 (역사 | 편집) ‎[187 바이트] ‎Dbstudy (토론 | 기여) (요약)
2025년 9월 25일 (목) 14:24 ‎책 (역사 | 편집) ‎[56 바이트] ‎Dbstudy (토론 | 기여) (새 문서: {{#forminput:form=book|size=25|button text=Create page}}) 태그: 시각 편집: 전환됨
2025년 9월 25일 (목) 13:45 ‎Sql양식 샘플 (역사 | 편집) ‎[52 바이트] ‎Dbstudy (토론 | 기여) (새 문서: ==SQL== 개요는? 21 3 3 3 상세내용은 여기)
2025년 9월 25일 (목) 10:43 ‎Form:dbstudy (역사 | 편집) ‎[59 바이트] ‎Dbstudy (토론 | 기여) (새 문서: {{#forminput:form=MyForm|size=25|button text=Create page}}) 태그: 시각 편집
2025년 9월 25일 (목) 10:31 ‎튜닝 Round Trips (역사 | 편집) ‎[1,882 바이트] ‎Dbstudy (토론 | 기여) (새 문서: == Round Trips == * Oracle의 round-trips는 클라이언트와 데이터베이스 서버 간의 네트워크 통신 왕복 횟수를 의미합니다. ## Round-trips란? - 클라이언트가 서버에 요청을 보내고 응답을 받는 한 번의 완전한 통신 사이클 - 네트워크 지연시간과 직접적으로 연관되어 성능에 큰 영향을 미침 ===나쁜 예 (많은 round-trips):=== <source lang=sql> -- 각 INSERT마다 1번의 round-trip 발생 INSERT...)
2025년 9월 25일 (목) 10:21 ‎SQL SYS.ODCIVARCHAR2LIST이용 unionall 대체 (역사 | 편집) ‎[620 바이트] ‎Dbstudy (토론 | 기여) (새 문서: == SYS.ODCIVARCHAR2LIST이용 union all 대체 == * CTE 구문 <source lang=sql> SELECT '1' code, 'one' code_name FROM dual UNION ALL SELECT '2' code, 'two' code_name FROM dual UNION ALL SELECT '3' code, 'three' code_name FROM dual; </source> * regexp_substr함수 와 SYS.ODCIVARCHAR2LIST함수 이용 union all 대체 <source lang=sql> SELECT regexp_substr(column_value,'[^|]+]',1,1) code -- '|'구분자 기준 1번째값 , regexp_substr(column_value,'[^|]+]',1,2) cod...)
2025년 9월 24일 (수) 13:32 ‎SQL 성능 관리 프로그램 (역사 | 편집) ‎[17,408 바이트] ‎Dbstudy (토론 | 기여) (새 문서: = SQL 성능 관리 프로그램 = == 프로그램 개요 == == SQL 인스펙션 == === SQL 수집 및 분석 === === 조치 결과 보고서 === == SQL 플랜 분석 == === 플랜 분석 보고서 === == DB별 SQL 성능 저하 SQL == === TOP 10 SQL ===) 태그: 시각 편집: 전환됨
2025년 9월 22일 (월) 14:08 ‎데이터 블럭의 구조 (역사 | 편집) ‎[2,743 바이트] ‎Dbstudy (토론 | 기여) (새 문서: === 데이터 블럭의 구조 === https://misogain.wordpress.com/wp-content/uploads/2024/05/data_block_layer.png)
2025년 9월 16일 (화) 10:52 ‎성능 문제 식별 방법론과 튜닝 접근법 (역사 | 편집) ‎[14,146 바이트] ‎Oracle (토론 | 기여) (새 문서: == 성능 문제 식별 방법론과 튜닝 접근법 == ## 1. 성능 문제 분석 방법론 ### 1.1 Top-Down 접근법 (시스템 → 세션 → SQL) **단계별 분석 순서:** ``` 시스템 전체 성능 → 인스턴스 레벨 → 세션 레벨 → SQL 레벨 → 오브젝트 레벨 ``` **장점:** - 전체적인 시스템 상황 파악 가능 - 우선순위가 높은 문제부터 식별 - 리소스 사용률 기반의 객관적 분석 **분석 도구:** - ADDM (Autom...)
2025년 9월 16일 (화) 10:35 ‎DBA 성능 튜닝 가이드 (역사 | 편집) ‎[4,590 바이트] ‎Oracle (토론 | 기여) (새 문서: # Oracle Database 19c 성능 튜닝 가이드 요점 정리 ## 주요 목록 구성 ### 1. 성능 튜닝 개요 (Performance Tuning Overview) - **핵심 기능**: 성능 문제 식별 방법론과 튜닝 접근법 - **요점**: - 성능 문제의 근본 원인 분석 - 시스템적 접근법 vs 개별 SQL 튜닝 - 성능 모니터링의 중요성 ### 2. 자동 데이터베이스 진단 모니터 (ADDM) - **핵심 기능**: 자동화된 성능 분석 및 권고사항...)
2025년 9월 11일 (목) 12:05 ‎오라클 컬럼의 구조 (역사 | 편집) ‎[7,025 바이트] ‎Oracle (토론 | 기여) (새 문서: = Oracle 컬럼의 물리적 구조 = == 개요 == Oracle Database에서 컬럼의 '''물리적 저장 구조'''는 성능과 저장 효율성에 직접적인 영향을 미치는 핵심 아키텍처 요소입니다. 이 문서는 '''DBA 및 데이터베이스 전문가'''를 대상으로 컬럼의 바이트 레벨 저장 구조부터 성능 최적화까지 상세히 다룹니다. == Row Format Architecture == === Row Header Structure (3 bytes) === {| class="wikitable" ! Byt...)
2025년 9월 11일 (목) 11:55 ‎컬럼의 순서가 변경시 ROW의 물리적 구조변화 (역사 | 편집) ‎[7,726 바이트] ‎Oracle (토론 | 기여) (새 문서: ㅇㅇ)
2025년 9월 11일 (목) 11:50 ‎컬럼의 순서가 변경되면 ROW의 물리적 구조도 바뀌는건가? (역사 | 편집) ‎[0 바이트] ‎Oracle (토론 | 기여) (새 문서: == 컬럼 순서 변경 시 기존 저장된 row의 물리적 구조 변화 == * Oracle 컬럼 순서 변경과 Row 구조 변화: === 기본 원칙: 기존 Row는 변경되지 않음! === * 테스트 데이터 생성 및 ROW 구조 확인 <source lang=sql> -- 초기 테이블 생성 CREATE TABLE column_order_test ( id NUMBER, name VARCHAR2(20), status CHAR(1) ); -- 초기 데이터 삽입 INSERT INTO column_order_test VALUES (1, 'John', 'A'); INSERT INTO column_o...)
2025년 9월 11일 (목) 10:23 ‎오라클 컬럼의 저장순서 (역사 | 편집) ‎[7,937 바이트] ‎Oracle (토론 | 기여) (새 문서: == 오라클 컬럼의 저장 순서 == {{틀:개요 |내용= Oracle row에서 실제 저장된 컬럼의 순서는 매우 중요한 개념이므로 정확히 이해 해야 합니다. === Oracle Row 컬럼 저장 순서 규칙 === ==== 기본 원칙: 테이블 정의 순서 유지 ==== * 예시 테이블 생성 <source lang=sql> -- 테이블 정의 순서 CREATE TABLE row_order_test ( col1 NUMBER, -- 1번째 컬럼 col2 VARCHAR2(10), -- 2번째 컬럼 col...)
2025년 9월 3일 (수) 12:44 ‎안티조인 (역사 | 편집) ‎[12,557 바이트] ‎Oracle (토론 | 기여) (새 문서: == 안티 조인(Anti Join) == === 목적 === * 첫 번째 테이블의 데이터 중 두 번째 테이블과 일치하지 않는 데이터만 반환 === 특징 === * NOT EXISTS 또는 NOT IN 연산자 사용 * 조인 조건에 만족하지 않는 행만 선택 * 예시 쿼리: <source lang=sql> SELECT e.employee_id, e.name FROM employees e WHERE NOT EXISTS ( SELECT 1 FROM departments d WHERE e.department_id = d.department_id ); </source> * 세미 조인과 주...)
2025년 9월 3일 (수) 12:40 ‎세미조인 (역사 | 편집) ‎[5,607 바이트] ‎Oracle (토론 | 기여) (새 문서: == 세미 조인(Semi Join) == === 목적 === : 첫 번째 테이블의 데이터 중 두 번째 테이블과 일치하는 데이터만 반환 === 특징 === * 조인 조건에 만족하는 첫 번째 테이블의 행만 선택 * 실제 두 번째 테이블의 컬럼은 결과에 포함되지 않음 === 주요 구현 방법 === * EXISTS 연산자 사용 * IN 연산자 사용 * 예시 쿼리: <source lang=sql> SELECT e.employee_id, e.name FROM employees e WHERE EXISTS ( SELE...)
2025년 8월 29일 (금) 08:50 ‎병렬 쿼리 튜닝 (역사 | 편집) ‎[6,575 바이트] ‎Oracle (토론 | 기여) (새 문서: === Parallel Execution 요약 === {| class="wikitable" ! 구분 !! 설명 |- | 병렬 실행 정의 || 하나의 SQL 문을 여러 병렬 서버 프로세스로 나누어 동시에 실행하여 성능을 향상시키는 기능 |- | 주요 대상 || SELECT, INSERT, UPDATE, DELETE (DML) / CREATE INDEX, CTAS, MOVE 등 (DDL) |- | 병렬도 (DOP) || * 수동 지정: PARALLEL 힌트 또는 객체 속성에 정의 * 자동 결정: 옵티마이저가 통계와 자원 상황 기반으...)
2025년 8월 29일 (금) 08:27 ‎대용량 데이터 튜닝 (역사 | 편집) ‎[4,224 바이트] ‎Oracle (토론 | 기여) (새 문서: === VLDB와 파티셔닝 소개 ==== * VLDB(Very Large Databases)의 과제와 데이터 관리의 어려움을 설명 * 파티셔닝은 대형 테이블과 인덱스를 더 작은 조각으로 나누어 성능, 관리성, 가용성을 향상시킨다 * SQL이나 DML 변경 없이 적용 가능하며, 파티션 단위로 DDL 조작 가능 * 파티셔닝은 애플리케이션 코드 수정 없이 적용 가능하며, 큰 데이터베이스도 효과적으로 처리 가능...)
2025년 8월 25일 (월) 13:13 ‎REAL PLAN 사용법 (역사 | 편집) ‎[3,651 바이트] ‎Oracle (토론 | 기여) (새 문서: == Oracle Real-time SQL Monitoring (오라클 실시간 SQL 모니터링) == * Oracle Real-time SQL Monitoring은 SQL 쿼리 실행 중 성능을 **실시간으로 모니터링**하고 분석하는 강력한 도구입니다. 복잡하고 시간이 오래 걸리는 쿼리의 실행 계획, I/O, CPU, 대기 시간 등 상세한 성능 지표를 즉각적으로 보여주어 성능 문제를 신속하게 파악하고 해결하는 데 도움을 줍니다. ----- ### 주요 기능...)
2025년 8월 25일 (월) 13:07 ‎옵티마이져 (역사 | 편집) ‎[3,427 바이트] ‎Oracle (토론 | 기여) (새 문서: ==오라클 옵티마이져== *옵티마이져는 단순한 SQL이 아니라면 모든 실행 계획들을 평가하지 않는다. *휴리스틱 선택을 기반으로 가장 유리한 실행 계획 부터 시작 하여 다른 실행 계획을 평가하는데 가장 좋은비용의 실행 계획을 찾거나 대안 실행 계획이 너무 많다고 판단될 경우 평가를 종료한다. ===옵티마이져 비용 추정 요소=== ====시스템 통계==== #DB엔진이 실행되...) 태그: 시각 편집
2025년 8월 25일 (월) 11:17 ‎JPPD(Join Predicate PushDown,조인절 PUSHDOWN) (역사 | 편집) ‎[2,933 바이트] ‎Oracle (토론 | 기여) (새 문서: == JPPD (Join Pushed Predicate) == === Join Predicate Pushdown (JPPD - 조인 조건 푸시다운) === # 조인 푸시다운은 뷰 쿼리 밖에 있는 조인 조건이 뷰 안쪽에서 먼저 처리되는 최적화 기법입니다. ==== 원리 ==== # 뷰의 기본 테이블과 외부 테이블 간의 조인 조건이 뷰 내부로 "밀려들어갑니다". 이렇게 되면 뷰는 조인에 필요한 데이터만 미리 필터링하여 가져오게 됩니다. ==== 처리 예시...) 처음에 "JPPD(Join Pushed Predicate)"라는 제목으로 만들어졌습니다
2025년 8월 25일 (월) 10:53 ‎View pushed predicate (조건절 PUSHDOWN) (역사 | 편집) ‎[3,037 바이트] ‎Oracle (토론 | 기여) (새 문서: == XPLAN에서 View Pushed Predicate 항목 == * `VIEW PUSHED PREDICATE`는 Oracle 옵티마이저가 뷰(View)의 성능을 최적화하기 위해 필터 조건을 뷰 내부로 밀어 넣는(push down) 실행 계획을 나타냅니다. * 이 최적화 기법은 뷰의 기본 테이블에서 더 적은 데이터를 읽게 만들어 I/O를 줄이고 쿼리 성능을 크게 향상시킵니다. === VIEW PUSHED PREDICATE 원리 === # 일반적인 VIEW Merge 처리 실행 순서 #...) 처음에 "View pushed predicate"라는 제목으로 만들어졌습니다
2025년 8월 14일 (목) 15:14 ‎시스템 작업 (역사 | 편집) ‎[573 바이트] ‎조혜림 (토론 | 기여) (새 문서: # 메모리 관리 ## SGA/PGA 산정 ## SGA/PGA 메모리 증설 절차 # 디스크 관리 ## 디스크 볼륨 추가 ## ASM DISKGROUP 추가 # 백업 관리TUP ## 복구절차 ## 솔루션 - 넷백업 ## 테이블 백업 / 복구 (EXPORT/IMPORT) # OS 관리 ## ALIAS 설정 ## ORACLE 환경설정 ## CRONTAB # DB 관리 ## DB 종류 ### 일반 ### HA - ONE NODE RAC ### RAC ### EXA ## DB 기동/재기동/종료 ### RAC #### SRVCTL #### CRSCTL ### 일반 #### SHUTDOWN/STARTUP ##...) 태그: 시각 편집: 전환됨
2025년 8월 13일 (수) 19:30 ‎오라클 인덱스 종류 (역사 | 편집) ‎[4,293 바이트] ‎Oracle (토론 | 기여) (새 문서: == 오라클 인덱스 종류 == === B-tree 인덱스 (Balanced Tree Index) === {{:개요 |제목=특징: * 오라클에서 가장 일반적으로 사용되는 인덱스 * Balanced Tree의 약자로, 트리의 모든 리프 노드(실제 데이터 주소를 담고 있는 노드)까지의 거리가 일정하게 유지되는 균형 잡힌 트리 구조. * 인덱스 키와 해당 데이터가 위치한 ROWID를 저장하며, 리프 노드들은 서로 양방향으로 연결되어...)
2025년 8월 13일 (수) 19:07 ‎B*Tree 인덱스 (역사 | 편집) ‎[11,740 바이트] ‎Oracle (토론 | 기여) (새 문서: == B*Tree 인덱스 == === B*Tree 인덱스를 파이썬으로 구현 === * 오라클 B-tree 인덱스의 구조를 핵심적인 개념을 담은 간소화된 예제입니다. * 아래 코드는 실제 오라클의 복잡한 B-tree를 완벽하게 모방하지는 않지만, 그 작동 원리(노드 분할, 탐색, 삽입)를 이해하는 데 도움이 되는 뼈대를 제공합니다. 💡 B-Tree 인덱스 구조 이해 B-tree는 데이터베이스에서 대용량 데이터를...)
2025년 8월 13일 (수) 19:04 ‎인덱스 아키텍처 (역사 | 편집) ‎[57 바이트] ‎Oracle (토론 | 기여) (새 문서: == 인덱스 아키텍처 == === B*Tree 인덱스 ===)
2025년 8월 13일 (수) 17:32 ‎효율적인 SQL 작성법 (역사 | 편집) ‎[2,402 바이트] ‎Oracle (토론 | 기여) (새 문서: == 효율적인 SQL 작성법 == === SQL 용어 설명 === === SQL 작성 규칙 === • SQL 작성은 ORACLE 표준에 따라 작성하고, ANSI SOL은 사용하지 않는다. 전체 대문자 작성을 원칙으로 한다. (SQL ID, 바인드 변수는 예외) • 한 라인(행)의 최대 길이는 100열 이내로 한다. 복잡한 연산 등으로 인해 최대 길이가 100열을 초과할 경우 다음 라인을 사용하되 연산자가 아닌 컬럼명이나 괄호로...)
2025년 8월 13일 (수) 10:00 ‎데이터베이스설계서-DB아키텍처-별첨1.DB상세설계내역.xlsx (역사 | 편집) ‎[1,064 바이트] ‎조혜림 (토론 | 기여) (새 문서: # Parameter # 용량산정-요약 # 용량산정-상세 # 파티션테이블 # DB 별 계정 정보 # Role 별 권한) 태그: 시각 편집: 전환됨
2025년 8월 13일 (수) 00:55 ‎성능을 고려한 설계 (역사 | 편집) ‎[5,428 바이트] ‎Oracle (토론 | 기여) (새 문서: == Oracle SQL 성능을 고려한 설계 방법 10가지 == === 인덱스(Index) 활용 === # '''인덱스 설계''' #: 특정 컬럼을 자주 조회하거나 조인(JOIN)에 사용하는 경우 인덱스를 생성하면 성능이 크게 향상됩니다. # '''인덱스 선택''' #: 대부분의 경우 '''B-tree 인덱스'''가 효과적입니다. 특정 컬럼의 값 분포가 낮거나 범위 검색이 빈번한 경우 '''비트맵(Bitmap) 인덱스'''를 고려할 수 있습...)
2025년 8월 13일 (수) 00:13 ‎DBMS XPLAN 사용법 (역사 | 편집) ‎[17,535 바이트] ‎Dbstudy (토론 | 기여) (새 문서: == DBMS_XPLAN == # 아래 뷰에 대한 SELECT 권한 필요 ## DBA_HIST_SQL_PLAN ## DBA_HIST_SQLTEXT ## V$DATABASE === DBMS_XPLAN.DISPLAY === * plan_table에 저장된 실행계획을 출력. EXPLAIN PLAN 구문보다 확장된 정보 출력 === DBMS_XPLAN.DISPLAY_CURSOR === * 실제 실행 후 패치된 플랜정보 * DBMS_XPLAN.DISPLAY_CURSOR 필요권한 ** V$SQL_PLAN ** V$SESSION ** V$SQL_PLAN_STATISTICS_ALL <source lang=sql> GRANT SELECT ON V_$SESSION TO HR; GRANT...)
2025년 8월 12일 (화) 23:35 ‎오라클 초보자 학습과정 (역사 | 편집) ‎[1,601 바이트] ‎Oracle (토론 | 기여) (새 문서: __notoc__ https://dbstudy.co.kr/w/resources/assets/dbstudy_iconx1.png = Welcome To DB STUDY - {{CURRENTYEAR}}.{{CURRENTMONTHNAME}}.{{CURRENTDAY}}({{CURRENTDAYNAME}}) = * {{SERVER}} * 게시글 총 : {{NUMBEROFPAGES}} 건 , 사용자 : {{NUMBEROFUSERS}} 명 , <p sizes="(max-width: 600px) 480px,800px"> https://dbstudy.co.kr/w/images/dbstudy_logo.jpg </p> {{틀:타이틀 라운드 |제목=오라클: {{PAGESINCATEGORY: oracle}} 건 , :Category:postgresql|Po...)
2025년 8월 8일 (금) 14:44 ‎MERGE 조인 (역사 | 편집) ‎[2,869 바이트] ‎Oracle (토론 | 기여) (새 문서: == MERGE 조인 == * 정확한 명칭은 'MERGE JOIN' 또는 'SORT MERGE JOIN') * SORT(정렬) 후 MERGE(합치다) 의 의미 --- === MERGE 조인이 필요한 경우 === # 조인에 사용되는 양쪽 테이블이 이미 정렬되어 있거나, 정렬 비용이 크지 않은 경우 # 대량의 데이터에 대해 효율적인 조인이 필요할 때 === MERGE 조인 동작 원리 === # 조인에 참여하는 두 테이블의 조인 컬럼을 기준으로 정렬(sorting)....)
2025년 8월 8일 (금) 14:25 ‎HASH조인 성능저하 파이썬 예제 (역사 | 편집) ‎[6,485 바이트] ‎Oracle (토론 | 기여) (새 문서: == 해시조인 “문제 상황” 퍼이썬으로 재현 == * 두 가지 시나리오를 비교 *:- 시나리오 A(정상): 적정 버킷 수 + 고르게 분포된 키 *:- 시나리오 B(문제): 너무 적은 버킷 수 + 편향된 키(핫 키 집중) * 핵심 포인트는 “버킷 과밀 → 체인 길이 급증 → 조인 탐색 시간 증가”를 눈으로 확인하는 것입니다. <source lang=python> import random import time from collections import defaultdict, Coun...)
2025년 8월 8일 (금) 13:58 ‎테이블 조인 방식 (역사 | 편집) ‎[59 바이트] ‎Oracle (토론 | 기여) (새 문서: {{:NL 조인}} ---- {{:HASH 조인}} ---- {{:MERGE 조인}})
2025년 8월 8일 (금) 08:13 ‎HASH 조인 (역사 | 편집) ‎[19,884 바이트] ‎Oracle (토론 | 기여) (새 문서: == 해시 조인(Hash Join) == # 해시 조인(Hash Join)은 두 개의 테이블을 조인할 때, 더 작은 테이블을 메모리에 올리고 해시 테이블을 만들어 효율적으로 조인하는 방식 # 대용량 테이블을 조인할 때 주로 사용되며, 조인 조건에 인덱스가 없는 경우에도 빠르게 작동 === 해시 조인의 원리 === * 해시 조인은 크게 두 단계로 나뉩니다. # 빌드 단계 (Build Phase): ## 옵티마이저는 두...)
2025년 8월 7일 (목) 21:36 ‎테스트 템플릿만들기 (역사 | 편집) ‎[322 바이트] ‎Oracle (토론 | 기여) (새 문서: {{오라클 DBA |Oracle INSERT 구문 |1단계 |* INSERT 구문은 테이블에 새로운 데이터를 추가할 때 사용됩니다. |INSERT INTO 테이블명 (컬럼1, 컬럼2) VALUES (값1, 값2); |INSERT INTO employees (id, name) VALUES (1, 'Alice'); |알았어, 다음에 또 봐 |그래, 다음에 또 봐 |oracle }})
2025년 8월 7일 (목) 18:55 ‎Rowid 를 이용한 조인 (역사 | 편집) ‎[2,287 바이트] ‎Oracle (토론 | 기여) (새 문서: == ROWID를 이용한 조인으로 SQL 튜닝 == # large_table과 small_table이라는 두 테이블을 조인하는 상황 # large_table에서 small_table의 특정 조건을 만족하는 데이터를 찾을 때, ROWID를 사용하면 물리적인 위치를 직접 참조하여 논리적인 인덱스 스캔보다 효율적일 수 있습니다. <source lang=sql> SELECT t1.column1, t1.column2, t2.column_a FROM large_table t1 WHERE t1.rowid IN ( SELECT...)
2025년 8월 6일 (수) 22:20 ‎NL 조인 (역사 | 편집) ‎[11,424 바이트] ‎Oracle (토론 | 기여) (새 문서: === NL(Nested Loop) 조인 === ==== Nested Loop Join 의 개념 ==== {{틀:개념 |제목=NL 조인의 개념 |내용=* 중첩된(Nested) + 반복(Loop) + 연결(Join) :# 두개 이상의 테이블에서, 하나의 집합을 기준으로 순차적으로 상대방 테이블의 row 를 결합하여 원하는 결과를 추출하는 테이블 연결 방식 :# 결합하기 위해 기준이 되는 테이블(선행테이블=드라이빙 테이블=outer테이블) : driving 테이블( O...)
2025년 8월 6일 (수) 22:14 ‎SQL 조인 방식 (역사 | 편집) ‎[185 바이트] ‎Oracle (토론 | 기여) (새 문서: == SQL 조인 방식 == {{:NL 조인|NL조인 (Nested Loop) }} ---- {{:해시 조인 HASH|해시조인 (Hash) }} ---- {{:SORT MERGE 조인|소트머지조인 (Sort Merge) }} ---- {{:조인별 튜닝 포인트 }}) 태그: 시각 편집: 전환됨
2025년 7월 28일 (월) 13:41 ‎전개 단계 (역사 | 편집) ‎[193 바이트] ‎Oracle (토론 | 기여) (새 문서: === 전개 단계 === ==== 산출물 ==== # 운영자 매뉴얼 ==== 주요 작업 TASK ==== # 데이터 이관 사전/사후 작업 # 이행후점검및운영 DB 전환)
2025년 7월 28일 (월) 13:40 ‎테스트 단계 (역사 | 편집) ‎[380 바이트] ‎Oracle (토론 | 기여) (새 문서: === 테스트 단계 === ==== 산출물 ==== # 가용성 테스트 결과서 # 복구 테스트 결과서 # 튜닝결과서 # 인스펙션 결과서(선택) ==== 주요 작업 TASK ==== # 데이터 이관 지원 # SQL 튜닝 (튜너) # 성능 모니터링 # 성능 테스트 지원 # 가용성 테스트 # 백업복구테스트)
2025년 7월 28일 (월) 13:40 ‎구축 단계 (역사 | 편집) ‎[370 바이트] ‎Oracle (토론 | 기여) (새 문서: === 구축 단계 === ==== 산출물 ==== # SQL 작성 가이드 ## 별첨)SQL작성가이드-DB아키텍처_DB접속정보.pptx ==== 주요 작업 TASK ==== # 물리모델반영및 변경관리 # 오브젝트 관리 # 통합테스트 환경구성 # 가용성 테스트 시나리오 작성 # 백업복구테스트 시나리오 작성)