'어장 Develop/어장 DBMS'에 해당되는 글 20건

OS 변경설치를 위해 개인적으로 테스트하기 위해 작성한다.

1. 테스트 데이터 베이스 생성 및 테스트 계정 생성

먼저 테스트용 서버에 PostgreSQL 13을 설치, 신규 데이터베이스 생성과 신규 계정을 생성한다.

만약 순서가 잘못된다면 권한과 관련해서 조금 많이 꼬여버리니까 주의해야한다. 모든 내용은 psql 명령어로 수행했다. 

2. 신규 테이블 생성 및 데이터 입력

여기서부터는 일반 SQL 쿼리와 크게 다르지 않다. 사실 위의 grant 명령어들도 SQL 이나 다를바 없긴 하지만 뭐...

처음에 postgres로 테이블 생성하고 이후에 DBEaver로 신규생성계정으로 접속하니 권한이 없어 select도 못하는 상황이 존재했다. 이후에 권한문제임을 깨닫고 접속 자체를 신규계정으로 접속, create table 명령어를 수행하는 방식으로 재설정했다.

3. PostgreSQL 데이터 베이스 백업 및 복구

임시데이터들도 모두 갖춰졌겠다, 이젠 해당 데이터베이스 설정 및 파일들을 모두 tar 압축백업을 할 예정이다.

그리고 신규 서버에 OS 설치 후 이걸 고대로 갖다 놓았을 때 정상적으로 접속이 되는지 확인할 것이다.

아마도 PostgreSQL 버전이 같다면 큰 문제 없이 수행되리라 예상하고 있다.

일단 PostgreSQL 설정파일 및 데이터베이스 파일이 위치해있는 디렉토리로 이동, tar 압축을 수행한다.

생성된 tar파일을 고대로 다운로드 한 후, 신규 서버에 업로드한다.

https://kimfish.tistory.com/361

이 내용을 참조하여 신규 서버에 PostgreSQL을 설치한 후, tar 파일을 업로드 한 이후, 다음의 과정을 수행한다.

뭐 그런데 결과가 당연하게도, 잘 구동 되었다.

문제는 기존 PostgreSQL 설정파일의 위치나 데이터베이스 파일, 테이블 스페이스 경로 등이 커스텀화 되지 않았는지 파악하는것이 가장 중요하다.

다음에는 직접 PostgreSQL 서버에 접속 후, 각종 테이블스페이스와 데이터베이스 설정 위치들을 쿼리를 통해 알아볼 예정이다.

얼마전에 docker linux에 PostgreSQL13 Server를 설치하였고 DBEaver를 통한 접속테스트를 수행했다.

이번에는 신규 계정 생성 및 TableSpace 생성, 기본적인 임시 테이블 서너개를 생성 후 백업 테스트를 위한 준비를 수행해볼 예정이다.

DB의 admin 계정으로 접속해서 직접 쿼리로 관리해도 되지만, 이번에는 새로운 방법(?)으로 해보려 했다.

아래의 순서는 다음과 같다.

데이터베이스 설정 - 테이블스페이스 설정 - 계정 생성 및 권한 설정

1. psql 접속 

docker linux에 접속 후, postgres 계정으로 변경한다.

이후, 설정에 따라 다르지만 아래의 명령어를 통해 psql에 접속한다.

2. 데이터베이스 설정

이제 막 PostgreSQL을 설치했으므로 기본 데이터베이스 외에는 존재하지 않으므로, 데이터베이스 생성부터 수행한다.

다음과 같이 명령어를 입력한다.

create database [DB명];

\l 명령어는 생성된 database를 확인하는 명령어이다.

3. DB 계정 생성 및 권한 부여

여기까지 기본적인 PostgreSQL 설정이 모두 완료되었다.

DBEaver를 통해 접속했을 때 정상적으로 보여지는 것 또한 확인했다.

고객사에서 MariaDB를 설치하고 있다. 그러던 와중, 잘 구동되던 Tomcat을 재구동하게 되었는데 오류메시지 "Access denied for user '계정명'@'localhost'(using password:YES)" 라는 오류가 발생한다. 이전까지는 재구동하는데 문제가 없었고, 오류가 생길만한 작업은 약 서너가지 정도가 짚히는 상황이었다. 현재 WAS 설정으로는, server.xml 및 context.xml 내에서 JNDI를 해당 MariaDB로 설정해둔 상태였다.

먼저, MariaDB에 익숙하지 않은 나인지라 용어의 혼란이 조금 있을 것 같아 아래와 같은 내용으로 이해를 하고 있다.  MariaDB는 계정별로 두 개의 권한을 갖는 듯한 모습이었다. MariaDB의 계정 테이블을 쿼리해보면 Host라고 작성된 부분이 있는데, 여기에 localhost 및 % 정도로 권한(?)이 부여가 된다. localhost는 내부에서만 접속이 가능하고, %은 내/외부에서 접속이 모두 가능한 권한 정도로 이해하고 있다.

본론으로 돌아와서 검색해보니 뭐 당연하게도 해당 계정의 localhost 권한이 없다는 문구다. 그래서 MariaDB가 설치된 서버에 접속하여 아래의 명령어를 사용했다. 해당 명령어는 shell 에서 MariaDB에 접속하기 위한 명령어이다.

그런데 위의 tomcat과 마찬가지로 "Access denied for user '계정명'@'localhost'(using password:YES)" 오류가 발생한다. 그래서 MariaDB의 root계정으로 접속하려는데, root 권한 또한 마찬가지 오류가 발생한다. 

이래저래 구글링을 해보니, 다음과 같은 명령어를 찾게 되었다.

해당 명령어는 서버의 root 권한으로 서버 내에 설치된 MariaDB의 root 비밀번호를 재설정하는 것이다. 이 이후에, mysql -u root -p 명령어로 접속하였고, localhost 계정을 다시 생성해주려 하였다.

했더니, 아래와 같은 오류메시지가 출력된다.

뭔가 해서 봤더니 직접 생성이 불가능한 것 같다. 혹시나 싶어, 계정 테이블을 직접 쿼리해서 상태를 좀 보고자 했다.

해당 명령어로 조회해보니 우리 DB에서 사용중인 계정 - Host(권한이라고 이해중)별 비밀번호가 각각 다른것이었다. A 계정의 % Host(권한)과 A 계정의 localhost Host(권한)과 비밀번호가 각기 다른 상황. 이러니 서버나 tomcat에서 접속할 때에는 Access Denied For User 에러가 발생했을 것이고, 개발자 PC의 DB툴로는 접속이 잘 되었겠지. 이제 원인이 파악된 상황이다.

* test라는 계정의 % Host 비밀번호는 암호화되어 *0B26A로 시작하는데, localhost는 *COB5F로 시작한다. 이러니 외부에서 접속하는 % Host는 기존 비밀번호로 접속이 되고, 같은 서버 내에 있는 tomcat은 기존 비밀번호로 접속이 안되겠지.

일단 원인은 알았다. test 계정의 % 비밀번호와 test 계정의 localhost 비밀번호가 다르기에 생긴 문제라는 것. 일단 localhost 비밀번호가 왜 저렇게 변경되었는지는 작업자들에게 물어보면 될 것이고, 접속이 되도록 수정을 해야겠다. 이럴땐 뭐다? test 계정의 localhost Host(권한)비밀번호를 기존에 사용중인 비밀번호로 Update 쳐주면 될 것이다.

했더니, 다음과 같은 에러가 발생한다.

않이; 뭐냐 대체 이건. 또다시 검색해보니 MariaDB 10.4 버전 이상은 user테이블을 직접관리하지 않고, 파일이나 뭐 그런식으로 관리하기 때문에 기존의 user테이블 update 방식은 사용할 수 없다고 한다. 그래서 또다시 뒤져보니 명령어로 직접세팅하는 방법이 있었다.

했더니, Query OK, 0 rows affected (0.014sec) 메시지가 출력되었다. 그리고 다시 user 테이블을 확인해보았고, 해당 계정의 % Host와 localhost Host의 비밀번호가 동일한 것을 확인할 수 있었다.

이후, tomcat을 재구동하였더니 정상동작 하였다.

MariaDB를 직접적으로 설정하고 사용할 일이 없어 여러모로 삽질을 많이하게 되었다. 문제해결하면서 알게된 점을 아래에 간략하게 작성해보았다.

계정은 Host(권한)별로 password가 지정된다는 점이다. 위에서도 보여지듯, test 계정임에도 불구하고 로컬(같은 서버내)에서 접속가능한 비밀번호와 외부에서 접속 가능한 비밀번호가 각기 설정되어있다.

또한, 명령어의 password('비밀번호')는 자동으로(?) 인코딩되어 설정된다는 점이었다. 혹시나 싶어 구글링한 결과 그대로 작성해보았는데, 알아서 인코딩되어 저장되는 것을 보니 어딘가에 설정이 박혀있는게 아닐까 싶다. 뭐 복잡시럽게 sha256으로 인코딩해서 직접 박아넣는게 아니라 다행이다 싶다.

위의 상황이 발생하게 된 계기는, 하나의 서버를 여러부서가 공동으로 개발장비로 사용하는 중이었고, MariaDB를 우리팀에서 설치, 사용을 하고 있었다. 그러다가 타 부서에서 MariaDB를 사용 할 일이 생기게 되었고, 우리가 설치한 MariaDB에 접속이 안되니 멋대로 서버의 root 권한으로 test계정의 localhost 비밀번호를 바꿔버려 생긴 문제였다. 거기에, 우리팀 막내가 당일 MariaDB 설정과 관련하여 파일 권한이라거나 기타 설정들을 바꾸면서 MariaDB Service를 재구동하는 등 여러 변경점이 생기다보니 우리팀 내에서만 원인 찾기가 힘든 상황.

나의 경우에는 계정-host별 비밀번호가 다르게 적용되는 줄 몰랐던터라, 애꿎은 DB보안프로그램과 서버접속 보안프로그램 탓을 했었다. tomcat 재구동 작업을 하기 바로 전날 야간에 설치가 되었던터라, 이 부분이 문제인줄 알았던 것. 여러 작업적인 이슈가 겹치다보니 생긴 당연한 인재였다. 개발서버였기에 망정이지, 실 운영이 진행중인 운영서버였다면 초대형사고였을지도 모른다. 이러한 이유로, 무슨 작업이든 작업이 있을 경우에는 연관부서에 모두 noti를 해줘야한다는 것이다.

개발하다보면, 특정 컬럼의 네이밍을 조회하는 경우가 있다. 가령 A 라는 컬럼을 어떤 테이블에서 더 쓰는지. 뭐 이런 경우. Oracle은 all_tab_column인지 all_object를 쓰면 되긴 하는데 mysql은 처음이다. 하지만 간단하다.

이렇게 해주면 된다. 개꿀.

DB 또는 시스템 작업을 하다보면 여러건에 대해 한번에 업데이트를 하는 경우가 많다. 뭐 그렇다치고 이번에는 MySQL 에서 서브쿼리를 이용하는 방법을 알아보자.

이번에 할 작업은 A_Table의 a_column의 데이터와 문자열을 합친 후, A_Table의 b_column에 업데이트를 해줄 일이 생겼다. 오라클과 다르게 한차례 더 가공을 해야 해서 손이 가는 편이지만 크게 어렵지는 않았다.

오라클 같은 경우에는 SET 구문에서 서브쿼리를 바로 날리면 되지만, MySQL의 경우에는 SELECT 구문에 서브쿼리를 한 번 더 감싸줘야 한다.

이로써 A_Table의 b_column에 'TEST_'문자열이 합쳐진 a_column값이 update 되게 된다.

[Oracle 11g Enterprise] / [Mybatis 3.2.7] 기준

varchar2 데이터타입은 최대 사이즈를 4,000byte 까지 줄 수 있다. 그런데 4,000byte 이상의 데이터를 저장할 일이 있다. base64로 인코딩된 이미지라거나, xml 파싱된 영수증내용이라거나 아주 긴 블로그의 글이라거나. 그럴 때 oracle 에서 사용하는 데이터타입은 clob 이다.

CLOB은 XML 형태로 데이터를 지정하게 되는데, DB 툴에서는 select * from table로 간단하게 데이터 확인이 가능하지만, mybatis를 사용하게 되면 일반적인 select 쿼리로는 활용이 불가능하다. 그럴 때 다음과 같이 mybatis의 select 구절에 resultmap을 설정하면 된다.

사용법은 심플하다.

select 쿼리의 resultMap 파라미터는 별도로 선언할 resultMap의 ID를 지정해준다.

별도로 선언할 resultMap에서는 id를 맞춘 후, clob으로 가져올 컬럼명(column)을 지정하고, jdbcType을 clob으로 지정, 이를 어떠한 column name으로 내보낼 것인지 지정(property)해주면 된다.

그런데 여기서 한가지 궁금한 점이 생기게 된다. 

각기 다른 테이블을 조인 후 가져올 때, 각 테이블의 같은 이름 clob은 어떻게 가져올까 하는 점이다.

테스트를 잠시 해보았는데 생각보다 매우 간단했다.

처음에는 같은 컬럼명이니까 위의 resultMap을 그냥 가져다 쓰면 ETC 컬럼을 ETC Property로 출력해주겠거니, 했지만 전혀 그렇지 않았다.(왜인지 Java의 Service 처럼 동작할거라 생각;)

그래서 두번째 방법을 사용해보았다.

그랬더니 각기 다른 테이블에서 동일한 네이밍의 clob 컬럼을 정상적으로 가져올 수 있었다.

간단한 테스트 결과, resultMap의 동작구조는 SELECT가 우선적으로 실행된 결과를 가져온 뒤, 이를 resultMap에서 처리하는 구조로 여겨진다. 결과적으로 resultMap은 Alias로 잡힌 컬럼명을 인식한다는 말이다.

[Oracle 11g Enterprise] 기준

개발을 하다보면 산출물을 작성해야하고, 이 산출물에는 테이블 생성날짜 등도 필요한 경우가 있다. 몰아서 테이블들을 생성해두고 나중에 작성하려다보면 뭐 임의의 날짜로 작성해도 무방하나 혹여나 하는 1g의 불안감 때문에 확인하는 경우가 있다.

뭐 대충 이정도. 검색을 하다보면 all_objects 테이블이 아니라 user_objects라느니 뭐라느니 하는데 아마 버전마다 다른게 아닌가 싶을 정도.

여튼, 위의 컬럼은 다음과 같은 구성을 가지고 있다.

뭐 대충 이정도. owner 에는 SYS 혹은 EXFSYS, SYSTEM 등 수많은 시스템용 owner가 있기에, 가장 기본적인 필터를 owner로 지정해두고 select 하는 것이 정신건강에 이로울 듯.

[Oracle 11g Enterprise 기준]

테이블의 데이터를 다른 테이블로 그대로 옮겨야 할 때가 있다.

Excel Export / Inport를 통한 방법이나 기타 여러 방법들이 있긴 한데 아무래도 귀찮은 방법이기도 하고. 그래서 Select Insert Query를 주로 사용한다.

가장 기본적으로 위와 같은 구성으로 시작할 수 있다. A_TABLE에 B_TABLE의 데이터 중, no가 1인 항목만을 넣는 쿼리이다.

만약, 특정 컬럼에 대해서만 select insert를 한다면? 다음과 같다.

위와 별개로, 다른 user에 할당된 테이블에 넣기 위해서는? 

회사에서는 하나의 DB에 user 단위로 운용/개발 DB가 분리되어있다. 당연하게도 dba 권한으로 아래의 쿼리를 이용해주면 된다.

user_1은 user_2에 접근할 수 없기에 dba 권한으로 둘 다 접속이 가능한 상태에서 select / insert를 수행해주면 된다.

지난글, 2013/06/26 - [어장 프로그래밍/어장 DBA] - [MSSQL] MAX 함수 NULL 일 때 치환 에서는 MSSQL을 기준으로 글을 작성하였다.

현재 개발중인 플젝의 DB는 informix로 되어있고, 위와 같은 방식으로 max null 값을 구하려 했더니 informix 에서는 isnull 함수가 사용불가능하더라.

검색 해 보니 NVL 이란 함수가 있었고, 아래와 같은 방식으로 사용하였다.

testColumn의 MAX 값을 구하고, 이 값이 null 일 경우에는 0으로 치환한 후, 그 값에 +1을 하여 tempName 이라는 임시 컬럼명으로 Select 한다는 내용이다.(내가 써놓고 뭔가 어정쩡한 설명이란 생각이 든다.)

아무튼, 테스트를 해 보니 testColumn 값이 null 이 아니더라도 정상적으로 쿼리가 작동하기 때문에 만족하고 사용중. 뭐 이렇게 하면 된다.