insert value  로.. 1초에 1000건.. 정도는 들어갈텐데... 별루 좋은 방법이 아닐것 같습니다.

차라리 파일로 시간별 정도로... 쌓으시고, 집계를 내야 하는 순간에만 파일을 읽어서 집계를 내는 것이 나을 듯 한데요...

예를 든다면... 파일로... 1시간 정도로 YYYYMMDDHHMISS.csv 형태로 쌓으시고.. 집계를 내야 하는 범위를 openquery로 적당히 읽어서... 집계...  테이블에는 집계 데이터만 있으면 되면.. 집계 만하시고.. 로그도 테이블로 보관하고 싶으시면.. insert select .. 로.. 저장.. 후 파일 삭제... 로그를 테이블로 보관하지 않아도 되면... 파일로 그냥 보관... 이런 시나리오...로...

제가 로그를 테이블로 저장했던이유는 파일로 저장하는것보다 디스크 I/O가 더 적을것같아서 테이블로 처리를 한것입니다.

파일로 저장하게 되면 웹서버에서 ASP로 텍스트파일 writeline 써서 저장하라는 말씀이신가요?

 그리고 동시에 천건이면, 파일을 천개의 세션에서 쓸텐데 지장이 없나요?

파일이 락이 걸린다던지 권한문제 같은걸로 처리가 안될거 같은 생가이 들어서요..

흠... 일반적으로 DB로 입력하는 것 보다 파일로 직접쓰는 것이 성능이 더 나았습니다.

물론 지금 홍순철님과 동일한 경우는 아닙니다만...

예전 경우에... 초당 3만개 정도의 insert value 를 처리해 달라는 RFP 여서... DB로 바로 입력은 불가능했었습니다.

그 때 해결한 방법은 먼저 파일로 쓰고, BCP로 넣는 것이었습니다.

언뜻 상상해도... DB에 입력하는 것이 성능상 불리한 점이 많습니다.

연결하고,  트랜잭션 보장해주고, 로그도 기록하고...

물론... 단 한건의 누수도 허용하지 않는 정밀도를 요구한다면... DB로 입력해야 할 듯.... (금융권 / 통신사 로그들)

위에 설명해주신 사항과 은행/증권 등의 입출금 로그와 중요도를 비교해보았을 경우 중요도가 차이가 있고, 어쩌다 발생하는 누수는 넘겨볼만한 사항같아서 파일로 쓰기를 추천했습니다.

ASP에서 파일을 어찌 핸들링하는지는 자세히 모르지만, DB 입출력보다 성능상 우월하지 않을까 예상해 봅니다.

(저는 APP 개발자 ..^^ 일단 Dephi로 구현했던 예전 APP는 파일로 입출력하는 것이 우월한 성능을 보였습니다.)

ASP 개발자 분이시라면 파일 I/O 하는 것을 구현해서 테스트 해보시는 것이 그리 어렵지 않으리라 생각되어집니다.

거기까지는 제가 테스트해보지를 못한 것이 아쉽군요.

누구 아시는 분 안계신가요?

만약 파일로 쓰시기로 하신다면 여러 새션에서 들어오는 로그를 직렬화 하는 부분도 생각해 보셔야 할거 같습니다. 동시에 파일에 쓰기 시작하면 로그가 엉킬수 있습니다.

그 부분도 고려해야 하겠군요. 과거 구현 내용에는 순서보장은 기록되어 있는 시간을 기준으로 해서 밀어 넣기만 했었지요.

그리고, 여러곳에서 가지고 오는 거라 각각의 에이전트들의 시간을 동일하게 맞추는 것이 깔끔하게 처리 안되었지요. 어느정도(1~3초) 오차는 보아줄 수 있는 상황이라 그냥 구현했던 듯...

위의 상황이라면 어느 정도 허용이 될 것도 같은데...

sunge 님 말씀대로 한곳에서 직렬화를 해서 파일에 기록해줄 녀석을 구현하면 의외로 쉽게  해결될 수도 있겠는데요...

말씀주신대로 ASP로 I/O 테스트 해봐야겠네요.

헌데 ASP 로 파일 쓰기를 하게되면 나외의 다른세션에서 파일을 쓰고 있을때 권한이 없어 액세스 하지 못할때가 있었던거 같았는데,

새벽시간때에 티안나게 테스트를 해봐야겠네요.

많은 말씀 감사합니다.

주변에 이런쪽 경험이 있으신분이 없네요.. 

광고쪽이다 보니, 업체가 한정적이고, 경쟁사이다보니... ^^;

현재 시스템 구성이 어떻게 되어 있는지 정보가 많이 부족한듯 합니다.

디비는 심플로 돌아가는지? 파일그룹은 어떻게 되어 있는지? sQL버전은? (파티셔닝 떄문...)

현재 순철님의 정보로는 인서트만 죽어라 하고 롤백 이슈는 없는 단순 로그성이라서...

파티셔닝이 가능하다면 이 부분을 추천해 봅니다.

또한 중간에 큐 서버를 두어서..패킷을 모았따가 주기적으로 한번에 저장하는 방식을 구성하는것은 어떨지요?

jevida(강성욱) 님 말씀감사합니다.

MSSQL2005 디비는 심플, 파일그룹은 D,E SSD디스크에 1개씩 구성되어있습니다.

중간에 큐서버를 둔다는것은 어플을 짜서 들어오는 패킷을 조절해서 서버에 저장하라는 말씀이신가요?

그리고 파티셔닝이라면 어떤걸 말씀하시는건가요?

파티션 테이블이나 파티션 뷰를 이용하라는 의미 같습니다.

로그가 수집 되고 있는 부분은 index를 만들지 않고  집계를 내어야 하는 부분은 index를 생성하고 집계를 산출하는 방식이 상상됩니다.

현 상태에서의 IOPS 등의 성능정보를 파악하고 접근하는 것이 좋을 것 같습니다.

위에 파티션 테이블로 성능 향상을 꾀하려는 것은 맞춤한 파일그룹과 디스크 구성이 갖추어져있다는 전제 하에 성능을 확보할 수 있는 것이라 생각됩니다.

MS-SQL 보고서를 보니, CPU 사용량도 한몫을 하더군요...
1CPU 로 처리했었는데 오늘 하루 모니터링 해봐야 겠네요.
파티션 테이블, IOPS 등에 대해서 검색해보고 알맞은 방법을 통하여 진행하도록 해야겠네요.
생기발랄, sunge, jevida(강성욱), Alucard 님 많은 말씀 너무너무 감사합니다.

위에서 나온 이야기 모두 조합하면 최고겠는데요 +_+

asp.net에서 바로 디비로 로그를 날리지 마시고 중간에 app서버에 로그 정보를 날리면 app가 일정량 저장해서 한번에 db에 내리면 db call횟수도 줄고 잘하면 트랜잭션 로그 크기도 줄일 수 있겠네요.

대신에 원체 로그가 많이 쌓이고 있으니 오랜 시간을 app서버가 받아줄 수 있을거 같진 않고요, 너무 많은 로그를 받아 놓고 디비에 반영하는것 자체가 app에 부하를 주면 웹에서 오는 로그를 받는데 느려질 수 있습니다. 시간과 저장된 로그수를 테스트 하셔서 적정 수치를 찾으시는게 중요할거 같네요. 

아니면 모은 로그를 한번에 파일로 내리는것도 괜찮겠네요. 파일로 내리는 건 IOCP같은 비동기 처리를 하시면 됩니다. 직렬화나 파일 분리 관리는 app서버가 관리해 주면 되니 간단해 지겠네요.

하지만 돈이 되신다면 스토리지 장비 좋은걸로 갈아타시면 왠만한건 다 해결되실듯 ㄷㄷㄷ

ps. 돈이 좋습니다 -  _-)a;;

1100건 Insert 는 cpu2장에 das 1set만 해도 떡을치는데 견디는데 select 가 관건이군.....그리고 random insert 면 disk 가 아작 날꺼고 sequential insert 이면 위치확인이 필요없이 막 막 박으면 되니 별 이슈가 없겠지...그래서 이럴때는 front db 서버는 index 없이 쌓고 backend db 서버는 index 만들고 쓰고 시간마다 linked server 로 가져와서 압축해서 쌓아 버리고 쓰면 좋지..........뭐 넘 작은 insert 라서 별 이슈가 없을듯 한데.........정 문제가 되면 그린플럼같은 db를 써 보는 것도 좋을듯

우와.. 내가 본 답글 중 최고수. 인듯....