검색결과 리스트
DATABASE에 해당되는 글 19건
- 2017.02.07 전체 프로시져에서 특정 문자열이 사용된 프로시져를 찾는 법
- 2016.01.12 dateadd, datediff
- 2014.02.28 [펌] UNION과 UNION ALL 의 차이 및 주의 사항
- 2013.12.16 GetDate format 변환
- 2013.11.05 [펌] 트랜잭션 로그 백업(Transaction Log Backup)에 관하여
- 2013.10.30 [업무] 임시 테이블을 이용해서 데이터 JOIN
- 2013.10.30 [기초] 임시테이블 @Table 만들기
- 2013.10.07 [MSSQL] 문자열 이나 이진 데이터 는 잘립니다.
- 2013.09.25 Truncate with condition - 조건 주고 TRUNCATE 하기
- 2013.09.25 TRUNCATE
글
SELECT DISTINCT a.name
FROM sysobjects AS a
LEFT JOIN syscomments AS b ON a.id = b.id
WHERE a.xtype = 'P'
AND b.text LIKE '%찾은문자열%'
'DATABASE > MS SQL' 카테고리의 다른 글
dateadd, datediff (0) | 2016.01.12 |
---|---|
GetDate format 변환 (0) | 2013.12.16 |
[업무] 임시 테이블을 이용해서 데이터 JOIN (0) | 2013.10.30 |
[기초] 임시테이블 @Table 만들기 (0) | 2013.10.30 |
[MSSQL] 문자열 이나 이진 데이터 는 잘립니다. (0) | 2013.10.07 |
설정
트랙백
댓글
글
dateadd
-- 월의 마지막 날
select dateadd(month,1,getdate())-day(getdate())
-- 월의 첫째날
select dateadd(day,-(day(getdate()-1)), getdate())
-- 월의 13개월전 첫째날
select dateadd(month,-12,getdate())-(day(getdate())-1)
-- 1일 더하기
select dateadd(day,1,getdate())
-- 1월 더하기
select dateadd(month,1,getdate())
-- 1년 더하기
select dateadd(year,1,getdate())
datediff
datediff( 시간단위구분자, 시작시간, 종료시간 )
'DATABASE > MS SQL' 카테고리의 다른 글
전체 프로시져에서 특정 문자열이 사용된 프로시져를 찾는 법 (0) | 2017.02.07 |
---|---|
GetDate format 변환 (0) | 2013.12.16 |
[업무] 임시 테이블을 이용해서 데이터 JOIN (0) | 2013.10.30 |
[기초] 임시테이블 @Table 만들기 (0) | 2013.10.30 |
[MSSQL] 문자열 이나 이진 데이터 는 잘립니다. (0) | 2013.10.07 |
설정
트랙백
댓글
글
출처 : 토토 블로그 http://intomysql.blogspot.kr/2011/01/union-union-all.html
UNION과 UNION ALL 의 차이 및 주의 사항
MySQL에서는 UNION 집합 연산만 제공하고 있다.
(하지만 MySQL에서 INTERSECT나 MINUS를 다른 형태의 쿼리로 풀어서 사용할 수 있다.)
이 글에서는 UNION 에 대해서 좀 더 자세히 알아 보고자 한다.
UNION 집합 연산은 다시 아래와 같이 두가지 종류로 나누어진다.
- UNION ALL
- UNION DISTINCT
우리가 일반적으로 사용하는 방식인 아무런 추가 키워드 없이 UNION 만 사용하는 것은
UNION DISTINCT 를 줄여서 사용하고 있는 것이다.
UNION ALL과 UNION DISTINCT를 레코드가 많은 결과에 대해서 적용해본 사람은
아마도 둘의 처리 방식에 대해서 의구심을 가져본 적이 있을 것이다.
레코드 건수가 많아지면 많아질수록 그 성능 차이는 엄청난 차이를 보여줄 것이다.
우선, 아래와 같이 2개씩 동일한 레코드 데이터를 가지고 있는 tab1과 tab2라는 테이블이 있다.
mysql>SELECT fdpk, fddata FROM tab1;
+------+--------+
| fdpk | fddata |
+------+--------+
| 1 | data1 |
| 2 | data2 |
+------+--------+
2 rows in set (0.00 sec)
mysql>SELECT fdpk, fddata FROM tab2;
+------+--------+
| fdpk | fddata |
+------+--------+
| 1 | data1 |
| 2 | data2 |
+------+--------+
2 rows in set (0.01 sec)
그러면, 이 두개 테이블에 대해서 각각 UNION과 UNION ALL을 사용하는 쿼리를 실행해보자.
mysql>SELECT fdpk, fddata
-> FROM (
-> SELECT fdpk, fddata FROM tab1
-> UNION ALL
-> SELECT fdpk, fddata FROM tab2
-> ) x;
+------+--------+
| fdpk | fddata |
+------+--------+
| 1 | data1 |
| 2 | data2 |
| 1 | data1 |
| 2 | data2 |
+------+--------+
4 rows in set (0.00 sec)
mysql>SELECT fdpk, fddata
-> FROM (
-> SELECT fdpk, fddata FROM tab1
-> UNION
-> SELECT fdpk, fddata FROM tab2
-> ) x;
+------+--------+
| fdpk | fddata |
+------+--------+
| 1 | data1 |
| 2 | data2 |
+------+--------+
2 rows in set (0.00 sec)
두개의 퀴리 실행 결과 UNION은 레코드가 반으로 줄었다.
이미 다들 알고 있다시피 UNION은 UNION DISTINCT와 동일한 작업을 하기 때문에 중복되는 레코드를 제거했음을 알 수 있다.
하지만, UNION ALL의 경우에는 별도의 중복 제거 과정을 거치지 않고 그냥 결과를 내려준다.
아주 중요한 내용이지만, 사실 이 내용을 다들 별로 신경쓰지 않고 모두들 UNION을 즐겨 사용한다.
안타깝게도, MySQL의 실행계획에서는 둘의 차이를 전혀 느낄 수 없다.
+----+--------------+------------+------+..+------+..+------+------+-------+
| id | select_type | table | type |..| key |..| ref | rows | Extra |
+----+--------------+------------+------+..+------+..+------+------+-------+
| 1 | PRIMARY | <derived2> | ALL |..| NULL |..| NULL | 4 | |
| 2 | DERIVED | tab1 | ALL |..| NULL |..| NULL | 2 | |
| 3 | UNION | tab2 | ALL |..| NULL |..| NULL | 2 | |
|NULL| UNION RESULT | <union2,3> | ALL |..| NULL |..| NULL | NULL | |
+----+--------------+------------+------+..+------+..+------+------+-------+
하지만 중복 제거는 그냥 얻을 수 있는 결과가 아니다.그러면, MySQL이 내부적으로 어떻게 중복을 제거하는 것일까 ?
내부적인 처리를 알아보기 전에, 레코드의 중복이라는 표현을 했는데 이 중복의 기준이 무었일까 ?
1. 각 테이블의 Primary key ?
2. 전체 테이블의 모든 필드 ?
3. 각 서브 쿼리에서 SELECT된 튜플(레코드)의 모든 필드 ?
그렇다. 이미 SELECT된 결과를 가지고 UNION하기 때문에 SELECT되기 전의 테이블이나 레코드에 대한 정보는 알 수 없다.
그래서, 중복 여부의 판단은 SELECT된 튜플들에 속해있는 모든 컬럼의 값들 자체가 중복 체크의 기준이 되는 것이다.
자~, 그러면 이제 MySQL이 내부적으로 UNION ALL과 UNION을 처리하는 과정을 알아보자.
1. 최종 UNION [ALL | DISTINCT] 결과에 적합한 임시 테이블(Temporary table)을 메모리 테이블로 생성
2. UNION 또는 UNION DISTINCT 의 경우, Temporary 테이블의 모든 컬럼으로 Unique Hash 인덱스 생성3. 서브쿼리1 실행 후 결과를 Temporary 테이블에 복사
4. 서브쿼리2 실행 후 결과를 Temporary 테이블에 복사
5. 만약 3,4번 과정에서 Temporary 테이블이 특정 사이즈 이상으로 커지면
Temporary 테이블을 Disk Temporary 테이블로 변경
(이때 Unique Hash 인덱스는 Unique B-Tree 인덱스로 변경됨)
6. Temporary 테이블을 읽어서 Client에 결과 전송
7. Temporary 테이블 삭제
UNION 두 가지의 차이는 2번 과정 딱 하나이다. 중복 제거를 위해서 Temporary 테이블에 인덱스를 생성하느냐 ?. 그렇지 않느냐 ?.별로 중요하지 않은 것 같지만, 이 인덱스로 인해서 3,4번 과정의 작업이 작지 않은 성능 차이가 만들어 내게 된다.
실제 UNION을 실행하는 데이터의 건수에 따라서 다르겠지만, 1.5 ~ 4배 가량의 성능 차이로 UNION ALL이 빠르게 처리된다.
만약 처리중 데이터의 량이 작아서 5번 과정을 거치지 않는다면 메모리 Temporary 테이블에 Hash 인덱스를 사용하기 때문에
속도 차이가 아주 미세할 것이다.
하지만 데이터량이 커져서 5번 과정을 거치게 되면 Disk Temporary 테이블에 B-Tree 인덱스를 사용하기 때문에 큰 성능 차이를 보이게 될 것이다.
이 성능 차이는 UNION 하는 두 집합에 중복되는 레코드가 있든 없든 관계 없이 발생할 것이다.
위에서 잠깐 알아보았던, "중복의 기준"을 생각하면, UNION 하는 컬럼들의 수가 많아지고 레코드의 사이즈가 커질수록 두 작업 모두에게 불리하겠지만, UNION ALL보다는 UNION에 더 악영향이 클 것이다.
결론은,
0. UNION 이든지 UNION ALL이든지 사실 그리 좋은 SQL 작성은 아니다.
UNION이 필요하다는 것은 사실 두 엔터티(테이블)가 하나의 엔터티(테이블)로 통합이 되었어야
할 엔터티들이었는데, 알 수 없는 이유로 분리 운영되는 경우가 상당히 많다.
즉 모델링 차원에서 엔터티를 적절히 통합하여 UNION의 요건을 모두 제거하자.
1. 두 집합에 절대 중복된 튜플(레코드)가 발생할 수 없다는 보장이 있다면 UNION ALL을 꼭 사용하자.
두 집합에서 모두 각각의 PK를 조회하는데, 그 두 집합의 PK가 절대 중복되지 않는 형태
2. 중복이 있다 하더라도 그리 문제되지 않는다면 UNION 보다는 UNION ALL을 사용하자.
3. 만약 UNION이나 UNION ALL을 사용해야 한다면, 최소 필요 컬럼만 SELECT 하자.
'DATABASE' 카테고리의 다른 글
[펌] 트랜잭션 로그 백업(Transaction Log Backup)에 관하여 (0) | 2013.11.05 |
---|---|
TRUNCATE (0) | 2013.09.25 |
CRUD 의 중요도? (0) | 2013.08.02 |
DECODE, RANK()OVER(), UNION/UNION ALL (1) | 2013.08.02 |
DATA BASE _ 기초 (0) | 2013.07.10 |
설정
트랙백
댓글
글
f--Getdate() Select Getdate() --YYYY/MM/DD Select Convert(varchar(10),Getdate(),111) --YYYYMMDD Select Convert(varchar(10),Getdate(),112) --HH:MM:SS Select Convert(varchar(8),Getdate(),108) --HH:MM:SS:mmm Select Convert(varchar(12),Getdate(),114) --HHMMSS Select Replace(Convert(varchar(8),Getdate(),108),':','') --HHMMSSmmm Select Replace(Convert(varchar(12),Getdate(),114),':','') --YYYY/MM/DD HH:MM:SS Select Replace(Convert(varchar(30),Getdate(),120),'-','/') --YYYY/MM/DD HH:MM:SS Select Replace(Convert(varchar(30),Getdate(),121),'-','/') --YYYY/MM/DD HH:MM:SS Select Convert(varchar(10),Getdate(),111) + Space(1) + Convert(varchar(8),Getdate(),108) --YYYYMMDDHHMMSS Select Convert(varchar(10),Getdate(),112) + Replace(Convert(varchar(8),Getdate(),108),':','')
'DATABASE > MS SQL' 카테고리의 다른 글
전체 프로시져에서 특정 문자열이 사용된 프로시져를 찾는 법 (0) | 2017.02.07 |
---|---|
dateadd, datediff (0) | 2016.01.12 |
[업무] 임시 테이블을 이용해서 데이터 JOIN (0) | 2013.10.30 |
[기초] 임시테이블 @Table 만들기 (0) | 2013.10.30 |
[MSSQL] 문자열 이나 이진 데이터 는 잘립니다. (0) | 2013.10.07 |
설정
트랙백
댓글
글
출처 : http://kuaaan.tistory.com/120
얼마전에 개발서버에서 HDD가 가득찬 적이 있었습니다. 알고 보니 .mdf 파일은 수백메가 수준인데 .ldf 파일이 무려 30기가가 넘게 쌓여 있더군요. shrink 문을 날려도 줄지도 않고... 게다가 일단 트랜잭션 로그파일이 차게 되면 insert, select, delete 등 select를 제외한 아무 작업도 되지 않습니다. HDD 공간을 확보해도 인덱스라도 한번 재구성하고 나면 금방 다시 차버립니다.
DB가 깨졌을 때를 대비하여 DBA는 다음의 세가지 백업을 수행해야 합니다.
- BACKUP DATABASE [DATABASENAME] TO DIST = 'C:\Temp\BackupFileName'
- EXEC sp_addumpdevice 'disk',
- '[BACKUPDEVICENAME]', 'C:\Temp\BackupFileName'
- BACKUP DATABASE [DATABASENAME] TO [BACKUPDEVICENAME]
- BACKUP DATABASE [DATABASENAME] TO [BACKUPDEVICENAME] WITH DIFFERENTIAL
- BACKUP LOG [DATABASENAME] TO [BACKUPDEVICENAME]
1) 장애 시점까지의 DB 복구
⑤ 10월 10일 Transaction Log Backup
만약 10월 12일에 DB에 Fault가 발생했다고 가정하겠습니다.
Q : DB를 Fault 발생 시점으로 완전하게 복구할 수 있을까요?
A : Yes~! .ldf파일의 트랜잭션 로그만 손상되지 않았다면 가능합니다.
⑥ ①에서 백업받은 트랜잭션 로그를 Restore
2) 특정 시점까지의 장애복구 (STOPAT)
이러한 경우에도 복원이 가능할까요?
- RESTORE LOG [DATABASENAME]
- FROM [BACKUPDEVICENAME]
- WITH FILE = 3, STOPAT = '2009-10-15 14:15:23' , RECOVERY
- RESTORE FILELISTONLY FROM [BACKUPDEVICENAME];
- DBCC SQLPERF(LOGSPACE) -- 현재 로그파일의 상태를 확인한다.
- BACKUP LOG [DATABASENAME] WITH NO_LOG -- 실제로 로그를 삭제하는 명령
- --BACKUP LOG [DATABASENAME] WITH TRUNCATE_ONLY 위의 SQL과 동일한 효과
- SP_HELPDB [DATABASENAME] -- 대상 파일이름 확인 (name 컬럼)
- DBCC SHRINKFILE([LOGFILENAME], 5, TRUNCATEONLY) -- 5MB까지 파일을 축소
- -- DBCC SHRINKFILE(DBName_log, 5, TRUNCATEONLY) -- 보통은 이렇게...
'DATABASE' 카테고리의 다른 글
[펌] UNION과 UNION ALL 의 차이 및 주의 사항 (0) | 2014.02.28 |
---|---|
TRUNCATE (0) | 2013.09.25 |
CRUD 의 중요도? (0) | 2013.08.02 |
DECODE, RANK()OVER(), UNION/UNION ALL (1) | 2013.08.02 |
DATA BASE _ 기초 (0) | 2013.07.10 |
설정
트랙백
댓글
글
'DATABASE > MS SQL' 카테고리의 다른 글
dateadd, datediff (0) | 2016.01.12 |
---|---|
GetDate format 변환 (0) | 2013.12.16 |
[기초] 임시테이블 @Table 만들기 (0) | 2013.10.30 |
[MSSQL] 문자열 이나 이진 데이터 는 잘립니다. (0) | 2013.10.07 |
Truncate with condition - 조건 주고 TRUNCATE 하기 (0) | 2013.09.25 |
설정
트랙백
댓글
글
출처 - http://blog.danggun.net/1036
이전 글에서 테이블변수에 대해서 이야기를 했었습니다.
임시테이블과 테이블변수는 사용하는 방법면에서는 별차이가 없으나 성능상 차이가 있다고 합니다.
테이블 변수가 성능면에서 더 유리하다고 하는데....직접 비교는 해보지 않아서 잘 모르겠습니다 ㅎㅎㅎ
(참고 : [MSSQL] 저장프로시저에서 테이블(Table) 변수 사용하기)
그런이유로 테이블 변수를 더 권장하고 있으나....임시 테이블을 사용하는 방법도 알려드리겠습니다 ㅎㅎ
1.선언
선언 임시테이블이므로 크래딧테이블(Create Table)로 생성하면 됩니다.
1 2 3 4 5 | --리턴값을 받기위한 임시 테이블 --Create Table [생성할 테이블 이름] ( [컬럼명] [데이터형], ... , [컬럼명] [데이터형] ) Create Table #Result ( nIndex int , sName varchar (16) , sID varchar (16)) |
2.입력
1 2 3 4 | --Insert [임시테이블] Exec [sql문] Insert #Result Exec ProcTest @nIndox , @sName , @sID |
3.사용
1 | Set @nTemp = ( Select * From #Result) |
'DATABASE > MS SQL' 카테고리의 다른 글
GetDate format 변환 (0) | 2013.12.16 |
---|---|
[업무] 임시 테이블을 이용해서 데이터 JOIN (0) | 2013.10.30 |
[MSSQL] 문자열 이나 이진 데이터 는 잘립니다. (0) | 2013.10.07 |
Truncate with condition - 조건 주고 TRUNCATE 하기 (0) | 2013.09.25 |
테이블 복사 쿼리 (0) | 2013.09.25 |
설정
트랙백
댓글
글
으앙 정신없다. 오랜만에 MSSQL , 아 진짜 DTG때문에 죽겠다. 꿈에서도 작업함ㅋㅋ
하루의 데이터를 정리해서 요약하는 프로시저가 도는데
문자열 이나 이진 데이터 는 잘립니다.
라는 문구와 함께 매번 프로시저가 종료되었다.
원인은 입력 테이블의 크기보다 큰 값을 넣으려고 해서.
차량번호를 입력하는 VARCHAR(12) 짜리 열에
경기32바1111 과 같은 제대로 된 차량번호가 아닌 테스트용 임시 차량번호 테스트경기32바1111 을 넣으려고 하니
사이즈가 너무 커서 에러발생..
그래서 테이블을 지워버리고 해당 열을 VARCHAR(20)으로 사이즈를 바꿔서 새로 만들었다.
해결끝.
'DATABASE > MS SQL' 카테고리의 다른 글
[업무] 임시 테이블을 이용해서 데이터 JOIN (0) | 2013.10.30 |
---|---|
[기초] 임시테이블 @Table 만들기 (0) | 2013.10.30 |
Truncate with condition - 조건 주고 TRUNCATE 하기 (0) | 2013.09.25 |
테이블 복사 쿼리 (0) | 2013.09.25 |
저장 프로시저 만들었음. (1) | 2013.09.10 |
설정
트랙백
댓글
글
4 | The short answer is no: MySQL does not allow you to add a But the good news is that you can (somewhat) work around this limitation. Simple, safe, clean but slow solution using First of all, if the table is small enough, simply use the
The Unfortunately, this will be very slow if your table is large... and since you are considering using the So here's one way to solve your problem using the Simple, fast, but unsafe solution using
Unfortunately, this solution is a bit unsafe if other processes are inserting records in the table at the same time:
Unfortunately, it is not possible to lock the table and truncate it. But we can (somehow) work around thatlimitation using Half-simple, fast, safe but noisy solution using
This should be completely safe and quite fast. The only problem is that other processes will see table Disclaimer: I am not a MySQL expert, so these solutions might actually be crappy. The only guarantee I can offer is that they work fine for me. If some expert can comment on these solutions, I would be grateful. | ||
출처 : http://stackoverflow.com/questions/3704834/truncate-with-condition
'DATABASE > MS SQL' 카테고리의 다른 글
[기초] 임시테이블 @Table 만들기 (0) | 2013.10.30 |
---|---|
[MSSQL] 문자열 이나 이진 데이터 는 잘립니다. (0) | 2013.10.07 |
테이블 복사 쿼리 (0) | 2013.09.25 |
저장 프로시저 만들었음. (1) | 2013.09.10 |
[펌] 프로시저 만들기 (0) | 2013.08.29 |
설정
트랙백
댓글
글
TRUNCATE
설명
TRUNCATE 문은 명시된 테이블의 모든 레코드들을 삭제한다.
내부적으로 테이블에 정의된 모든 인덱스와 제약 조건을 먼저 삭제한 후 레코드를 삭제하기 때문에, WHERE 조건이 없는 DELETE FROM table_name 문을 사용하는 것보다 빠르다. TRUNCATE 문을 사용해서 삭제하면 ON DELETE 트리거가 활성화되지 않는다.
대상 테이블에 PRIMARY KEY 제약 조건이 정의되어 있고, 이 PRIMARY KEY를 하나 이상의 FOREIGN KEY가 참조하고 있는 경우에는 FOREIGN KEY ACTION을 따른다. FOREIGN KEY의 ON DELETE 액션이 RESTRICT나 NO ACTION이면 TRUNCATE문은 에러를 반환하고, CASCADE이면 FOREIGN KEY도 함께 삭제한다. TRUNCATE 문은 해당 테이블의 AUTO INCREMENT 컬럼을 초기화하여, 다시 데이터가 입력되면 AUTO INCREMENT 컬럼의 초기값부터 생성된다.
구문
TRUNCATE [ TABLE ] <table_name>
- table_name : 삭제할 데이터가 포함되어 있는 테이블의 이름을 지정한다.
예제
CREATE TABLE a_tbl(A INT AUTO_INCREMENT(3,10) PRIMARY KEY);
INSERT INTO a_tbl VALUES (NULL),(NULL),(NULL);
SELECT * FROM a_tbl;
=============
3
13
23
--AUTO_INCREMENT column value increases from the initial value after truncating the table
TRUNCATE TABLE a_tbl;
INSERT INTO a_tbl VALUES (NULL);
SELECT * FROM a_tbl;
=============
3
'DATABASE' 카테고리의 다른 글
[펌] UNION과 UNION ALL 의 차이 및 주의 사항 (0) | 2014.02.28 |
---|---|
[펌] 트랜잭션 로그 백업(Transaction Log Backup)에 관하여 (0) | 2013.11.05 |
CRUD 의 중요도? (0) | 2013.08.02 |
DECODE, RANK()OVER(), UNION/UNION ALL (1) | 2013.08.02 |
DATA BASE _ 기초 (0) | 2013.07.10 |