336x280(권장), 300x250(권장), 250x250, 200x200 크기의 광고 코드만 넣을 수 있습니다.
테이블을 생성할 때, 일련번호를 할당하기 위하여 IDENTITY를 사용하게 됩니다.

IDENTITY를 사용하할 때, 삽입한 행의 일련번호를 얻기 위하여 흔히 @@IDENTITY 함수를 자주 이용하게 되는데, @@IDENTITY 함수를 사용할 때 주의할 점이 있습니다. @@IDENTITY 함수는 현재 세션에서 삽입된 마지막 IDENTITY 값을 반환합니다. 따라서 트리거에서 다른 테이블의 IDENTITY가 새로 추가되거나 하게 되면 원치 않는 결과를 가져오게 됩니다.(@@IDENTITY 함수가 트리거에서 삽입된 IDENTITY 값을 반환함) 그래서 현재 범위(하나의 저장프로시저 내, 하나의 쿼리문 내 ...)내에서 마지막으로 추가된 IDENTITY 다음 값을 얻을 때는 SCOPE_IDENTITY() 함수를 사용해야 합니다. IDENT_CURRENT() 함수는 해당 테이블의 호출 시점의 마지막 IDENTITY 값을 반환합니다. 따라서 그 값이 다음에도 마지막 값이라고 보장할 수 없습니다. 다른 세션에서 새로운 행을 추가한 경우에는 그 값이 달라지기 때문입니다.


Posted by 당양부부34
336x280(권장), 300x250(권장), 250x250, 200x200 크기의 광고 코드만 넣을 수 있습니다.

자동으로 증가되는 IDENTITY(시퀀스)의 값을 변경하기 위한 쿼리.

테이블에 있는 데이터를 삭제해도 IDENTITY의 값은 변경안됨. 


아래의 쿼리를 실행하면 현재 IDENTITY의 값을 확인할 수 있다.(변경되지 않음)

DBCC CHECKIDENT(테이블명, NORESEED)



아래의 쿼리를 실행하면 IDENTITY의 값이 0로 초기화됨.

insert되면 1부터 시작.

DBCC CHECKIDENT(테이블명, RESEED, 0)


아래의 쿼리를 실행하면 IDENTITY의 값이 현재 컬럼보다 작을 경우 값을 현재 컬럼과 같도록 변경함.

DBCC CHECKIDENT(테이블명, RESEED)


Posted by 당양부부34
336x280(권장), 300x250(권장), 250x250, 200x200 크기의 광고 코드만 넣을 수 있습니다.

ORCLE이 정말 좋은 RDB라는 것을 알게 하는 것이 바로 페이징 기법일거라 생각되네요.
MySQL도 내부적으로 페이징이 가능한 쿼리를 지원해주지만 MSSQL은 최근 2005버전까지도... 좋은 페이징 기법을 소개하지 못하고 있는 것 같네요. 성능 좋은 페이징 기법이 공개된 것이 있기도 하지만... 초심자에게 쉽지 않은 쿼리들인 것 같습니다.
이에 조금 쉽게... 어떻게 하면 성능이 향상되는지를 설명해 보려고 합니다.

아래의 내용은 온라인상에서 바로 작성하는 내용이고 맞춤법등이 틀릴 수 있기 때문에 copy해서 사용하지 마시기 바랍니다.

개념을 잡는 정도로 활용하시면 좋을 것 같습니다.

MS SQL의 페이징 기법의 키는 TOP 키워드입니다.

#1. TOP과  클러스터드 인덱스

SELECT TOP 10 ID, subject, contents FROM TBL

이 쿼리는 누구나 알고 있는 쿼리입니다. 여기서 중요한 것이 TOP 10 입니다.  상위 10개만 갖고 오겠다는 뜻입니다.MSSQL은 내용저장을 클러스터드 인덱스 순으로 저장을 하게 됩니다. 만약 ID를 PK로 지정하셨거나 따로 클러스터드 인덱스로써 ID를 지정해 놓으셨다면 ID순으로 자동으로 정렬이 되어 상위 10개만 가져오게 됩니다.

기본키는 반드시 설정할 필요는 없습니다. 다만 레코드를 구분하는 아이디값을 대게의 경우 기본키로 놓게 되는데요.

사실 기본키가 성능에 있어서의 의미는 없다고 봅니다.(확인된 바 없음)

기본키는 자동으로 인덱스 컬럼이 된다는게 의미가 있겠죠. 그것도 테이블당 딱 하나 사용할 수 있는 클러스터드 인덱스로 자동 설정됩니다. 헌데 문제는 ASC로 설정된다는 것입니다.

웹페이지에서 최근 글의 경우는 대부분 DESC로 정렬합니다. 즉 최근 글을 먼저 표시해주지요. PK로 만들더라도 꼭 ID를 DESC로 인덱스하도록 만들어야 합니다.

바로 이 유일 인덱스 컬럼이 성능을 좌우하는 핵입니다.

초심자의 경우 인덱스의 중요성을 넘기는 경우가 많은데요. PK가 중요한 것이 아니라 정렬을 원하는 컬럼을 클러스터드 인덱스로 만들어 놓는 것이 성능에 가장 중요합니다.(레코드 수가 늘 수록 엄청난 성능 향상이 있습니다.)

팁) TOP 10 PERCENT라는 키워드도 가능합니다. 말 그대로 전체의 10%만 가져온다는 것입니다. 쓸모가 많은 팁이라 생각되네요.


#2. 가장 많이 쓰이는 페이징 쿼리

SELECT TOP 10 ID, subject, contents FROM TBL where ID not in (SELECT TOP 현재페이진 이전까지의 모든 게시물 수 ID FROM TBL order by ID DESC) order by DESC

참 좋은 쿼리입니다. MS SQL에서 나올 수 있는 가장 간결하고 좋은 쿼리가 아닌가 싶습니다.

저역시 작은 규모의 게시판 종류는 무조건 이 쿼리를 이용합니다. 유지보수가 편하기 때문입니다. 누구나 쉽게 알아 볼 수 있기 때문에 제가 도저히 못 봐줄 유지보수 프로젝트라면 다른 사람이 대신할 수 있는 쿼리이기 때문에... 이 쿼리를 즐겨사용합니다.

다만 이 쿼리에는 조건이 하나 붙습니다.

사용자들이 100페이징 이하(게시물 수로 2000개 이하정도)의 글을 되도록 조회한다.

이 쿼리는 2만건 이하의 테이블에 적당하다고 생각됩니다.

1페이지라고 하면 성능이 최고가 되며
2페이지라면 not in 안의 쿼리문에 의해 한페이지가 10개의 글이라고 가정하면 10개를 일단 불러 들이게 됩니다. 제거를 위해서죠.
3페이지라면 20개를 불러들여서 제거를 해야 하겠고
4페이지라면 30개를...

그럼 100페이지라면 990개의 글을 읽어 들여야 겠군요. 990개를 먼저 불러 들이는 것이 문제입니다.

가장 심플한 쿼리이지만 DB에 어느정도의 부하를 주는 쿼리라는 것을 알 수 있습니다.

개인적으로 레코드셋종류의 객체에 내용을 불러오는 쿼리는 0.1초 이전에 끝나야 한다고 생각됩니다. 물론 검색이 들어가면 이야기가 달라지지만 기본적인 형태(아무런 검색이 없는 경우)에서는 0.1초 이하에서 OPEN을 끝내는 것이 좋다고 생각되네요.

 

#3. ORDER BY문

아시다시피 ORDER BY문은 정렬의 조건입니다. 위 쿼리의 경우 ORDER BY ID DESC이니깐 ID에 대해 내림차순으로 정렬하겠네요. 사실 ORDER BY 문은 안써주는 것이 성능에 가장 좋습니다.

만약 ID를 클러스터드 인덱스로 지정해 놨다면 안써도 될 것 같습니다. 클러스터드 인덱스를 내림차순으로 지정해 놨다면 ORDER BY ID DESC는 성능에 전혀 영향을 미치지 않습니다. 가끔 MSSQL에서 서브쿼리를 썼을 경우 원하는 값을 리턴하지 않습니다. 이유는 모르겠습니다. 서브쿼리문을 가져오는 방법에서 더 빨리 가져오려고 하는 그 부분에서 나오는 문제일거라 생각되네요.

클러스터드 인덱스로 지정했을 경우 ORDER BY ID DESC는 되도록이면 넣으시는게 좋습니다. 정확성을 위해서!;


#4. 성능저하 요소 SELECT COUNT(*) FROM TBL

NOT IN 쿼리보다 심플한 페이징 쿼리는 MSSQL에서 없는 것 같습니다. 개발자 입장에서 프로그래밍하기도 정말 쉬운 쿼리입니다. 현재 페이지 번호만 넘겨주면 모든 것이 가능합니다. 가장 큰 장점이 바로 개발하기 편하다는 것이 겠고, 사용자의 웹접근 액션과도 상당히 잘 맞아 떨어집니다. 사람들은 10페이지 이상은 잘 보지 않으려는 경향이 있기 때문입니다.

NOT IN 쿼리는 생각보다 좋은 쿼리라는 것을 일단 말씀 드립니다. 단 조건은 INDEX를 잘 설정해줬다는 조건이 붙습니다.


게시판 등을 개발할 때 전체 게시물 수를 구해오는데 가장 많이 쓰는 쿼리문이 SELECT COUNT(*) FROM TBL입니다. 페이지 바로 가기 버튼을 위해서도 필요하고 게시물 번호를 붙히는 데도 쓰이기 때문에 쓰는 경우가 많습니다.

헌데 이 쿼리문 속도가 상당히 늦습니다. 100만건을 조회할 경우 1초가 넘어가 버리는 무식한 쿼리입니다. 야야~ 그럼 IDEX행을 가져와봐... 라고 하실 것 같습니다. SELECT COUNT(ID) FROM TBL ... 허나 애석하게 속도가 똑같습니다.

그리고 COUNT함수는 가능하면 (*)를 사용하시기 바랍니다. 이것이 정확한 방법입니다. COUNT(*)에서 속도향상을 위한 방법은 솔직히 말씀드려서 없습니다.

가장 좋은 방법은 테이블 하나를 만들어서 데이타 입력/삭제시마다 업데이트 하면서 게시물 수를 저장해 놓는 방법입니다. MSSQL 내에서는 트리거라는 기능을 제공합니다. INPUT/DELETE 시 UPDATE TBL_SETTING set TBL_COUNT = xxx 뭐 이런 식으로 짜 놓으면 되겠죠.

전체 게시물 수를 가져올 때는 되도록이면 트리거를 쓰거나 프로그램을 통해 정보를 저장하는 테이블에 업데이트하고 이 자료를 페이징시 가져오는 것이 성능을 위한 좋은 방법입니다.

1만건 이하라면 COUNT(*)를 쓰던 NOT IN을 쓰던 별 지장이 없다는 게 제 생각입니다. 고로, 자꾸 써먹어도 좋은 쿼리 들임을 일단 알려드립니다.


#5 성능향상에 가장 좋은 방법

1000만건을 테스트 해보지는 않았지만, 1페이지와 100만 페이지가 같은(해보진 않았죠^^)-혹은 비슷한- 성능을 보이는 쿼리는 다름 아닌 NOT IN보다 훨씬 더 간결한 쿼리입니다.

SELECT TOP 11 ID, subject, contents FROM TBL where ID <= 현재페이지 최상위 ID (order by ID DESC)

이 쿼리에서 가장 중요한 것은 ID가 클러스터드 인덱스로 ID를 설정하고 내림차순으로 지정되어 있어야 한다는 것입니다.

아무리 많은 글들도 0.1초안에 해결될만한 가장 성능이 좋은 쿼리문입니다. 동접자수 엄청나고 글 수가 많다면 이방법 이외의 방법은 사용하지 마시기 바랍니다.

허나 장점이 있으면 단점도 있습니다. 이 쿼리를 사용할 경우 ID값에 바로 접근하긴하기 때문에

이전 1 2 3 4 5 6 7 8 9 10 다음 <- 이와 같은 구성이 불가능하다는 것입니다.

그래서 TOP 10이 아닌 11을 사용한 것입니다. 1부터 10까지 구성은 힘들지만 다음페이지 버튼은 가능하기 때문입니다. 갯수가 11개면 다음 페이지가 있다는 이야기가 되며, 다음페이지의 최상위 ID값도 가져올 수 있게 됩니다.

어쨌거나 위 쿼리는 성능에 있어서는 더이상 좋을 수 없는 쿼리입니다. 분명 글이 많고 사용자 액션이 단순한 사이트라면 반드시 고려해보셔야 할 쿼리입니다. 이전 페이지 구현은 프로그램적으로 머리를 좀 굴려야 할 부분이긴 합니다.

어짜피 다음 페이지 버튼을 눌러야만 가능하니깐 이전 페이지의 ID값은 무조건 가지고 갈 수 있습니다. POST방식으로 이전 페이지 정보를 계속 넘기는 방법도 괜찮은 방법일 것입니다.


SELECT TOP 10 ID FROM TBL where ID > 현재페이지 최상위 ID order by ID ASC 를 어쩔 수 없이 쓰는 것도 한 방법이겠구요. 그래도 다른 쿼리들보다는 빠른 방식이니깐요. <- 이건 저도 테스트 해보진 않았습니다.


#6. 사용자 편의성도 좀 생각해 보자

대부분 웹사이트에서는 NOT IN쿼리가 좋은 방법입니다. 사용자 편의성에 있어서 좋은 선택이니깐요.

이전 1 2 3 4 5 6 7 8 9 10 다음 <- 이게 얼마나 편한 방법입니까^^; 그리고 사람들은 10페이지 이상 조회를 거의 하지 않기도 합니다.

성능을 생각한다면 #5번의 방법이 정말 좋은 방법이지요. 다만 사용자 편의를 위한 인터페이스 구현은 사실상 불가능 합니다. 이전 페이지 구현도 쉽지 않죠.

목표가 생겼습니다.

이전 1 2 3 4 5 6 7 8 9 10 다음

이 기능을 한번 구현해 보죠. 약간 성능 저하가 있더라도... 전체 NOT IN보다는 훨씬 더 빠르게 한다는 목표를 가지고...

일단 쿼리를 하나 보죠.

SELECT TOP pageSize*10+1 ID from TBL where ID <= 1페이지 11페이지 21페이지 등 각 1페이지의 처음 ID

이 쿼리는 페이지 바로가기 버튼 구현을 위한 쿼리입니다.

페이지 사이즈가 10개라고 하면 101개를 가져옵니다. 101개면 너무 많지 않냐 하겠지만 적은 갯수입니다.^^

컬럼이 하나밖에 없기 때문에 속도 저하가 거의 없는 쿼리죠.

이 결과를 가지고 1 2 3 4 5 6 7 8 9 10 다음 버튼 구현이 가능합니다. 이전 버튼 구현은 역시 약간 복잡하죠?

PageInfo = rs.getrows() 등의 좋은 메소드 등을 통해 배열로 만든 후 이 기능을 구현하는 것이 가장 좋은 방법일거라 생각됩니다.


SELECT TOP 10 ID, subject, contents from TBL where ID not in(SELECT TOP pageSize*(현재페이지의한자리숫자-1 / 0일때는 10) ID from TBL  where ID <= 페이지 11페이지 21페이지 등 각 1페이지의 처음 ID order by ID DESC)  and ID <= 페이지 11페이지 21페이지 등 각 1페이지의 처음 ID order by ID DESC


이 쿼리는 실제로 글을 뿌려주는 쿼리입니다. NOT IN이 쓰였네요. 하지만 10페이지 단위로 끊어서 10페이지 글 내에서 NOT IN을 사용하기 때문에 항상 빠른 속도를 내줄 수 있는 쿼리입니다.

페이지당 글 수가 아무리 많아도 100개 이하가 대부분이기 때문에 10페이지 단위로 끊는다고 해도 1000개의 글 내에서 모든 작업이 이루어지기 때문에 성능 저하는 거의(아예) 없다고 보시면 됩니다. 1000개정도 레코드는 아무것도 아니지요.


다만 걸리는 것은 페이지 바로 가기 버튼을 구현하기 위해 비슷한 쿼리를 두번 날렸기 때문에 두배의 비용이 든다는 거겠지요.


#7. 검색에 대한 이야기

검색 속도를 위한 가장 좋은 방법은 고가의 검색 엔진을 사용하는 것입니다. 검색엔진에 DB를 설정하고 URL 저장 방법만 설정해 놓고 스케쥴링만 해 놓으면 검색엔진은 알아서 DB를 검색하고 고쳐진 값에 대해서 URL 링크를 인덱싱해 놓습니다.

속도도 빠르고 한글의 경우 형태소 분석기를 통해 별에 별 검색도 가능하며 서비스 측면에서는 하일라이트 생성기등을 통해 사용자 편의성을 제공해주고... 뭐... 문제는 쩐이군요^^;

MSSQL에서 우리는 like '%xxx%' 검색을 많이 활용하게 됩니다.

SELECT ID, subject, contents from TBL where subject like '%xxx%'

이 쿼리는 xxx를 가지는 모든 subject 컬럼에 대해 검색을 하게 됩니다. 그럼 어떻게 해야 할까요. 넵~ 인덱스를 설정해야 합니다. subject에 대해서 넌클러스터드 인덱스를 설정해 주어야 합니다. 그러면 엄청난 속도 향상을 느낄 수 있습니다.

subject 는 varchar(255)형입니다. 그렇기 때문에 인덱스 설정이 가능합니다.

그럼 contents like '%xxx%'는?

헌데 contents가 text형이거나 varchar(max) (이건 2005에서 지원)라면?...

불행히도 인덱스를 줄수가 없습니다. MSSQL은 그다지 많은 인덱스 공간을 지원해주지 않습니다.

이경우 가능하면 input쪽에 varchar(4000)정도 만큼만 글을 입력하도록 제한하거나 varchar(4000)을 몇개 더 만들어서 DB저장시 나누어서 넣어주는게 좋습니다.

편법이고 지저분한 방법입니다.^^; 그래도 뭐 속도 향상이 있다면야... 모두들 어쩔 수 없이 text형도 검색을 하지만, 좋은 방법이 아닙니다. 글이 1만개만 넘어가다 상당한 부하가 걸릴 거라 생각됩니다.

넌클러스터드 인덱스만이라도 걸려 있다면, 성능은 무척 좋아집니다.

하지만 너무 방법이 지저분 하네요.

더좋은 방법이 있겠죠? MSSQL은 이런 경우를 위해 풀텍스트검색서비스를 지원합니다. varchar(MAX)나 text형 등을 시중의 검색엔진과 비슷한 방식으로 인덱싱하고 검색할 수 있는 방법은 제공합니다. 속도가 그렇게 좋지는 못합니다만...  형태소 분석기도 들어 있고 유사어 검색도 가능하고 정확도 정렬도 가능합니다. 다만 문제는 속도가 생각처럼 나오지는 않는 다는 것입니다. 특히 정확도 정렬을 위한 정렬의 경우 100만건 이상으로 테스트시 1초가 넘어가더군요.

그리고 MSSQL 2000에서 한글은 제대로 지원되지 않았습니다. 2005에서 한글 지원이 되는데... 실제로 띄어쓰기를 하지 않아도 검색이 되는 정도를 확인하였습니다. 동의어 검색도 가능하다고 하는데... 저역시 많은 테스트가 필요할 것 같습니다.

2000에서는 전혀 안쓰는 기능이었지만, 2005에서는 충분히 활용가치가 있을 것 같네요. 다만 호스팅 업체에서 이 기능을 지원하지 않는 다는 것이 가장 큰 문제입니다.^^; 인덱싱 속도는 꽤 빠르나 하드디스크를 많이 차지하기 때문에, 그리고 인덱싱시 꽤 부하를 주기 때문에 지원하지 않는 것 같으며, 2000의 경우 한글 인덱싱 자체가 잘 안되기 때문에 지원을 하지 않는 것 같습니다.

다만 MSSQL 2005라면 프로젝트에 충분히 쓸 수 있을 것도 같습니다. 제가 이번에 활용해보도록 하겠습니다.

상용검색엔진에 비하면 못하겠지만 어느정도 흉내를 내주고 CONTAINS(TABLE)/ FREETEXT(TABLE)등의 4개의 함수를 통해 SQL쿼리문 내에서 사용하기 때문에 개발하기가 수월합니다.

풀텍스트 검색엔진에 대한 이야기는 또 다음에 계속 하도록 하겠습니다.



정리;
속도 향상을 위해 가장 중요한 것은 바로 INDEX 설정!;

'IT > MSSQL' 카테고리의 다른 글

@@IDENTITY, SCOPE_IDENTITY(), IDENT_CURRENT() 차이점.  (0) 2014.01.14
MSSQL Identity 초기화 DBCC  (0) 2013.10.01
MSSQL Row Number 일련번호 구하기  (0) 2013.08.02
MSSQL XML 결과  (0) 2013.07.26
MSSQL 응답 속도 측정  (0) 2013.07.11
Posted by 당양부부34
336x280(권장), 300x250(권장), 250x250, 200x200 크기의 광고 코드만 넣을 수 있습니다.

MSSQL Row Number 일련번호 구하기

ROW_NUMBER() OVER(ORDER BY 정렬 기준이 될 컬럼 정렬방법) 별명

ex) ROW_NUMBER() OVER(ORDER BY COLUMN_IDX DESC) RNUM


SELECT

ROW_NUMBER() OVER (ORDER BY jb_idx) rnum

,ROW_NUMBER() OVER (ORDER BY jb_idx DESC) rnum2

FROM

[TABLE]

'IT > MSSQL' 카테고리의 다른 글

MSSQL Identity 초기화 DBCC  (0) 2013.10.01
MSSQL 페이징 쿼리 ( Paging Query )  (0) 2013.08.16
MSSQL XML 결과  (0) 2013.07.26
MSSQL 응답 속도 측정  (0) 2013.07.11
MSSQL @@IDENTITY , SCOPE_IDENTITY, IDENT_CURRENT 차이  (0) 2013.06.19
Posted by 당양부부34

2013. 7. 26. 14:23 IT/MSSQL

MSSQL XML 결과

336x280(권장), 300x250(권장), 250x250, 200x200 크기의 광고 코드만 넣을 수 있습니다.

SELECT *

FROM    [Table]

FOR XML RAW


1. Row 명칭 변경하기

FOR XML RAW('새로운 명칭')


2. 속성(attribute)를 요소(element)로 바꾸기

FOR XML RAW, ELEMENTS


3. Prolog 붙이기


Declare @strCode VarChar(1024)
 
set @strCode = '<?xml version="1.0" encoding="utf-8"?>'
set @strCode = @strCode +
 (Select  strData1 as String
        , strData2 as [Dex]
        , strData1 as [Damage]
From tb_WebServiceTest
 
--xml로 출력
FOR XML RAW ('Item'), ELEMENTS
)
 
select @strCode



Posted by 당양부부34
336x280(권장), 300x250(권장), 250x250, 200x200 크기의 광고 코드만 넣을 수 있습니다.

IO에 대하 통계를 OFF로 하시고, 다음은 Time이라는 설정을 해보도록 하겠습니다.


    SET STATISTICS IO OFF


    go


    SET STATISTICS PROFILE OFF


    go


    SET STATISTICS TIME ON


    go


위를 수행하고 다음을 수행합니다.


    SELECT  *


    FROM    Customers


실행을 하게 되면, 구문 분석 및 컴파일 시간과 실행시간이 나타나는 것을 알 수 있습니다.


시간의 단위는 밀리세컨드로 나타나게 됩니다.


시간에는 Cpu시간과 경과시간이 있습니다.


Cpu시간과 경과시간은 거의 비슷하게 나타나는 것이 좋습니다.


Posted by 당양부부34
336x280(권장), 300x250(권장), 250x250, 200x200 크기의 광고 코드만 넣을 수 있습니다.

MSSQL @@IDENTITY , SCOPE_IDENTITY, IDENT_CURRENT 차이

 

@@IDENTITY

@@의 의미는 세션이다. 즉 해당 세션에서 테이블에 insert 된 최종값을 의미한다.

멀티스레팅에서 엉뚱한 값이 들어갈 확률이 높다.

 

IDENT_CURRENT('테이블명')

세션에 상관없이 해당 테이블에 대한 최종값 또는 들어갈 값을 의미한다.

다른 IDENTITY 와 다르게 데이터 입력전에 그 값을 알 수 있다.

하지만 테으블 전체에 대한 값을 의미하므로 1인용 시스템에나 적합하다.

 

SCOPE_IDENTITY()

마지막으로 해당 프로세스 + 해당 세션의 최종 IDENTITY 를 가져온다.

이 함수가 실행되는 곳이 SP 이거나 FN 이거나 TRIGGER 일 수도 있다. 그렇다면 해당 프로세스+세션으로 제한을 걸고 IDENTITY 를 가져오기 때문에 실시간 키코드를 리턴해야하는 상황에서 가장 신뢰할 수 있는 함수이다.

 

타 DBMS

ORACLE : SEQUENCE.CURRVAL, SEQUENCE.NEXTVAL

MYSQL : LAST_INSERT_ID()

Posted by 당양부부34
336x280(권장), 300x250(권장), 250x250, 200x200 크기의 광고 코드만 넣을 수 있습니다.

MSSQL MS 에서 

 

변경 내용을 저장할 수 없습니다. 변경 내용을 적용하려면 다음 테이블을 삭제하고 다시 만들어야 합니다. 다시 만들 수 없는 테이블을 변경했거나 [테이블을 다시 만들어야 하는 변경 내용 저장 사용 안 함] 옵션을 설정했습니다.

 

발생시

 

[테이블을 다시 만들어야 하는 변경 내용 저장 사용 안 함] 옵션이 어디 있느냐..

 

그것은 바로

 

MSSQL Management Studio → 도구 → 옵션 → Designers → 테이블 및 데이터베이스 디자이너 → 테이블을 다시 만들어야 하는 변경 내용 저장 안 함

 

체크를 풀어주면 된다.

Posted by 당양부부34
336x280(권장), 300x250(권장), 250x250, 200x200 크기의 광고 코드만 넣을 수 있습니다.

select
a.name as table_name,
b.name as column_name,
c.name as data_type,
c.length as data_length
from sys.tables a
inner join sys.syscolumns b on a.object_id=b.id
inner join sys.systypes c on c.xtype=b.xtype
where a.name in
 (
 select name from sysobjects
 where xtype = 'U'
 )
and b.name in ('userid', 'user_id')
order by table_name

Posted by 당양부부34

2013. 4. 24. 18:04 IT/MSSQL

MSSQL DB 이관

336x280(권장), 300x250(권장), 250x250, 200x200 크기의 광고 코드만 넣을 수 있습니다.

A-SQLServer SQL Server에 존재하는 Migrate 데이터베이스를 B-SQLServer SQL Server로 동일한 데이터베이스명으로 이관하고 사용자(MigDBUser)가 접근 할 수 있도록 권한 처리를 한다.

   

  • 이관하려는 데이터베이스를 백업
    • 데이터베이스 백업
      • Microsoft SQL Server Management Studio 실행
      • A-SQLServer 서버에 연결한다.
      • Migrate 데이터베이스를 좌측 개체 탐색기에서 선택 후 우측 마우스 버튼 클릭
      • [작업] - [백업] 선택
      • 데이터베이스 백업 대화상자가 열린다.
      • [일반] 페이지 - [대상] Section 의 추가, 제거 버튼을 클릭하여 백업할 위치지정 (파일명 예: Migrate.bak)
      • [확인] 버튼을 클릭

           

  • 백업 데이터베이스 확인
    • Migrate.bak 파일이 생성되었는지 확인한다.

         

  • B-SQLServer 서버에 데이터베이스 이관
    • Migrate.bak 파일을 이관 B-SQLServer가 존재하는 PC 로컬 디스크에 복사 한다
    • Microsoft SQL Server Management Studio에서 B-SQLServer 서버 연결
    • 좌측 개체 탐색기에 존재하는 DB중 아무거나 선택하고 우측 마우스 버튼을 클릭
    • [작업] - [복원] - [데이터베이스]를 선택
    • 데이터베이스 복원 대화상자가 열린다.
    • [일반] 페이지 - [복원에 사용할 원본] Section의 라디오 버튼 중(데이터베이스, 장치) 장치를 선택하고 우측의 버튼을 클릭한다.
    • 백업 지정 대화상자가 열린다.
    • 백업 위치 영역 우측의 버튼 중 "추가"(맨 위) 버튼을 클릭한다.
    • Migrate.bak 파일을 찾아 선택하고 확인 버튼을 클릭한다.
    • 백업 지정 대화상자의 확인 버튼을 클릭하여 지정을 완료한다.
    • 장치 지정이 이뤄지면 복원에 사용할 백업 세트 선택 영역에 복원 대상 목록이 표현된다.
    • 최근 버전에 해당하는 데이터베이스 좌측의 체크박스를 선택한다.
    • [일반]페이지 - [복원 대상] Section의 데이터베이스를 Migrate (생성하려는 데이터베이스명)로 지정한다.
    • [옵션]페이지 - [복원 옵션] Section의 데이터베이스 복원 위치를 지정한다.
      • Mdf(데이터베이스 파일), ldf(로그 파일) 의 위치 및 파일명을 선택한다.
    • 이전에 존재하는 데이터베이스 일 경우, [옵션] 페이지 - [복원 옵션] Section의 최상위 체크 박스인 기존 데이터베이스 덮어쓰기를 선택한다.
    • 위의 설정을 수행하고 확인 버튼을 클릭한다.
    • 데이터베이스의 용량에 따라 수초에서 수분이 걸릴 수 있다.
    • 작업이 완료되면 생성되었다는 메시지가 뜬다.

         

  • 권한 설정 (삭제)
    • 이관한 데이터베이스는 시스템이 틀리므로 이름이 동일하더라도 내부적으로 가지고 있는 SID값이 틀려 프로그램으로 접근이 불가능 하다.
      • SELECT * FROM maste..syslogins, SELECT * From Migrate..sysusers
      • 위의 쿼리를 입력하면 틀린 SID값을 확인할 수 있다.
    • 먼저 이관한 데이터베이스의 전체 권한을 제거한다.
      • 권한 제거는 다른 UI에서 처리할 수가 없으며, 쿼리를 수행하여 삭제할 수 있다.
        • sp_dropuser 'MigDBUser'
    • 좌측 개체 탐색기에서 이관한 데이터베이스를 선택하고 우측 마우스 버튼을 클릭한다.
    • [속성]을 선택한다.
    • 데이터베이스 속성대화상자가 열린다.
    • [사용 권한] 페이지 선택을 클릭한다.
    • [사용자 또는 역할] 영역에 MigDBUser가 삭제되었는지 확인하고, 기타 다른 계정도 2) 항목과 같이 삭제 처리한다.

         

  • 권한 설정 (추가)
    • 좌측 개체 탐색기에서 [보안] - [로그인]을 선택하고 우측 마우스 버튼을 클릭한다.
    • [새 로그인]을 선택한다.
    • 로그인 - 신규 대화상자가 열린다.
    • [일반] 페이지 선택을 클릭하고 로그인 이름에 MigDBUser를 입력한다.
    • SQL Server 인증으로 체크하고 암호를 입력한다.
    • 암호 정책 강제 적용 등 옵션을 선택하고 기본 데이터베이스(Migrate)를 지정, 기본 언어 선택을 한다
    • [사용자 매핑] 페이지 선택을 클릭하고 우측에 접근할 데이터베이스 체크한다.
    • [데이터베이스 역할 맴버 자격] Section에서 db_datareader, db_owner등 권한에 맞도록 체크를 한다.
    • [확인] 버튼을 클릭하여 계정 생성을 완료한다. 
      =========================================================================================


      MSSQL2000 에서 백업 받은 DB를 다른 서버에 있는 MSSQL2000 에 복원 시켰을때 해당 DB의 사용자가 있는데 로그인 이름이 없어 로그인이 안되는 문제가 있다.

      이 문제는 해당 DB를 사용하는 사용자의 GUID가 syslogins.sid 테이블에 있는 것돠 다르기때문이다.

      EM에서 사용자에 가 보면 사용자 이름은 있는데 로그인 이름은 비어 있을 것이다.이것을 해결하기 위해서는 새 서버의 로그인 계정과 복원한 DB의 사용자 를 연결해야 한다.

      먼저 쿼리매니저에서 연결되지 않은 계정을 확인한다.

      sp_change_users_login 'Report'
      go;

      하면 사용자는 있는데 연결되지 않은 사용자의 아이디가 나온다.

      나오는 이름을 확인하고

      sp_change_users_login 'Update_one', 'username', 'username'

      go;

      를 하면 연결 작업이 끝난다. EM에서 사용자를 보면 로그인 이름이 생겨있다.


      이제 DB에 해당 사용자로 연결이 되는지 확인하면 된다.

      http://www.baragi.pe.kr/

      출처 : http://choiwonwoo.tistory.com/59

 

Posted by 당양부부34
이전버튼 1 2 3 이전버튼

블로그 이미지
주요 토렌트를 블로깅하고 있습니다. 토렌트 순위 등은 다른 사이트를 찾아보세요. 주요 웹툰 순위도 게재했어요 경제를 좋아하는 일산의 행복한 프로그래머입니다.
당양부부34
Yesterday
Today
Total

달력

 « |  » 2024.3
1 2
3 4 5 6 7 8 9
10 11 12 13 14 15 16
17 18 19 20 21 22 23
24 25 26 27 28 29 30
31

최근에 올라온 글

최근에 달린 댓글

최근에 받은 트랙백

글 보관함