MSFL :: 모리스 소프트웨어 공작소

ADO.NET 의 DataTable을 사용하는 경우에 DataTable내에서 데이터를 필터링하여 재 사용하여야 하는 경우가 많이 발생하게 된다. 이 때 고민에 빠지는 것이 DataTable의 데이터가 많은 경우에 다양한 조건으로 데이터를 필터링하여야 하는데 성능이 어떤 것이 좋은지? 에 대한 것이다. 여러가지 정보를 검색하던 중에 [  여기  ]에서 구체적으로 성능 시험을 한 부분이 있어서 정리해 본다. 위의 참고 자료를 기준으로 하면 근소하나마 DataView.RowFilter를 이용하는 것이 성능 상으로 좋다는 결론을 볼 수 있다. 그러나 또 궁금한 것은 DataTable에 대해서 Index의 설정과 이를 이용하는 경우와 이용하지 않는 경우의 필터링 조건에 따라 위의 결과가 다를 수도 있지 않을까? 하는 의문이다. 이 부분에 대해서는 MSDN에서 보조적인 설명을 해 주고 있다. "The Find and FindRows methods leverage the current index without requiring the index to be rebuilt." 위의 문장을 의역해 보면 "현재의 인덱스를 이용하면 인덱스를 재 구성하지 않고 사용하기 때문에 Find 나 FindRows 메서드가 최대의 성능을 낼 수 있다" 라고 할 수 있다. 즉, Index 를 구성하지 않는 컬럼을 기준으로 필터링을 한다면 DataView.RowFilter 를 사용하는 것이 좋다는 뜻이 된다. 이유는 DataView.RowFilter는 필터링을 하면서 해당 컬럼에 대한 인덱스를 구성하기 때문이다. 따라서 단순히 한번의 필터링을 한다면 그다지 큰 차이는 없겠지만, 필터링의 기준 컬럼의 값을 여러 번에 걸쳐서 필터링을 한다면 인덱스를 구성하고 이를 사용하게 되는 DataView.RowFilter가 더 좋은 성능을 발휘하다는 것이다. 물론 이런 생각과 정리는 많은 데이터를 사용하는 경우에 성능적인 향상을 볼 수 있다...

.NET 환경에서 작업을 하다보면 UI Thread 와 다른 작업 (예를 들면 Socket 통신 등, ...) 에서 생성된 Thread 간에 처리 결과를 다시 UI 의 컨트롤에 설정해야 하는 상황이 많이 발생한다. 지금도 UI 에서 버튼을 누른 후에 통신 구간을 (비동기 Thread 처리) 다녀와서 통신의 결과를 다시 UI의 컨트롤에 보여주어야 하는 상황이다. 이런 경우는 Thread 를 넘나드는 것이기 때문에 Cross - Threading Exception이 발생하게 된다. 물론 이런 경우를 해결하기 위한 아주 단순 무식한 방법으로 Cross - Threading Exception을 검사하지 않도록 하는 설정으로 다음과 같이 처리하면 된다. Control.CheckForIllegalCrossThreadCalls = false; 이 방법을 통해서 Exception은 발생하지 않고 정상적으로 동작하는 것을 확인할 수 있지만, 이 방법은 기존의 .NET Framework 1.1 처럼 동작하는 것이기 때문에 권장하는 방법은 아니다. MSDN에서 권장하는 방법은 Invoke 나 BackgroundWorker를 호출하여 해결하는 방법이다. 문제는 invoke를 위해서는 따로 delegate를 선언해서 처리를 해야 하고, BackgroundWorker는 다중 Threading 처리 시에 적용하는 것이다. [ Invoke를 이용해서 처리하는 간단한(?) 방법 ] this.Invoke(new MethodInvoker( delegate() { // 컨트롤에 처리할 값 설정 } )); 위의 같이 Windows Forms 에서 제공하는 MethodInvoker와 익명 Delegate를 이용해서 Thread Safe 방식으로 처리가 가능하다. 그런데 문제가 될 수 있는 부분이 해당 처리가 Cross Thread 상태에서 호출이 된 것인지? 아니면 그냥 동일 Thread 상에서 호출된 것인지...

SQL Developer를 사용하는 중에 장애가 발생해서 작업관리자에서 실행중인 프로그램을 죽여야 했다. 그 결과 Oracle에 접속을 하지 못하는 문제가 발생하였고, 아래와 같이 증상을 확인하면서 다시 복구를 해야 했다. ㅠㅠ [ ORA-01033 ] 강제로 죽였기 때문에 Log 파일 또는 DB 파일 (*.DBF) 가 삭제되는 경우에 발생할 수 있다. 물론 파일은 있지만 REDOXXX.LOG 파일이 갱신되지 않아서 문제가 되는 경우가 더 많다. > 해결 방법 SQL> sqlplus system/비밀번호 as sysdba; SQL> shutdown SQL> startup 상기와 같이 다시 구동했을 때 아래와 같은 문제점이 또 보일 수 있다. (거의 대부분) ORA - 01113 : file 3 needs media recovery ORA - 01110 : data file X: 'xxxxx.dbf' 위의 오류는 파일 3번에 복구가 필요하며, 해당 파일은 xxxx.dbf 라는 것이다. [ ORA-01113 ] 복구 과정을 통해서 복구가 되면 해결이 된다. > 해결 방법 SQL> recover database until cancel; 또는 SQL> recover database until time '2013/11/08: 12:00:00' 일반적으로 상기 과정을 통해서 오류가 해결이 되겠지만, 실제로 파일이 삭제되고 없는 경우는 ORA-01157 오류가 발생하게 된다. (탐색기 등에서 파일을 삭제한 경우) 이런 경우는 파일은 없는데, 파일에 대한 정보가 남아있는 것이기 때문에 SQL> alter database datafile '/oracle/oradata/xxx.TBL' offline drop; SQL> alter database open; SQL> drop tablespace [tablespace name...