'분류 전체보기'에 해당되는 글 1243건

이제야 겨우 알았어.
숨쉬는 건, 살아 있다는 건, 정말 멋진일이야.
가끔은 울어도, 눈물쯤은, 그런 눈물쯤 은
괜찮은 거야.
이제 즐겨봐.

(말해봐) 
슬픔에 빠져 허우적 대고 있었을때,
널 만났지, 불만 많은 나 같은 사람과는
너무 다른 모습에 얄미웠지만, 넌 너무 밝았어
웃고 말았지 나도 모르게 웃고 말았어
마음을 바꿀준비가 되어있어야~만 모두 바꿀수 있어
세상을 뒤집어 놓을 바람이 불어오는 걸 느껴야돼 자신을 벗어나

이제야 겨우 알았어.
숨쉬는 건, 살아 있다는 건, 정말 멋진일이야.
가끔은 울어도, 눈물쯤은, 그런 눈물쯤 은
괜찮은 거야.
이제 즐겨봐.

(말해봐)
나도 알아, 나처럼 쉬운일이 아니라는 걸
너도 알아, 어디까지 믿어도 되는 건지.
우리모두 알지만, 한번 믿어보는거야
개같은 내인생
달콤한 인생
장미빛 인생

이제야 겨우 알았어.
숨쉬는 건, 살아 있다는 건, 정말 멋진일이야.
가끔은 울어도, 눈물쯤은, 그런 눈물쯤 은
괜찮은 거야.
이제 즐겨봐.

라라라라라~~~~~~
장~미빛 인생~~~~

보통 ASP.NET 기반의 Web Application을 개발하다 보면, DLL들을 많이 이용하게 되는데,
만일 그 DLL의 일부 코드 수정을 반영 하려면 IIS 서비스를 다시 시작해야 한다.
그래서 보통 IISRESET.EXE 라는 명령어를 이용해 아예 서비스를 내렸다가,
다시 시작하곤 한다.

그러나 단순 DLL의 로직 몇가지 변경 때문에, IISRESET을 하기에는 비용이 비쌀 수 있다.
Web Publishing에 관련 된 대부분의 서비스를 내렸다가 다시 올리는 작업이기 때문에,
Reset 하는 시간도 많이 걸리는데다, IIS를 통해 데이터를 끌어 올리는 비용도 만만치 않다.

이에 IIS 6.0 대 부터는 Application Pool 이라는 것이 있어, 그 Application Pool 만
정리해 주면 새로운 DLL로 올려줄 수 있도록 제공하게 된다.

보통은 INETMGR을 띄워 해당하는 Application Pool 에서 오른쪽 버튼을 클릭해서 재생(혹은 Recycle)을 선택하면 되는데, UI 도구를 사용하는 것이라, 조작이 좀 귀찮긴 하다.

Utility 네임 스페이스 안에 있는 수많은 Utility 중에서 또 하나 기가 막히게 자주 쓰는 도구가 있으니 바로 Encoder 다. 언어별 Encoder는 아니고, URL과 HTML에 대한 Encoder다.

간혹 HTML 내용이 있을 때, HTML 소스 그대로를 출력해주어야 할 때가 있다.
그렇다고 우리가 번역하기엔 그 내용도 만만치 않고 귀찮다. 그 때 해주는 Encoder가 아래와 같다.

string Microsoft.SharePoint.Utilities.SPEncode.HtmlEncoder(원본 HTML이 담긴 string 내용)

위의 메소드를 쓰면 < 같은 것이 &lt; 이런식으로 바꿔 주게 된다. 거기서 Encoding된 내용을 웹브라우저에서 보면 <로 바뀌어 보이게 된다.

역으로 Encoding 된 것을 바꿔주는 것이 아래이다.

string Microsoft.SharePoint.Utilities.SPEncode.HtmlDecoder(원본 HTML이 담긴 string 내용)

두번째는 URL 인코더다.
간혹 URL을 통해 GET 메소드에 사용할 값을 넘겨 줄떄가 있다. 그 때 URL 내에 이상한 문자가 들어가면 안되는 경우가 있다.
예를 들어 "http://www.hind.pe.kr/test.php?value1=크크크 호호호호&value2=I&you" 라는 URL이 있을 때 value1에는 한글 가득한데다 그 안에 공백 문자가 있고, Value2에는 I와 you 사이에 & 이라는 문자가 있다. 이러면 명백한 오류. 그러나 그 값들은 꼭 넘어가야 한다고 할때... 처리해 주는 도구가 바로 아래이다.

string Microsoft.SharePoint.Utilities.SPEncode.UrlEncoder(원본 값이 담긴 string 내용) 

저것을 사용하면 크크크 호호호호 라는 값이 #FF02#F022..... 형태로 바뀌는 것을 볼 수 있을 것이다. ( 간혹 아예 value1=크크크 호호호호 라는 것을 통채로 인코딩하시는 분들이 있는데 그건 오해이자 막가는 것이다. 크크크 호호호호 만 인코딩 해줘야 한다. )

물론 이 역함수는 아래와 같다.

string Microsoft.SharePoint.Utilities.SPEncode.UrlDecoder(원본 값이 담긴 string 내용)

하나씩 하나씩 진기로운 도구들이 숨겨져 있어서 나름 재미를 뽐내는(?) SharePoint 인것 같다.

P.S 사실 알고 보면, .NET Framework 내에서도 위와 같은 작업을 해주는 Method들이 있다.

주의 : 이 작업은 MS SQL 2005에만 해당 되며, SQL 2000 혹은 다른 DBMS를 사용중이라면 아래의 쿼리 내용을 수정/편집 해야 한다.

MOSS 2007을 유지 관리하다 보면 데이터베이스 파일 크기에 대해 주의를 기울이게 되는데, 이를 미리 파악하기 위한 쿼리를 만들어 보았다. 하지만, 절대 아래의 쿼리가 튜닝된 데이터는 아니다. SELECT 만 좀 할 줄 아는 사람이 이것 저것 문서보면서 만든 쿼리이기 때문에, 성능상 문제가 되는 경우 알아서 편집을 해야 할 것이다.

아래의 쿼리를 Microsoft SQL Server Management Studio 에서 실행한다.

CREATE table #tot_resultSize
(
name sysname,
fileid smallint,
filename varchar(500),
filegroup varchar(50),
size nvarchar(13) null,
maxsize varchar(50),
growth varchar(50),
usage varchar(50)
)
DECLARE @cmd varchar(500);
DECLARE @name varchar(255);
--SET @name = 'WSS_CONTENT_80'
--INSERT #tot_resultSize  select @cmd = 'use ' +  quotename(@name) + N' exec sys.sp_helpfile'

DECLARE DBLits CURSOR
FOR select name from sys.databases ORDER by name;
OPEN DBLits;
FETCH NEXT FROM DBLits
INTO @name
WHILE @@FETCH_STATUS = 0
BEGIN
select @cmd = 'use ' +  quotename(@name) + N' exec sys.sp_helpfile'
INSERT INTO #tot_resultSize exec (@cmd)
FETCH NEXT FROM DBLits
INTO @name
END
CLOSE DBLits;
DEALLOCATE DBLits;
SELECT name, (convert(decimal, LEFT(size, LEN(size)-2))/1024/1024) as size FROM #tot_resultSize WHERE filegroup = 'PRIMARY'
SELECT name, (convert(decimal, LEFT(size, LEN(size)-2))/1024/1024) as size FROM #tot_resultSize WHERE filegroup IS NULL
DROP TABLE #tot_resultSize

이 내용을 보면 쿼리가 두 종류가 나오는데, 위쪽 결과 물이 데이터 파일, 아래쪽 결과물이 로그 파일들이다.

위의 목록을 모두 긁어서 복사한 뒤, Excel 파일에 붙여 넣기 해서, Excel로 정리해서 보면 보고하기도 좋고, 자신이 관리 처리하기 좋을 것이다.

코딩 습관이라는 것은 다들 개인적인 사상이 있고, 개인적인 취향이 있기 때문에,
무어라 따지기 힘든 것이 있다.

사실 내가 작성한 코드도 1달 정도 지나면 어느새 비판하고 싶은 내용이 많은 코드로 변해가고
스스로 짜증을 내며 나름대로 리팩토링을 한다.

왜 이런 생각을 가지고 쨨냐,
그것 말고 이미 다른 이들이 구현해 놓은 것은 없냐,
좀 더 효율적으로 처리하는 방법은 없냐,
코드의 길이가 너무 길게 되어 있지 않냐,
변수 이름이 알아보기 힘들지 않냐,
함수 이름이 알아보기 힘들지 않냐,
디버깅 하기에 어려울 정도로 너무 한줄에 다닥 다닥 붙이지 않냐, 등등..

그런데 그 중에서 내가 제 1 로 치는 최악의 코딩는

  같은 로직의 같은 코드를 계속 반복해서 넣은  코드

이다.

일단, 수정을 하나 할때, 미묘하게 변수 이름 하나만 달랑 틀린 코드가
반복해서 나열되어 있으면, 코드도 길어지고 복잡해지고,
수정하나 할때 그 반복된 만큼 수정하고...

특히나 단순 반복 작업을 제대로 못하는 나에게는 지옥과도 같은 코드다.
( 똑같은 것 반복 되어 있으면 내가 어디까지 수정했는지 까먹는 스타일...)

사실 단순 반복 작업은... 컴퓨터가 하는 것이라고 생각하는 나로써는 진짜 돌아버릴 코드다.
지금 그 단순 반복 작업을 유도하는 코드를 수정 중에... 짜증나서 쓴다.

SharePoint 에서 제공하는 다양한 Utility들이 있는데, 그 중 한가지 재미있는 메소드를 소개한다.

간혹 HTML 원본 문서가 오면, 그 문서의 HTML 관련 태그들을 모두 날리고 표현하고 싶을 때가 있다.

예전 프로젝트 때, 해당하는 HTML 태그를 날리는 기능을 하는 함수를 만들어서 쓴적이 있었는데,

문제는 이 기능을 만들어 넣으려면 점점 그 크기가 커지는 것을 막을 수 없었다.

( 처음에는 단순하게 < 태그 시작에서 끝이 > 인 것이라는 조건으로 시작 &nbsp; 에 &amp;에.....등등)

이 다양한 기능을 위한 레귤러 익스프레스를 가져와 썼지만, 역효과...

도리어 지우지 말아야 하는 부분까지 삭제되는 불상사가 발생하곤 했다.

이를 한큐에 해결 해주는 부분이 있었으니...

바로 이 메소드

string Microsoft.SharePoint.Utilities.SPHttpUtility.ConvertSimpleHtmlToText( 원본 Html 문자열, 가져올 길이)

이 메소드를 사용하면 간단하게 HTML 관련 태그들은 모조리 날리고, 제한 길이 만큼 잘라서 보내주게 된다.

(보통 이 메소드를 사용하는 때가, 요약을 보여줄 떄 많이 사용되는 듯.)

사용방법은 간단.

만일 HTML 원본 Text가 sHtmlSource 라는 변수에 담기고 100글자만 담고 싶다면....

string sResult = Microsoft.SharePoint.Utilities.SPHttpUtility.ConvertSimpleHtmlToText(sHtmlSource, 100)

하면 된다. 물론 Microsoft.SharePoint.dll 이 참조로 걸려 있어야 쓸 수 있다.!

어제 도착했다.

Microsoft Wireless Notebook Presenter Mouse 8000

나의 두번째 무선 마우스. 이번에는 수신기를 달기 싫어서 블루투스로 질렀다. 물론 수신기도 제공하는 모델로 구매했다.

하지만, 내 놋북에서 블루투스를 제공하므로 굳이 동굴이를 꽂을 필요가 없다는 사실.

그러나 단순한 무선 마우스를 구매하지 않았다.

바로 프리젠테이션 기능을 제공하는 마우스!!!!

프리젠테이션 모드에 들어가면 마우스 아랫쪽에 있는 버튼으로 프리젠테이션을 제어할 수 있다. (앞/뒤)

게다가 레이저 포인터도 나온다 !!!! ㅎㅎ

생각보다 블루투스의 감도는 그닥 좋지는 않지만, 그대로 만족스럽다.

강추보다는 한번 생각해보고 구매해보는 것이 좋다 정도?

일단 개인적으로는 마음에 든다. 조만간 있을 교육에 써먹어야 겠다 ㅋ

이 자료는 SharePoint Product & Technologies Team Blog에서 보았던 자료 중 하나 입니다. 그 문서를 나름대로 멋대로 번역한 문서입니다. 이 번역 문서는 MS 공식이 아니므로 인용될 수 없습니다. 인용하시고 싶으시면, 원본 문서를 참조하시기 바랍니다. 해당 문서는 Word 문서로 되어 있으며 이 내용의 원본 백서(White Paper)는 http://go.microsoft.com/fwlink/?LinkID=105623&clcid=0x409 에서 다운로드 받을 수 있습니다.

물리적 측면의 지침

전체 시스템 성능은 SQL 서버의 배치 방법, 네트워크, 물리적 저장 장소 형태 및 내부 캐쉬가 어떻게 구성되어 있는지에 따라 달라 진다. 또한 하드웨어 구성 시, 32bit 기반의 운영체제 및 데이터베이스로 운영되어야 하는 경우, 가급적 최신 버전의 SharePoint 제품군을 사용하는 것이 좋다.

중요: 단계적인 업그레이드 방법을 고객에게 제시 할 때, SQL 서버가 허용치 내의 응답 시간을 유지 하기 위해 SQL 서버 자원 중 최소한 한 가지 혹은 두 가지의 요소에 대한 업그레이드를 고려한다.

다음의 권장 사항들은 SharePoint 제품 군을 사용하는 서버에서 SQL 서버 데이터베이스를 이용하는 경우를 기준으로 제품군 팀에서 찾아낸 최적의 실례들을 기반으로 제시하는 내용이다.

독립적으로 설치된 SQL Server 2005를 사용하는 경우

• 단일 서버에 모든 서비스를 올릴 계획이 아니면, 이 독립적으로 구성된 SQL Server 상에 다른 Farm 역할을 할당하지 않는다. 오로지 SQL Server로서만 동작하게 한다.

• 구성 상황에 중대한 문제가 있는 경우가 아니면, SQL Server 구성 시 반드시 64-bit 운영체제에 64-bit SQL Server로 구성하는 것이 좋다. 이 구성이 최상의 설정을 위한 최고의 권장사항이다..

• SQL Server 2005를 사용할 때, 구성 상황에 중대한 문제가 있어 이전 버전을 사용하고 있는 경우가 아니라면, 최신의 Service Pack(이 문서가 작성될 시점을 기준으로 SP2)가 설치되어야 최적의 성능 보장이 가능하다.

• SQL Server에서 이용하는 I/O 채널들 (디스크들) 은 다른 응용 프로그램들(운영체제 가상 메모리 파일 또는 IIS 로그 등등)과 공유해서 사용하지 않는다.

자원 추가가 예상되는 확장 시 고려사항

SQL 서버 성능을 좌우 하는 세가지 중요한 자원 요소가 있다. CPU, 메모리, I/O 서브 시스템이 바로 그 세가지다. 혹시 구성요소 중 확장시킬 예정인 경우, 현재 또는 예상되는 작업량을 기반으로 각종 대처 방안들을 파악하여 최적의 방안을 찾고, 자원 또는 SQL 서버 자체를 추가 함으로써 얻을 수 있는 성능 향상되는 항목들을 확인하도록 한다. 보통, 제품 팀에서 권장하는 성능 향상 방법이 일반적으로 서버 자원을 추가 증설 방법이다.

하드웨어 선정 시, SQL 서버 지침 따르기

SQL 서버 팀에서 권장하는 하드웨어 관련 지침 사항 중에는 SharePoint 제품군에서 중요하게 다루는 중요한 요소들은 아래와 같다.

메모리

SQL 서버에서 적절한 메모리 용량에 대해 파악하려면 제일 먼저 메모리 수요에 따른 배포 규모를 확인한다. 편의상 배포 규모를 나눈다면 소규모, 중규모, 대규모 나눌 수 있다.

각 배포 규모는 아래와 같은 기준으로 나눈다.

• 배포 규모가 기준치에 위의 표에 미달하면, 소규모로 판단된다.

• 배포 규모가 위의 수치와 유사하거나, 2가지 정도 내의 항목만 넘어서는 경우 중규모로 판단된다.

• 배포 규모가 위의 수치를 초과하거나, 대부분의 값이 수치를 넘어서는 경우 대규모로 판단된다.

단 위의 표에서 나타내는 기준은 일반적인 구성 형태의 사이트를 기준으로 작성되어 있다. 만일 특이한 형태를 갖춘 형태로 구성되거나 계획 예정인 형태에서는 위의 지침대로 구분할 수 없다.

메모리 용량에 영향을 받는 다른 요소들로는 다음과 같다.

• SQL 서버 미러링을 사용여부

• 15MB 보다 큰 파일을 자주 사용하는 경우

대략적인 권장되는 메모리는 아래와 같다. (SQL 서버용 메모리)

• 최소 4GB의 메모리가

• 중규모에서는 8G 정도

• 대규모에서는 16GB 이상

Cache

• SQL 서버가 동작하는 서버 상에서 L2 캐쉬가 CPU당 최소 2MB 이상의 캐쉬 용량을 갖추어야 한다.

Bus Bandwidth

대형 버스 대역폭(bus bandwidth )은 성능 및 가용성을 확장하는 중요한 요소이다. 주의 해야 할 점은 디스크를 활용하는 것이 아니라는 것이다. 예를 들면, 네트워크 접근 등을 들 수 있다.

• 중간 규모에서 대규모의 서버들은, 대형 버스 대역폭을 갖추어야 시스템 가용성을 갖출 수 있다. 특히 multi-pathing 소프트웨어을 추가할 계획이면 중요하다. (작은 규모의 시스템에서는 대형 버스 대역폭이 가용성 증대에 대해서는 별의미가 없다.) 버스 대역폭의 가용성은 시스템 내 여유 Path를 고려해 줄 수 있으며, 하드웨어 장치에서 오류가 발생할 때, 단일 시스템이 갖는 문제점들을 방지할 수 있다.

• 대형 버스 대역폭은 순차 I/O 및 대규모 블록 전송을 자주 사용하는 시스템에서 특히 성능 향상을 가져올 수 있다.

• 대부분 순차적인 I/O를 사용하는 소규모 서버에서 PCI 장치인 경우 3대의 디스크 정도 연결되는 경우 병목현상이 발생할 수 있다. 또한 임의 I/O가 많이 수행되는 소규모 시스템인 경우에는 최대 8대 디스크 정도로 구성할 수 있다. 물론 PCI로 충분할 수 있지만, 가급적 PCI-X 기반의 인터페이스를 통해 처리되도록 하는 것이 좋다.

• 대형 버스 대역폭은 많은 수의 디스크 연결에 반드시 필요한 요소 중 하나이다.

• 시스템 위상의 제한으로 버스 대역폭의 용량에 제한을 받을 수 있다. 만일 시스템이 직접 연결형 디스크를 사용한다면, 디스크 슬롯 수의 제한으로 충분히 연결 할 수 없을 수 있다. 하지만, 만일 SAN 기반 시스템이라면, 이와 같은 물리적인 제한 요소가 없다..

• 대형 또는 고속 버스는 일반적으로 가격이 비싼 서버들에 구성된다. 간혹 대치 서버 없이 버스의 대역폭 용량을 늘릴 수 없는 경우가 있다. 하지만, 대형 서버들은 다양한 형태의 구성을 시도해 볼 수 있다. 이 경우 해당 서버의 담당자에게 상세한 점검을 요구한다.

Disk | RAID | SAN 인터페이스

시스템에서 사용하는 인터페이스에 따라 가용성 및 성능에 미치는 영향이 틀리다.

대형 드라이브들은 대부분 또는 동일하게 탐색 시간(Seek time)이 증가 될 수 있다.

아래 내용을 참고하여  인터페이스의 선택에 대해 한번 즈음 고려할 필요가 있다.

장점

• 강제 데이터 쓰기를 지원하므로, 데이터 복구율이 높다.

• TCQ를 갖춘 SCSI는 다중 I/O 요청을 처리할 수 있다.

• 핫-스왑(hot-swapping )을 지원한다.

• SCSI 는 채널당 최대 15개의 드라이브를 연결 할 수 있다.

• 물리적인 케이블 길이의 제한이 적다.

단점

비고

• 채널에 너무 많은 수의 드라이브를 연결하면, 전송률 제한에 도달하는 경우가 증가됨

인터페이스 : IDE

장점

• 핫-스왑(hot-swapping ) 지원

• 채널당 1개의 드라이브만 장착했을 때 높은 전송률을 보임

• 보통 SCSI 보다 큰 용량의 드라이브 장치가 많다.

• 보통 SCSI 드라이브 보다 GB 당 가격이 저렴하다.

단점

• 채널 당 I/O 요청에 대하여 한번에 하나씩 처리되는 경향이 강함

인터페이스 : SATA

장점

• TCQ가 내장된 SCSI 에서는 멀티 I/O 요청을 지원한다.

• 핫-스왑(hot-swapping ) 지원

• 대부분 채널당 한대의 드라이브를 지원하도록 설계되어 있는 경우가 많지만, 2~12개 이상의 SATA 채널을 지원하는 추가 인터페이스 카드가 있음

• 보통 SCSI 보다 큰 용량의 드라이브 장치가 많다.

• 보통 SCSI 드라이브 보다 GB 당 가격이 저렴하다.

인터페이스 : SAS

장점

• 매우 빠르다..

• SCSI 프로토콜을 지원.

• SCSI보다 더 많은 수의 디스크를 장착할 수 있다

비고

• DAS에서만 적용됨.

• 병렬 SCSI를 기술적 대치

• SATA 드라이버들에 대해 하위 호환.

Disk Topology (Direct Attach/SAN/NAS)

현재 시스템에서 사용 중인 Disk Topology은 시스템의 가용성과 성능에 영향을 미칠 수 있다.

• SQL 서버가 동작 중인 서버의 I/O 시스템에서 최소 대기 시간은 매우 중요하다. I/O 시스템에서 느린 응답을 주는 경우에는 아무리 다른 자원들(CPU나 메모리 등)을 추가해도 성능 향상을 가져다 주지 않는다. 단지, Farm 전체적인 이슈를 조장하고, 유발하게 된다. 그러므로 배포 전에 최소 지연에 대한 계획을 수립하고, 다음 섹션에 있는 감시 부분에서 설명하는 것처럼 기존 시스템에 대한 지속적인 감시를 해야 한다.

아래의 내용을 활용하여 Topology에 대해 정확히 왜 선택했는지에 대해 명확히 할 필요가 있다.

인터페이스 : SAN

장점

• 다중 서버에 연결하여 서비스 할 수 있다.

• 사용할 디스크의 수에 대한 제한이 없다.

• 많은 수의 서버를 쉽게 추가/관리할 수 있다.

• 서버간의 디스크 저장 공간을 재 설정할 수 있다.

• DAS에 비해 저렴한 비용으로 관리 할 수 있다.

단점

• 채널에 너무 많은 수의 드라이브를 연결하면, 전송률 제한에 도달하는 경우가 증가됨

인터페이스 : DAS

장점

• 최고속 대역폭을 제공

• 적은 수의 서버에 대해 관리하기 쉽다.

• SAN 보다 초기 비용이 저렴하다.

단점

• 서버 당 구축해야 한다.

• 디스크 장착용 슬롯 수 및 사용되는 인터페이스의 종류가 제약이 있다.

인터페이스 : 네트워크 기반 저장 장치

장점

• TCQ가 내장된 SCSI 에서는 멀티 I/O 요청을 지원한다.

• 핫-스왑(hot-swapping ) 지원

• 대부분 채널당 한대의 드라이브를 지원하도록 설계되어 있는 경우가 많지만, 2~12개 이상의 SATA 채널을 지원하는 추가 인터페이스 카드가 있음

• 보통 SCSI 보다 큰 용량의 드라이브 장치가 많다.

• 보통 SCSI 드라이브 보다 GB 당 가격이 저렴하다.

단점

• NAS 환경에서는 SQL Server에 필요한 I/O 응답 시간에 대해, 보장하거나, 관리할 수 없다.

• iSCSI 는 낮은 I/O 량에 대해서만 지원된다.

인터페이스 : SAS

장점

• 매우 빠르다..

• SCSI 프로토콜을 지원.

• SCSI보다 더 많은 수의 디스크를 장착할 수 있다

비고

• DAS에서만 적용됨.

• 병렬 SCSI를 기술적 대치

• SATA 드라이버들에 대해 하위 호환.