2018. 10. 22. 17:08

1. 조사배경

  - 묵혀둔 MSSql이 있었다. (한 2년 접속 안함)

  - 접속하니 enableSSL xxx 하면서 ssl 로그가 뜬다.

  - 다음과 같은 로그를 남기고 접속이 안된다.


   드라이버가 SSL(Secure Sockets Layer) 암호화를 사용하여 SQL Sever로 보안 연결을 설정할 수 없습니다. 오류: "java.security.cert.CertificateException: Certificates do not conform to algorithm constraints". ClientConnectionId:60f65f8c-e751-4cff-90d9-69928ae25ef8



2. 원인

  java 가 Update되면서 일부 key를 사용못하게 함

  즉 client 는 최신

     server는 Old ==> 


  즉 서버에서 키 문제가 존재하는 것으로 handshake 할려고 하는데.. 그게 문제가 되는가 부다.



3. 해결

client의   JRE_HOME/lib/security/java.security 파일을 열어서


  다음 속성

 jdk.certpath.disabledAlgorithms

 jdk.tls.disabledAlgorithms


을 주석 처리함.. 즉 알고리즘 다 사용하게 함...

==>  정확히 처리할려면 서버도 알고리즘을 맞추어 주어야 되는데 mssql ssl 알고리즘 설정을 어디서 하는지 모르겠다.



# 참고

1. 에러 원문

 com.microsoft.sqlserver.jdbc.SQLServerException: 드라이버가 SSL(Secure Sockets Layer) 암호화를 사용하여 SQL Sever로 보안 연결을 설정할 수 없습니다. 오류: "java.security.cert.CertificateException: Certificates do not conform to algorithm constraints". ClientConnectionId:60f65f8c-e751-4cff-90d9-69928ae25ef8

at com.microsoft.sqlserver.jdbc.SQLServerConnection.terminate(SQLServerConnection.java:1668)

at com.microsoft.sqlserver.jdbc.TDSChannel.enableSSL(IOBuffer.java:1668)

at com.microsoft.sqlserver.jdbc.SQLServerConnection.connectHelper(SQLServerConnection.java:1324)

at com.microsoft.sqlserver.jdbc.SQLServerConnection.login(SQLServerConnection.java:992)

at com.microsoft.sqlserver.jdbc.SQLServerConnection.connect(SQLServerConnection.java:828)

at com.microsoft.sqlserver.jdbc.SQLServerDriver.connect(SQLServerDriver.java:1012)

at java.sql.DriverManager.getConnection(DriverManager.java:664)

at java.sql.DriverManager.getConnection(DriverManager.java:208)

at com.somansa.db.connection.DBConnection.getConnection(DBConnection.java:238)

at com.somansa.db.connection.PIScanDBConnection.InspectDBStructure(PIScanDBConnection.java:332)

at com.somansa.manager.PITargetDBManager.inspectDBStructure(PITargetDBManager.java:588)

at com.somansa.manager.PIGetDBInfoManager.getDBinfoProcess(PIGetDBInfoManager.java:41)

at com.somansa.manager.PIGetDBInfoManager.run(PIGetDBInfoManager.java:133)

at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)

at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)

at java.lang.Thread.run(Thread.java:748)

Caused by: javax.net.ssl.SSLHandshakeException: java.security.cert.CertificateException: Certificates do not conform to algorithm constraints

at sun.security.ssl.Alerts.getSSLException(Alerts.java:192)

at sun.security.ssl.SSLSocketImpl.fatal(SSLSocketImpl.java:1946)

at sun.security.ssl.Handshaker.fatalSE(Handshaker.java:316)

at sun.security.ssl.Handshaker.fatalSE(Handshaker.java:310)

at sun.security.ssl.ClientHandshaker.serverCertificate(ClientHandshaker.java:1639)

at sun.security.ssl.ClientHandshaker.processMessage(ClientHandshaker.java:223)

at sun.security.ssl.Handshaker.processLoop(Handshaker.java:1037)

at sun.security.ssl.Handshaker.process_record(Handshaker.java:965)

at sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:1064)

at sun.security.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1367)

at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1395)

at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1379)

at com.microsoft.sqlserver.jdbc.TDSChannel.enableSSL(IOBuffer.java:1618)

... 14 more

Caused by: java.security.cert.CertificateException: Certificates do not conform to algorithm constraints

at sun.security.ssl.AbstractTrustManagerWrapper.checkAlgorithmConstraints(SSLContextImpl.java:1127)

at sun.security.ssl.AbstractTrustManagerWrapper.checkAdditionalTrust(SSLContextImpl.java:1051)

at sun.security.ssl.AbstractTrustManagerWrapper.checkServerTrusted(SSLContextImpl.java:993)

at sun.security.ssl.ClientHandshaker.serverCertificate(ClientHandshaker.java:1621)

... 22 more

Caused by: java.security.cert.CertPathValidatorException: Algorithm constraints check failed on keysize limits. RSA 512bit key used with certificate: CN=RIKKY-PC-X64.  Usage was tls server

at sun.security.util.DisabledAlgorithmConstraints$KeySizeConstraint.permits(DisabledAlgorithmConstraints.java:817)

at sun.security.util.DisabledAlgorithmConstraints$Constraints.permits(DisabledAlgorithmConstraints.java:419)

at sun.security.util.DisabledAlgorithmConstraints.permits(DisabledAlgorithmConstraints.java:167)

at sun.security.provider.certpath.AlgorithmChecker.check(AlgorithmChecker.java:332)

at sun.security.ssl.AbstractTrustManagerWrapper.checkAlgorithmConstraints(SSLContextImpl.java:1123)

... 25 more


2. 참고 사이트

https://stackoverflow.com/questions/21218217/ssl-handshake-exception-algorithm-constraints-check-failed-md5withrsa

Posted by citrine
2018. 3. 6. 14:44

1. 조사 배경

  - 몇달전에 SQL Anywhere 16 Developer를 설치하고 운영하다가

  - 몇달 뒤에 네트워크로 사용하려고 하다가

  - 서비스 띄우는 법을 까먹음



2. 서비스 시작 방법(Windows 7)

  - 시작 > SQL Anywhere 16 > SQL Anywhere > Network Server (64 bit) 클릭


3. 확인 방법

  - netstat -an|findstr {서비스 포트}

   # 서비스 포트는 서비스 시작시 콘솔 출력에 나타남


3. 참고

  - 오류 발생시 dbsrv16.exe를 강제로 죽이고 다시 하자.

  - 개발자 버전이라서 Services 목록에 없으니 괜히 찾는다고 고생하지 말자.!!!!!

  - 설치 방법도 까먹었다. ㅠ.ㅠ

Posted by citrine
2017. 12. 26. 09:59

요약 : citus 라는 확장 라이브러리를 설치하여 Sharding 처리


https://github.com/citusdata/citus




Sharding with PostgreSQL





In this article we are going to talk about sharding in PostgreSQL. What is sharding, Sharding is like partitioning. The difference is that with traditional partioning, partitions are stored in the same database while sharding shards (partitions) are stored in different servers.
Below is an example of sharding configuration we will use for our demonstration

sharding
PostgreSQL does not provide built-in tool for sharding. We will use citus  which extends PostgreSQL capability to do sharding and replication.
We will use 3 servers
pgshard0: 192.168.1.50
pgshard1: 192.168.1.51
pgshard2: 192.168.1.52
First let’s install PostgreSQL + citus extension on all servers (pgshard0, pgshard1, pgshard2). We suppose of course that network is configured so that all server can communicate
[root@pgshard0 ~]# yum install -y https://download.postgresql.org/pub/repos/yum/9.5/redhat/rhel-7-x86_64/pgdg-oraclelinux95-9.5-2.noarch.rpm
[root@pgshard0 ~]# yum install -y citus_95.x86_64
Now let’s  to initialize a new database system on all servers (pgshard0, pgshard1, pgshard2)
[root@pgshard0 ~]# /usr/pgsql-9.5/bin/postgresql95-setup initdb Initializing database ... OK
To load citus extension we have to edit the /var/lib/pgsql/9.5/data/postgresql.conf   file and add the following line
shared_preload_libraries = ‘citus’
[root@pgshard0 data]# grep shared_preload_libraries /var/lib/pgsql/9.5/data/postgresql.conf #shared_preload_libraries = '' # (change requires restart) shared_preload_libraries = 'citus' [root@pgshard0 data]#
To allow postgreSQL connection between servers we have to configure two configuration files /var/lib/pgsql/9.5/data/postgresql.conf  and /var/lib/pgsql/9.5/data/pg_hba.conf
[root@pgshard0 data]# grep listen postgresql.conf listen_addresses = '*' # what IP address(es) to listen on; [root@pgshard0 data]#
[root@pgshard0 data]# grep trust pg_hba.conf # METHOD can be "trust", "reject", "md5", "password", "gss", "sspi", host all all 127.0.0.1/32 trust host all all 192.168.1.0/24 trust host all all ::1/128 trust [root@pgshard0 data]#

Let’s now start database on all servers (pgshard0, pgshard1, pgshard2)

[root@pgshard0 data]# service postgresql-9.5 start Redirecting to /bin/systemctl start postgresql-9.5.service [root@pgshard0 data]#

 We need to inform the master (pgshard0) about its workers (pgshard1 and pgshard2). For this we have to create a configuration file pg_worker_list.conf  like this

[root@pgshard0 data]# pwd /var/lib/pgsql/9.5/data [root@pgshard0 data]# cat pg_worker_list.conf pgshard1 5432 pgshard2 5432 [root@pgshard0 data]#

Let’s now reload the master pgshard0  to take into account the modification

[root@pgshard0 ~]# service postgresql-9.5 reload Redirecting to /bin/systemctl reload postgresql-9.5.service [root@pgshard0 ~]#

Very important:  we must create citus extension on both servers

postgres=# create extension citus; CREATE EXTENSION postgres=# \dx List of installed extensions Name | Version | Schema | Description ---------+---------+------------+------------------------------ citus | 5.2-1 | pg_catalog | Citus distributed database plpgsql | 1.0 | pg_catalog | PL/pgSQL procedural language (2 rows)

The last step before the sharding is now to verify that the master is ready. This SELECT command we will  run in the psql shell should output the worker nodes mentioned in the pg_worker_list.conf file.

postgres=# SELECT * FROM master_get_active_worker_nodes(); node_name | node_port -----------+----------- pgshard2 | 5432 pgshard1 | 5432 (2 rows) postgres=#

Every thing is going fine until now, so we can create on the master the table to be sharded. Let’s say table sales

postgres=# CREATE TABLE sales postgres-# (deptno int not null, postgres(# deptname varchar(20), postgres(# total_amount int, postgres(# CONSTRAINT pk_sales PRIMARY KEY (deptno)) ; CREATE TABLE

We need have inform Citus that data of table sales will be distributed among pghard1 and pgshard2. In our case we choose a hash distribution.

postgres=# SELECT master_create_distributed_table('sales', 'deptno', 'hash'); master_create_distributed_table --------------------------------- (1 row)

In our example we are going to create one shard on each worker. We will  Specify
the table name :  sales
total shard count : 2
replication factor :  1  –No replication
postgres=# SELECT master_create_worker_shards('sales', 2, 1); master_create_worker_shards ----------------------------- (1 row) postgres=#

And guys it’s all. Sharding is done. Connecting to pgshard1 and pgshard2 we can verify that shards were created with the same structure than the base table.

[postgres@pgshard1 bin]$ psql -c "\dt" List of relations Schema | Name | Type | Owner --------+--------------+-------+---------- public | sales_102026 | table | postgres (1 row)
[postgres@pgshard2 ~]$ psql -c "\dt" List of relations Schema | Name | Type | Owner --------+--------------+-------+---------- public | sales_102027 | table | postgres (1 row)
Now let’s insert some rows in the table from the master
postgres=# insert into sales (deptno,deptname,total_amount) values (1,'french_dept',10000); INSERT 0 1 postgres=# insert into sales (deptno,deptname,total_amount) values (2,'german_dept',15000); INSERT 0 1 postgres=# insert into sales (deptno,deptname,total_amount) values (3,'china_dept',21000); INSERT 0 1 postgres=# insert into sales (deptno,deptname,total_amount) values (4,'gambia_dept',8750); INSERT 0 1 postgres=# insert into sales (deptno,deptname,total_amount) values (5,'japan_dept',12010); INSERT 0 1 postgres=# insert into sales (deptno,deptname,total_amount) values (6,'china_dept',35000); INSERT 0 1 postgres=# insert into sales (deptno,deptname,total_amount) values (7,'nigeria_dept',10000); INSERT 0 1 postgres=# insert into sales (deptno,deptname,total_amount) values (8,'senegal_dept',33000); INSERT 0 1 postgres=#

We can see that data are distributed between pgshard1 and pgshard2

[postgres@pgshard1 bin]$ ./psql psql (9.5.4) Type "help" for help. postgres=# select * from sales_102026; deptno | deptname | total_amount --------+--------------+-------------- 1 | french_dept | 10000 3 | india_dept | 21000 4 | gambia_dept | 8750 5 | japan_dept | 12010 7 | nigeria_dept | 10000 8 | senegal_dept | 33000 (6 rows)

[postgres@pgshard2 bin]$ ./psql psql (9.5.4) Type "help" for help. postgres=# select * from sales_102027; deptno | deptname | total_amount --------+-------------+-------------- 2 | german_dept | 15000 6 | china_dept | 35000 (2 rows)

If we do an explain from the master pgshard0, we note that query is routed to different shard depending of data
postgres=# explain verbose select * from sales where deptno=5; QUERY PLAN -------------------------------------------------------------------------------------------------------------- Distributed Query Executor: Router Task Count: 1 Tasks Shown: All -> Task Node: host=pgshard1 port=5432 dbname=postgres -> Index Scan using pk_sales_102026 on public.sales_102026 sales (cost=0.15..8.17 rows=1 width=66) Output: deptno, deptname, total_amount Index Cond: (sales.deptno = 5) (9 rows)

postgres=# explain verbose select * from sales where deptno=6; QUERY PLAN -------------------------------------------------------------------------------------------------------------- Distributed Query Executor: Router Task Count: 1 Tasks Shown: All -> Task Node: host=pgshard2 port=5432 dbname=postgres -> Index Scan using pk_sales_102027 on public.sales_102027 sales (cost=0.15..8.17 rows=1 width=66) Output: deptno, deptname, total_amount Index Cond: (sales.deptno = 6) (9 rows)

Conclusion:
In this article we show that PostgreSQL allows to do many interesting things. Use of extensions can considerably extend PostgreSQL capability


# 참고

https://blog.dbi-services.com/sharding-with-postgresql/



Posted by citrine
2017. 12. 21. 14:06

대용량 시스템을 위한 데이타베이스 아키텍쳐
Sharding & Query Off Loading

RDBMS는 크게 request를 바로 처리하는 트렌젝션 처리용의 OLTP(On-Line Transaction Processing)성과, 데이타를 모아서 분석하고 리포팅하는 OLAP(On-Line Analytical Processing) 두가지로 분리된다. 여기서 설명하는 RDBMS는 OLTP성의 데이타 베이스 이다.

RDBMS는 2차원 테이블 구조의 데이타를 KEY 값을 중심으로 여러개의 컬럼으로 저장되며, 저장된 각각의 로우(행)은 다른 테이블의 로우와 관계를 가질 수 있다.

RDBMS를 이용한 설계를 하는데, 고려할만한 아키텍쳐는 성능 향상을 위한 Query Off Loading과, Sharding이라는 기법이 있다.


Query Off Loading

 Query Off Loading은 DB의 성능 향상을 위한 기법이다. (정확하게 이야기 하면, 처리량을 증가 시키기 위한 설계 기법이다.) DB 트렌젝션의 70~90%는 대부분 READ 성이 많다. 나머지 10~30%가 Create/Delete/Update와 같은 트렌젝션인데, 이 Update 성 트렌젝션과 Read 트렌젝션을 분리하는 기법이다.



먼저 Master DB에는 쓰기(Update)만을 허용하고, Master DB의 내용을 중간의 Staging DB라는 곳으로 복사한다. 이 Staging DB는 복제된 내용은 N개의 Slave DB로 복제한다.

애플리케이션은 Master DB에만 쓰기를 하고, 읽기는 Slave DB에서만 수행한다. 이를 위해서 Application을 DB에 대한 쓰기 로직과 읽기 로직을 분리해서 구현해야 하며, 이 분리된 로직은 쓰기 DB로 접근하기 위한 DB Connection과 읽기 DB로 접근하기 위한 DB Connection을 이용해서 접근한다. 일반적으로 application server에서는 이러한 Connection을 Connection Pool 을 이용해서 관리 하는데, 읽기 DB의 경우에는 N개의 Slave DB로 부터 읽기 때문에, Application이 이 N개의 Slave DB에 대한 요청을 Load Balacing을 해야 한다. 또한 특정 Slave DB 장애시 다른 Slave DB 인스턴스에 접근을 할 수 있도록 HA (High Availability) 기능을 제공해야 하는데 Connection Pool 자체에 Load Balancing과 HA 기능을 가지고 있는 Connection Pool을 이용하거나 또는 JDBC Driver와 같이 DBMS용 Driver 자체에 Load Balancing과 HA 기능을 사용한다.

Master DB와 Slave DB는 각각 쓰기와 읽기를 위해서 접근된다고 하지만 그렇다면 중간에 Staging DB의 역할은 무엇일까? Staging DB는 Slave DB로 복제하기 위한 중간 경유지 역할을 한다. 다수의 Slave DB로 복제를 해야 하기 때문에, 이에 대한 부하가 크다. 만약 Master DB에서 Slave DB로 바로 복제를 하게 되면, Master DB가 쓰기 트렌젝션 이외에 복제에 대한 부분을 처리해야 하기 때문에 성능 저하를 유발할 수 있다. 이를 방지 하기 위해서 중간에 Staging DB를 넣는 것이다.

그렇다면 Master à Staging à Slave DB로의 복제는 어떤 기술을 이용할까?

CDC (Change Data Capture)라는 기술을 이용한다. DBMS들은 공통적으로 Create/Update/Delete와 같은 쓰기 관련 작업을 수행할때, 데이타를 실제로 저장하기 전에 먼저 해당 작업에 대한 request를 BackLog라는 곳에 저장한다. (BackLog는 일반적으로 Local 파일이다.) 이는 실제로 데이타를 쓰기전에 장애가 났을때, restart하면서 이 BackLog를 읽어서 복구를 위한 용도로 사용이 된다. CDC는 이 Back Log를 이용해서 데이타를 복제하는데, Source DB로 부터 이 Back Log를 읽어서, 복제를 하고자하는 Target DB에 replay 하는 형식이다.

즉 Source DB에서, insert A,B,C를 하면 이는 모두 Back Log에 기록되고, 이를 읽어서 Target DB에서 다시 replay – insert A,B,C를 순차적으로 수행하는 것이다.

대표적인 CDC 제품으로는 Oracle의 Golden Gate, Quest의 Share Flex가 있고, 오픈소스 제품으로는 Galera[1]라는 제품이 있다.


Sharding

Sharding은 데이타베이스의 용량 한계를 극복하기 위한 기술이다. 클러스터링 기술을 사용하더라도 데이타 베이스는 물리적인 용량 한계를 갖는 경우가 많다. 수년 전에만 해도, 하나의 서비스에 수천만명이 사용하는 서비스는 없었다. 인터넷의 발전등에 따라서 사용자가 급격하게 늘어나고 저장해야 하는 데이타의 양도 급격하게 늘어났다. 데이타 베이스 시스템은 이러한 용량 증가를 따라가지 못했다. 그래서 Sharding이라는 아키텍쳐가 유행하기 시작했는데, Sharding은 쉽게 말해서 데이타를 여러개의 데이타 베이스에 나눠 담는 방법이다.

하나의 데이타 베이스가 10억개의 레코드만 저장할 수 있다면, 100억개의 데이타를 저장하려면 10개의 데이타 베이스를 사용하여 분산 저장하는 방법이다. 이 각 10개의 데이타 베이스를 Shard라고 한다.

Sharding은 데이타를 분산 하는 방식에 따라서 Vertical(수직적) Sharding과 Horizontal(수평적) Sharding으로 나뉘어 진다.

Vertical Sharding은 연속된 데이타에 대해서 범위별로 데이타를 나누는 방법이다. 아래 예는 연령대 별로, 데이타를 나누는 예이다.



Figure 1 Vertical Sharding


다음으로는 Horizontal Sharding이 있는데, 이는 연속된 키가 아니라 “Category”와 같은 종류에 따라서 데이타를 수평적으로 분리하는 방법이다.



Figure 2 Horizontal Sharding


데이타를 분산 저장할때 위와 같이 meaningful한 데이타를 사용할 수 있는데, 이 경우에는 데이타의 몰림 현상이라는 것이 발생할 수 있다. 위의 Vertical Sharding을 예를 들어보면, 해당 서비스를 사용하는 연령층이 20대와 30대에 편중되어 있다면, 20,30대 Shard에는 데이타가 몰리게 되고, 부하도 더 많이 받게 될 것이다. 그래서 이렇게 meaningful한 데이타를 KEY로 사용할 경우에는 데이타 몰림현상을 고려하여 각 Shard 서버의 성능을 비 대칭적으로 설계할 수 있다. 즉 20,30대의 Shard에는 더 좋은 CPU와 메모리를 갖는 서버를 배치하는 방법이 대안이 된다.

만약에 데이타 편중 현상에 대한 예측이 어려운 경우에는, meaningful 하지 않은 KEY를 사용해서 Sharding을 할 수 있다. 10개의 Shard를 갖는 데이타 베이스에서, 사용자 레코드를 등록할때, KEY를 Sequence를 이용해서 순차적으로 부여한다. 첫번째 사용자는 1, 두번째는 2, 다음은 3,4,5,6.. 등으로.. 그리고 이 ID를 10으로 나눈 나머지 값을 가지고 Shard를 결정하면, 데이타를 모든 Shard에 걸쳐서 골고루 분산 시켜 배치 할 수 있다. (Hash 방식)

Sharding을 구현하는 방법은 DBMS 단에서 Sharding을 지원 하는 방법과, OR Mapper와 같은 DB 접근용 프레임웍에서 Sharding을 제공하는 방법 그리고, Application Code 자체에서 지원하는 방법 세가지가 있다.

DBMS 단에서 제공하는 방법으로는 Microsoft SQL Server Azure의 federation model[2]이나 RDBMS는 아니지만 NoSQL중 MogoDB의 경우 1.6부터 Sharding을 DB단에서 지원한다.

프레임웍단에서는 자바의 Hibernate의 경우 Hibernate Shard[3]라는 기능을 통해서 Sharding을 지원한다.  프로그래밍 언어인 Grail의 경우에도 자체 프레임웍에서 “Grails Sharding Plug in”을 통한 Sharding 을 지원한다.

직접 Application에서 구현할 경우 Key에 따라서 DB Instance를 선택적으로 고를 수 있는 구조를 가져야 하며, 특히 다른 Shard간의 데이타 Join등은 불가능하기 때문에, 구현상에 이에 대한 고려가 필요하다.

Sharding 이라는 것이 데이타를 분산 저장함으로써 시스템의 전체 용량을 늘릴 수 는 있지만 Application의 복잡도가 올라가고, 데이타 편중 방지등 여러가지 요소를 고려한후에 설계, 반영해야 한다..



출처: http://bcho.tistory.com/670 [조대협의 블로그]

Posted by citrine
2017. 7. 12. 09:38

# 참고
http://blog.naver.com/PostView.nhn?blogId=ace2805&logNo=70074737356


wallet (전자 지갑)은  특정 칼럼을 안보이게 한다. (가령 중요한 급료 부분등)

========================================================================

SINGLE INSTANCE 환경

------------------------------------------------------------------------

vi sqlnet.ora

/u01/app/oracle/product/10.2.0/db_1/network/admin/sqlnet.ora.rac1

 

NAMES.DIRECTORY_PATH = (TNSNAMES)

ENCRYPTION..  를 붙여넣기 내용을 추가해 준다.

 

출처:

http://blog.naver.com/orapybubu?Redirect=Log&logNo=40049292922

http://www.oracle-base.com/articles/10g/SecureExternalPasswordStore_10gR2.php

 

sqlplus / as sysdba

 

alter system set encryption key

identified by oracle1234                   --> wallet (전자 지갑) 의 패스워드를 oracle1234 로 하겠다.

 

connect scott/tiger

select ename, sal from emp;            -->  아직 까지는 잘 보인다.

 

alter table emp modify sal encrypt;    -->  sal을 암호화 했다.   푸는것은 decrypt

select ename, sal from emp;            -->  아직은 전자 지갑이 열려 있음으로 보인다.

 

connect / as sysdba                      -->  sys 유저로 접속

alter system set encryption wallet close;                -->  전자 지갑을 닫는다.

 

connect scott/tiger

select ename, sal from emp;            -->  이제 보이지 않는다.

 

connect / as sysdba

alter system set encryption wallet open   

identified by oracle1234;                          -->  다시 연다.

 

=======================================================================================================

                                                                    RAC 환경 

-----------------------------------------------------------------------------------------------------------

                   1번 node                                          2번 node

-----------------------------------------------------------------------------------------------------------

                    wallet                 

2 번 노드에 접속한 session에서 wallet 이 걸린 칼럼을 조회하기 위해서는 1번 node의 wallet 이 필요하다. 

                     -->  1번 node 의 wallet 을 2번 node 쪽으로 copy 해야한다.

-----------------------------------------------------------------------------------------------------------   

select ename, sal from emp;

  --> 안보인다. RAC환경은 전자 지갑 생성시 필요로 하는 NODE 쪽으로 전자 지갑을 카피 해줘야 한다.

scp ewallet.p12 rac2:/u01/app/oracle/product/10.2.0/db_1   -->  로 1#node 에서 2#node로 카피 해준다.

 또한, 2#node 의 sqlnet.ora 에도 내용을 추가 해줘야 한다.

 

 connect scott/tiger

 

alter system set encryption

wallet open identified by oracle1234   

 

select ename, sal from emp;

 

               ##  전자 지갑은 system level 로 사용 해야 한다. session level 로는 사용 불가 하다. ##



Posted by citrine
2017. 6. 27. 14:36

다음과 같은 에러가 나오면 id or password 에러임 


즉 에러코드 : 0

다음 메세지 : null 이면 ==> id or password 에러임  


[2017-06-27 14:32:32,412]  WARN ((pool-1-thread-1) DBConnection.java[getConnection]:257) - Fail to Connect : JZ00L: 로그인에 실패하였습니다. 이 예외에 대한 SQLWarnings에서 원인을 확인하십시오.

[2017-06-27 14:32:32,412]  WARN ((pool-1-thread-1) DBConnection.java[getConnection]:263) - e.getErrorCode() : 0

[2017-06-27 14:32:32,412]  WARN ((pool-1-thread-1) DBConnection.java[getConnection]:264) - e.getSQLState() : JZ00L

[2017-06-27 14:32:32,412]  WARN ((pool-1-thread-1) DBConnection.java[getConnection]:265) - e.getMessage() : JZ00L: 로그인에 실패하였습니다. 이 예외에 대한 SQLWarnings에서 원인을 확인하십시오.



# 참고

http://cy.cyworld.com/home/24525504/post/4BBD9595D555792299D28401



Posted by citrine
2017. 4. 6. 16:38


1. install Python 2.7 using http://toomuchdata.com/2014/02/16/how-to-install-python-on-centos/
NOTE: If you install Python 2.7 using yum - your yum setup will be damaged !!! I love Linux!

2. install pip using the same doc as per Python 2.7

3. # pip2.7 install sqlalchemy 

3. Download and install multicorn-1.0.2 or better. Hint: # export PYTHON_OVERRIDE=python2.7

4. Now the tricky part, postgres installed with yum used system Python version, which is 2.6. Now we need to download right version of the postgresql source code and compile it with:
# ./configure --with-python  PYTHON=/usr/local/bin/python2.7 && make

5. copy one single file to the system postgres lib dir:
# cp src/pl/plpython/plpython2.so /usr/pgsql-9.3/lib/

6. Hack the startup script, add line PATH=/usr/local/bin:$PATH 
# sudo vi /etc/init.d/postgresql-9.3  

7. restart postgres
# /etc/init.d/postgresql-9.3 restart

That's it, now multicorn is usable.

This link may be helpfull:  http://oktarahadian.com/post/47435454848/how-to-change-python-version-used-by

# 참고
http://h4cktheworld.blogspot.kr/2014/04/multicorn-install-on-centos.html


Posted by citrine
2017. 2. 22. 14:14

1. 환경 : curl을 이용


2. 삭제 : pi_stat/pi_discoverincidentdbdata/ 모두 삭제

curl -XDELETE 'http://127.0.0.1:9200/pi_stat/pi_discoverincidentdbdata/_query' -d '{

    "query" : { 

        "match_all" : {}

    }

}'


3. 조회 : ddb_columnname가 STAFFEMAIL인 항목 찾기

curl -XDELETE 'http://127.0.0.1:9200/pi_stat/pi_discoverincidentdbdata/_search -d '{

 "query" : {

    "match" : {

    "ddb_columnname":"STAFFEMAIL"

      }

  }

}'

Posted by citrine
2017. 2. 22. 14:11

1. 버전 정보 가져오기 : curl -XGET 'localhost:9200'


2. Elastic Home 경로로 이동 (/usr/share/elasticsearch )


3. 설치 : ./bin/plugin install https://github.com/NLPchina/elasticsearch-sql/releases/download/2.2.1.0/elasticsearch-sql-2.2.1.0.zip


4. 서비스 재시작 :  service elasticsearch restart


5. 접속 해 보기 : 접속 URL ==> http://127.0.0.1:9200/_plugin/sql/



##특이사항 

 - 꼭 서비스 재시작을 해야 정확히 동작한다.


'[IT] DB' 카테고리의 다른 글

[Postgresql] Centos 6.7에 multicorn 설치  (0) 2017.04.06
[Elastic Search] Document 삭제/조회  (0) 2017.02.22
[DB2] 버전 찾기  (0) 2017.01.31
[ElasticSearch] Bitwise 연산하는 법  (0) 2016.11.04
[MYSQL] JDBC - ssh를 통한 mysql 접속  (0) 2016.10.21
Posted by citrine
2017. 1. 31. 16:03

다음 명령 실행


java -cp db2jcc4.jar com.ibm.db2.jcc.DB2Jcc -version

Posted by citrine