시도니 2018-11

전통적인 관계형 데이터베이스는 무조건...

하드웨어는 램빨과 디스크 IO 빨입니다.

혹시 sql이 무료버젼 아닌지요.

무료버젼 express 의 경우 최대 할당할 수 있는 자원량이 한정됩니다.

에디션에 대한 문제가 아니라면...

자원을 투입할 만큼 넣고... 나머지는 쿼리 튜닝 밖에 방법이 없습니다.

뭐. 외부스토리지를 쓸 수 있겠지만....

그 정도 투자는 무리이실테니..

미수맨 2018-11

제가 듣기로 아주 저급한 디비라고 들었습니다

한창우 2018-11

저라면 진료실 컴의 램 용량에 올인하겠습니다. ^^

미수맨 2018-11

시퓨속도와  램을 늘리는게 의미가 있을까요?

박문형 2018-11

SSD 안에 DB 화일이 있다면 이미 속도는 PC에서는 최고급이라고 볼수 있고

빠른 외장 RAID 스토리지를 구해서 BMT 해보는게 다입니다..

단 RAID에서 스트라이프 사이즈는 DB 데이터 이므로 작게 해야 합니다..


디비랑 설치한 업체가 있을테니 그 업체랑 느리다고 상의해보세요..

꿈돌이친구 2018-11

10만건 정도에 느리다면 조회 쿼리가 잘못된거죠.
접속 계정을 알고 계신다면 실행계획 분석하시고 쿼리 튜닝이 필요하다고 봅니다.

엠브리오 2018-11

년도별로 분리하는게 어떨까 싶군요.

주원재 2018-11

필요 인덱스 확인해서 추가하는 것만으로도 좋은 효과를 볼 듯 합니다.

DAP박인호 2018-11

1인 정보를 불러올때 느리면
Index가 생성 안되어서 그럴것 같은데
의사랑 프로그램을 한번 살펴보고 싶은 1인
꽤 유명한 것 같은데...

엠브리오 2018-11

챠트번호 한껀당 데이터가 얼마나 되는지 모르겠지만..
10만껀 정도인데 저렇게 느리다면 애초에 DB설계가 잘못된게 아닐까 싶군요.

송주환 2018-11

테이블 인덱스만 만들어줘도 해결될 것으로 보입니다.. 10만건이면 많은 데이터도 아니구요.

엠브리오 2018-11

대충 챠트하나당 1MByte라고 가정한다면 10만껀일 경우 대략 100 기가바이트 정도 되네요.
지금 용량이 얼마나 차지하는지 모르겠지만, 윈도우10 자체용량은 100 기가 이하일겁니다.

400G SDD의 용량이 절반이 넘어갔다면 1테라 SSD로 바꾸어 보시기 바랍니다.
SSD의 특성상 용량이 차오를수록 느려지기 시작하고 빨리 망가집니다.

미수맨 2018-11

디비의 크기는 지금보니까 6.45 기가입니다. 사진 파일은 21.9 기가입니다

이윤주 2018-11

의사랑 DB사이즈 생각보다 작습니다.
이정도크기면 램디스크로 사용해도 될정도지만 현실에서는 절대 불가.
하드웨어적인 문제가 아니고 현재 사용하고있는 진료실컴의 소프트웨어문제같습니다.
실험적으로 db를 일반하드에 복사사용해봐도 비슷하게 지연될거 같습니다.

엠브리오 2018-11

DB용량은 정말 작네요.
제가 보기에도 프로그램의 문제일 가능성이 높아보입니다.
튜닝 테스트가 필요한 시점이네요.

이윤주 2018-11

관여하고 있는 의원의 경우
차트번호 20,000번 차트건수는 13만건정도에 1G정도 용량입니다.
그냥 개인적인 생각으로는 DBSEIII+ 수준의 sql이라고 하기도 애매한 순차적DB구조 같습니다.
매월말일-1일에 무조건적으로 매번 DB업데이트(수가변동등으로)하는데 이때 reindex합니다.
진료차트의 성격상 어떤 관계형DB구조도 필요없습니다. 그냥 순차적자료 저장입니다.
관계형이 필요할경우 환자의 가족을 연계시키는 정도.
매건별로 증상 병명 처방내역만 있는 가변형데이타구조.완벽한 텍스트데이타입니다.

아나벨가토 2018-11

의사랑이면 병의원급에서 가장 많이 쓰는 두개 중에 하나인데, 이게 의료법상 법적으로 보관의무가 있어서 아무나 쉽게 DB 를 못건드리는것으로 알고 있습니다.

CPU 사양이나 램, PCIE SSD 로 봐서는 개인이 할 수 있는 만큼은 다하신거 같은데, 평소 CPU 온도와 내부 쿨링, 실시간으로 돌아가는 소스등  다른 부하요인이 있는건 아닌지 확인해보시고,이상이 없다면 의사랑 본사나 의사랑 영업담당자를 통해 먼저 알아보시는게 좋습니다.
아마 현재로선 처치처방묶음 등록하신거등 여러가지이유로 다른 전자챠트도 갈아타기도 어려운 상황이고 다른 전차챠트로 갈아탄들 똑같은 상황일겁니다.

DB에서 밀리기 시작하면 별도로 서버구성해서 빼야될 수도 있습니다.
(단, 이렇게 해서 해결안된 병원이 있습니다. 이 병원은 챠트 자체를 아예 갈아타고나서야 해결되었습니다.
윗분들이 말씀하신 전자챠트 DB 자체 튜닝이나 최적화문제 때문이죠.)
그리고 간혹 DB 자체가 꼬여서 문제가 생기는 경우가 있는데, 이 부분은 의사랑에서 어느정도 엔지니어가 잡아줄 수 있습니다.
DB 패킹을 다시 해서 해결해주는 경우가 있더라구요.

특히 사진이 많고, PACS 뷰어등으로 땡겨서 봐야할게 많다면 네트워크 까지 한방에 고민해야봐야합니다.
DB가 많아져서 터진다던지, 의사랑 DB 가 사용하는 SQL 서버자체 문제라면 의사랑 내부 개발자들이 해결해야되는 상황입니다.
의사랑 자체가 아마 SQL 서버 DB까지는 개발 못했을거고 무료 나 유료를 구입하여 사용하고 있을건데, 유료 DB여야 아마 의사랑 개발자들도 어찌 할 수 있는 상활일겁니다. DB 업체로 부터 의사랑도 다시 기술지원을 받습니다. 무료 DB면 답없습니다.

이윤주 2018-11

의사랑DB는 일반사용자가 DB자체조작등 어떠한것도 할수 없는 방식입니다.
1. 의사랑 담당영업사원을 불러서 대책요구.(아마도 오래된 5년넘은 차트 분리해서 DB크기 줄이는 방식권할겁니다.)
2. 진료실컴에서 불필요한 모든프로그램 다 삭제. 원도우만 깨끗이 설치하고 의사랑만 사용.
3. 시퓨나 램 SSD는 충분한 사양입니다. 다만 OS를 원도우7으로 사용하면 문제가 해결될수도 있습니다.
의사랑DB가 도스로부터 출발된DB를 계속적으로 사용해서 최신os에서 최적화안되어 있을거 같습니다.
몇년전에 DB제작사 찾아본적이 있는데 찾지 못했습니다. 제작사 지원이 안되니까 의사랑입장에서도
그냥 그냥 땜방으로 사용하는 형식인거 같습니다.
의사랑 아직도 XP에서 잘돌아갑니다.

미수맨 2018-11

의사랑 권유대로 최근 데이터 7년분만 불러오는것으로 조정하였습니다.
감사합니다.

엠브리오 2018-11

DB엔진을 최신버전으로 바꾸면 어찌될지 문득 궁금해지네요. ㅎㅎ

안형곤 2018-11

예전에 의사랑 관련 장비를 좀 관리해드렸는데....

최신 장비로 바꾸고 빠른 SSD로 바꾸는거 외에는 할게 없습니다.