Data Store

``` oracle.net.ns.NetException: Listener refused the connection with the following error: ORA-12519, TNS:no appropriate service handler found. ``` ```sql select * from v$resource_limit where resource_name = 'processes'; ``` 프로세스 수가 최대치에 육박하여 더 이상 요청을 처리할 수 없어 발생하는 문제. 커넥션 풀 close를 제대로 하지 않는 것으로 보임. Hikari maximumPoolSize 기본값은 10인데, 이를 3으로 변경하고 수행하니 커넥션에 여유가 생겨 pending 걸리던 구간 통과하여 끝까지 TC 수행됨. 하지만..

구축 https://github.com/deviantony/docker-elk JVM Heap이 256m으로 작게 설정되어 있어서 이를 늘려주어야 함. docker-compose.yml 의 `` ES_JAVA_OPTS, LS_JAVA_OPTS`` 설정. 설정하지 않으면 ES나 Logstash 인스턴스가 java.lang.OutOfMemoryError: Java heap space 뜨면서 죽어버릴 수 있음. 설정 후 Management - Stack Monitoring 항목 확인해볼 것. https://www.elastic.co/guide/en/logstash/current/jvm-settings.html 사이즈는 어떻게? 4 ~ 8 정도로 하라고 나와 있지만 여의치 않으면 2g 정도로도 잘 돌아간다. h..

컨슈머? 파티션 리더에게 메시지 가져오기 (Consume) 다른 메시지큐 처럼 소비하면 없어지나? ⇒ X 기본값 7일 동안 저장했다가 삭제 ⇒ 필요하다면 이미 가져온 데이터도 다시 가져올 수 있음 ⇒ 여러 컨슈머 그룹에서 메시지 수신 가능 컨슈머 중요 옵션 group.id 컨슈머 그룹 식별자 fetch 관련 fetch.min.bytes 한 번에 가져오는 데이터의 최소 사이즈. 지정한 사이즈 보다 작은 경우 요청에 응답하지 않고 데이터가 누적될 때 까지 기다림. (default 1byte) fetch.max.wait.ms 사이즈가 작아서 기다린다면 최대 몇 초 동안 기다릴건지? (default 500ms) max-wait 시간 지나면 쌓인 데이터가 min-bytes 보다 작아도 그냥 컨슈머로 보내기 때문에..

Oracle로 설명했지만 대부분의 DB in docker image에서 통하는 내용이다. 문제 상황 Oracle docker image를 사용해서 DB 올리고 작업하고 있는데, insert된 row들 날짜 필드 시간이 안맞는다. (UTC -> Asia/Seoul)로 timezone 설정이 필요한 상황이다. ```sql SELECT SYSDATE, CURRENT_DATE, DBTIMEZONE, SESSIONTIMEZONE FROM DUAL; -- 현재 시각은 한국 기준 05-19 00:38:51 +-------------------+--------------------------+----------+---------------+ |SYSDATE |CURRENT_DATE |DBTIMEZONE|SESSIONT..

Pagination https://en.wikipedia.org/wiki/Select_(SQL)#Result_limits 12c 버전 이후라면? : Row Limiting Clause https://oracle-base.com/articles/12c/row-limiting-clause-for-top-n-queries-12cr1 myjamong.tistory.com/170 12c 이전에는? https://stackoverflow.com/questions/241622/paging-with-oracle https://blogs.oracle.com/oraclemagazine/on-top-n-and-pagination-queries https://use-the-index-luke.com/sql/partial-re..

flyway는 DB에 schema_version 테이블을 유지하면서, DB 상태를 버전으로 관리할 수 있게끔 도와준다. (나중에 DB를 실행해도 버전에 맞게 데이터를 밀어넣어준다.) DB에 데이터가 존재하는 상태에서 flyway를 적용할 때 발생하는 문제 ``` Caused by: org.flywaydb.core.api.FlywayException: Found non-empty schema "SYSTEM" without metadata table! Use baseline() or set baselineOnMigrate to true to initialize the metadata table. ``` DB가 비어있지 않아(상태를 가지고 있어) flyway를 적용할 수 없다는 것. flyway를 사용하려면 ..

https://dba.stackexchange.com/questions/42997/longest-prefix-search-in-oracle https://asktom.oracle.com/pls/apex/f?p=100:11:0::::P11_QUESTION_ID:4246230700346756268 일단... 쿼리 하나로 해결하자면 이렇게도 가능은 한데, 성능 관점에서는? ```sql SELECT MIN(t.BIN_NO) KEEP (DENSE_RANK FIRST ORDER BY LENGTH(t.BIN_NO) DESC) FROM CARD_BIN t WHERE '654103' LIKE t.BIN_NO || '%'; ``` DBA 문의 결과... 다음과 같이 인덱스 걸고 ```sql create index CARD..

DB 클러스터링 DB 장애 시 가용성을 유지하기 위한 클러스터링 방안 Oracle 기준이긴 하지만, 다른 DB에서도 비슷한 옵션이 있는 경우 있음. HA ( High Availability ) 같은 장비를 Active 1대 , Standby 1대로 구성해서 Active에 문제 생기면 Standby로 서비스 하는 방식. Active, Standby 각자가 별도 storage를 가지고 있음. => Active와 Standby의 데이터 동기화 문제 및 성능 저하 => Active 가 죽고 Standby로 전환되기 전 그 사이에 발생하는 트랜잭션은 유실됨 *** 오라클에서는 데이터 가드 라는 이름으로 제공하고 있다. *** 위와 같은 문제점 때문에 OPS 방식이 8i 버전까지 사용되었음. OPS ( Oracle..

기본 포트는 6379 Java Redis Client는 다음 두 가지 Jedis Lettuce SpringBoot 2.0부터 lettuce가 기본 Client Lettuce is a fully non-blocking Redis client built with netty providing Reactive, Asynchronous and Synchronous Data Access . Redis의 LRU eviction docs https://github.com/lettuce-io/lettuce-core/wiki/Connection-Pooling default expire time은 없다. 그래서 웬만하면 설정해 주는 것이 좋다. redis의 자료형(List, Set, ...) Redis command ( a..

쿼리에 파라미터 넣어서 필터링 해도 되고 앱에서 로직으로 필터링 해도 되는거라면, 보통 앱에서 하는게 더 좋다. 왜? 장기적으로 봤을 때, 쿼리는 간단하게 가져가는게 좋다. 비즈니스 로직은 앱단에 두고 쿼리는 간단하게 가는 것이 보통 변경에 유리한 구조이기 때문. 유지보수, 관리, 가독성 측면에서. JPA 같은 ORM으로 마이그 할 여지가 있을 때 로직이 쿼리에 들어가 있으면 몹시 곤란하다. 서브 쿼리는 일반적으로 지양하는 편이 좋다 스칼라 서브쿼리는 리턴되는 건수마다 결과를 수행하기 때문에 대량의 결과가 리턴되는 쿼리에서는 성능이 몹시 떨어진다. 스칼라 서브쿼리란? subquery 위치에 따라서 다음과 같이 부른다. SELECT 절에 있는 서브쿼리 : 스칼라 서브쿼리 FROM 절에 있는 서브쿼리 : 인..

파티셔닝(단편화) 란? 저장해야 하는 정보가 많은 대규모 시스템의 경우 하나의 DB에 모든 정보를 저장해서는 제대로 된 응답성을 기대할 수 없다. read가 많이 발생하든, write가 많이 발생하든 DB 저장하는 정보가 많을 수록 스캔 속도도 느려지고, 요청이 많은 경우 큐에 작업이 쌓이면서 응답도 느려진다. 그래서 DB를 여러대 운용해서 응답을 좀 분산해보자, 라는 생각을 하게 되는데, 가장 쉽게 생각해 볼만한건 Master DB의 데이터를 복제한 Slave DB를 두고, read를 분산하는 것이다. 스캔 속도는 그대로겠지만 요청을 분산할 수 있다. 그러나 이 방법은 write는 분산되지 않는다. Master에 write가 발생하면 이를 Slave에 복제 해줘야 하므로, 복제하면서 같은 내용의 wri..

포인트 읽기 - 포인트 차감 순으로 DB 작업이 발생하는 상황이었다. ```java @Transactional public foo bar() { // SELECT MemberRestMileageInfo member = getMemberMileageByKey(memberKey); ... // UPDATE memberInfoMapper.update(member); } ``` 이런 상황에서 같은 `` memberKey`` 를 대상으로 빠르게 두 번 요청하면 갱신 손실 문제가 발생한다. ``` T1 T2 start transaction start transaction SELECT SELECT UPDATE UPDATE ``` 즉, 먼저 들어온 트랜잭션이 UPDATE 하기 전에 다른 트랜잭션이 SELECT를 해버리..