- 2025년 12월 15일 (월) 14:32 그래프DB 와 벡터DB (역사 | 편집) [3,139 바이트] Oracle (토론 | 기여) (새 문서: == 그래프 DB(Graph Database) 와 벡터 DB(Vector Database) == {틀:요약 |제목=* 그래프 DB: ** “누가 누구와 어떻게 연결되어 있는가” 를 빠르게 찾는 DB * 벡터 DB: ** “이 데이터와 가장 비슷한 것은 무엇인가” 를 찾는 DB } ⸻ === 핵심 개념 비교 === {| class="wikitable" |+ 핵심 개념 |- ! 구분 !! 그래프 DB !! 벡터 DB |- | 핵심 목적 || 관계 탐색 || 유사도 검색 |- | 데이터 형태 || 노드 +...)
- 2025년 11월 21일 (금) 02:07 SQL 트레이스 방법 (역사 | 편집) [5,549 바이트] Dbstudy (토론 | 기여) (새 문서: == SQL 트레이스 == === SQL 세션 트레이스 수행 ==== <source lang=sql> -- 0.트레이스 식별자 지정 alter session set tracefile_identifier=’DBSTUDY_TUN_DUMP’; ==> orcl_ora_10024_"DBSTUDY_TUN_DUMP".trc 형태로 저장됨. -- 1. sql trace 시작 ALTER SESSION SET SQL_TRACE = TRUE; -- 2. event 를 level 12 로 설정. 이렇게 설정하면, SQL trace 정보, 실행계획, 대기 이벤트 정보를 볼 수 있다. ALTER SESSION SET events '10046 trace n...)
- 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"라는 제목으로 만들어졌습니다
검색 여닫기
메뉴 여닫기
33
0
9
1.7천
DB스터디