2015년 1월 28일 수요일

허삼관 매혈기

위화... 중국이 자랑하는 현존 최고의 자가...

그동안 미국, 유럽 그리고 가끔 일본작가의 책을 보았는데 중국작가의 글에는 서구의 글과 일본의 글과는 또다른 매력이 있다.

과장되지도 자극적이지도 않으면서 읽고 나면 잔잔한 감동이 온다.
영화 포스터를 보고 읽은 책. 내용은 아버지로서 책임,역할을 다하기 위해 어려울때마다 피를 팔아 생계를 책임지는...

그땐 정말 그랬을까 ? 책의 배경이 되는 중국의 당시 시대적 상황, 문화를 알았더라면 한층더 감격했을 것 같다...

노인과 바다 - 어니스트 헤밍웨이

2015년은 고전을 봐야겠다 첫책으로 노인과 바다.

언제부터인가 책도 감성과 말초신경을 자극하는 책들만 보다가 고전을 보니... 처음엔 별 감흥이 없어졌다.

역시 고전은 감수성이 예민한 청소년기에 보는 것이 옳게 느껴진다. 지금의 시대적인 상황, 개인적인 상황과 소설속 당시의 시대적 상황이 너무가 거리가 멀게 느껴진다.

방법은 여러번 보던가? 아님 이런 고전을 계속봐서 무디졌던 감수성을 되찾던가 ?

우선 읽어보자...

2015년 1월 18일 일요일

요나스 요나손 - 셈을 할줄아는 까막눈이 여자

요나스 요나손 - 셈을 할줄아는 까막눈이 여자

새해들어 두번째 소설책, 첫책을 너무 재미있게 본후에 봄.

작가의 상상력, Story전개하는 능력 모두 뛰어나다.
몇가지 머리아픈 일이 있고, 한살 더 나이를 먹으니 슬픈것 아픈것보다 Happy Ending으로 끝나는 행복한 결말이 좋다.

천재란 역시 태어나는 것일까 ? 우선은 머리가 좋아야겠다.
그리고 성격 또한 유전일까 ? 아무리 어렵고 힘든 일이 있다해도 낙천적으로 꾸준히 끝까지 해내어 결국은 모두가 좋은 결말이 이르도록 하는 것.

여러가지로 복잡할때 편하게 즐겁게 미소지으며 읽을볼 수 있는 좋은 책...

2015년 1월 11일 일요일

MySQL 튜닝 참고 문서

* MySQL 튜닝 참고 문서

1. http://egloos.zum.com/mcchae/v/11063919

2. http://egloos.zum.com/tiger5net/v/5672418

2015 두번째 책 - 창문넘어 도망친 100세 노인

"강추- 창문넘어 도망친 100세 노인"
최근 읽은 책중에서 가장 유쾌하고 재미있고 작가의 상상력이 풍부하면서도 긴 여운을 주는 책.

알란 칼손... 아주 어린나이 부모를 여의고, 잠시 폭탁 제조 기술을 배워, 집을 통째로 날려먹고, 정신병원에 감금되어 거세를 당하고... 원자폭탄 개발에 결정적인 아이디어를 제시...
중국, 소련, 북한, 미국, 프랑스, 인도네시아 등 정상과 가까이 지내며 세계사의 중요한 순간마다 결정적인 역할하여 세계사를 바꾼 노인.

세계를 둘러보기엔 100세가 너무 짧은 그. 100세 생일날 아침 또한번의 유쾌한 도전과 사고를 저지르나 모두 즐거운 Happy Ending으로 끝이 나는 신나는 글.

아직은 사망소식이 없으니 더 큰 사고를 칠지도...

2015년 1월 7일 수요일

11g 통계정보 생성 중요 기능

11g에서는 파티션 적용 테이블에서 Incremental NDV 생성기능.
파티션 적용테이블에서 거래내역이나 이력데이터를 보관할경우 대부분이 일자로 Range 파티션을 하게된다.

Global 통계정보를 생성하려면 10g 까지는 2단계의 과정을 거쳐야 했다.

첫번째로는 파티션 레벨의 통계정보를 생성 하기위해 각파티션을 scan 하는작업수행.

두번째로는 Global 통계정보를 생성하기위해 전체 파티션을 scan 하는 작업수행.
정말 비효율적이지 않는가? 같은 파티션을 두번씩 읽은 셈이다.

10g 에서는 아래처럼 granularity를 옵션으로 사용하거나 아니면 수동으로 2번 돌려야 했다. 아래예제 에서는
estimate_percent 를 10% 로 한정 하였다.

exec dbms_stats.gather_table_stats('CUST', 'CUSTOMERX', estimate_percent =>10, granularity =>'GLOBAL and PARTITION');

위의 방법대로 하면 전체 파티션을 내부적으로 2번씩 scan 해야 하므로 성능면에서 최악이다.
경험 많은 DBA 는 새로이 추가된 파티션의 통계정보만 생성하고 Global 통계정보를 생성함으로 전체 파티션에 대하여 2번씩 scan 하는 비효율을 제거한다. 아래처럼 새로 추가된 파티션을 명시하면 된다.

exec dbms_stats.gather_table_stats('CUST', 'CUSTOMERX', 'PART10', estimate_percent =>10, granularity =>'PARTITION');
exec dbms_stats.gather_table_stats('CUST', 'CUSTOMERX', estimate_percent =>10, granularity =>'GLOBAL');
하지만 2번째의 방법으로도 Global 통계정보의 생성을 위한 전체 파티션 scan은 막을수 있는 방법이 없었다
.
이러한 성능 이슈 때문에 11g 에서는 2단계의 과정이 없어지고 과정이 하나로 줄었다. 쉽게 말하면 각파티션 통계정보를 생성해놓고 Global 통계정보 생성시 파티션의 통계정보를 sum 하여 이용한다는 것이다. 또한 특정파티션을 지정하지 않아도 아래와 같이 gather_table_stats 을 수행하기전에 set_table_prefs를 수행하게 되면 바뀌거나 새로이 insert 된 파티션만 scan 을 하게된다.
11g :

exec dbms_stats.set_table_prefs('CUST', 'CUSTOMERX', 'INCREMENTAL', 'TRUE');
exec dbms_stats.gather_table_stats(‘CUST', 'CUSTOMERX', granularity =>'GLOBAL and PARTITION');

11g 에서는 estimate_percent를 10% 로 한정 하지 않았기 때문에 성능 어떨지 궁금하지 않은가?

아래의 테스트 결과를 보자.

DataBase Ver Elapsed Time (s)
------------------------------- ----------------
Oracle Database 11g Incremental 1.25
Oracle Database 10g Release 2 10% 2152 --> 전체를 2번 scan 한 경우
Oracle Database 10g Release 2 10% Manual 1058 --> 추가된 파티션만 명시한 경우

10g 에서 추가된 파티션만 명시한 경우에 비하여 무려 800 배 정도 빨라졌다. 대단하지 않은가?

이것은 3가지의 효과가 서로 상호작용한 효과이다.
1.Global 통계정보 생성시 2단계의 작업(각 파티션의 작업 + Global 작업) 이 1단계로 축소되고
2.Imcremental NDV 작업이 가능 해졌다는것
3.미리 언급한 hash-based algorithm 의 효과

2015년 1월 6일 화요일

2015년 첫책 - ZERO to ONE

Startup 기업을 포함한 모든 기업이 반드시 답해봐야할 일곱가지 질문 !!

1. 기술
점진적 개선이 아닌 획기적인 기술을 만들어 낼수 있는가 ?

2. 시기
이 사업을 시작하기에 지금이 적기인가 ?

3. 독점
작은 시장에서 큰 점유율을 가지고 시작하는가 ?

4. 사람
제대로 된 사람을 갖고 있는가 ?

5. 유통
제품을 단지 만들기만 하는 것이 아니라 전할 방법을 가지고 있는가 ?

6. 존속성
시장에서의 현재 위치를 향후 10년, 20년간 방어할 수 있는가 ?

7. 숨겨진 비밀
다른 사람들은 보지 못하는 독특한 기회를 포착했는가 ?

2015년 1월 4일 일요일

Oracle ASMLib: Physical and Logical Blocksize

FEBRUARY 27, 2014 4 COMMENTS

This article is about the use of Advanced Format devices on Oracle’s ASMLib kernel library for Linux. For background, read this page on 4k sector sizes first, otherwise it might all sound like nonsense. Mind you, it mind sound like nonsense anyway, I can’t guarantee anything here. By the way, a big hello to my buddy Nate who asked for this information: you rock, dude.

In more recent versions of ASMLib, Oracle introduced a new parameter into the /etc/sysconfig/oracleasm file:

[root@half-server4 mapper]# tail -5 /etc/sysconfig/oracleasm
# ORACLEASM_USE_LOGICAL_BLOCK_SIZE: 'true' means use the logical block size
# reported by the underlying disk instead of the physical. The default
# is 'false'
ORACLEASM_USE_LOGICAL_BLOCK_SIZE=false

To understand what this parameter does, consider this device which I am presenting from a Violin array:

[root@half-server4 ~]# ls -l /dev/mapper/testlun
lrwxrwxrwx 1 root root 8 Feb 27 15:33 /dev/mapper/testlun -> ../dm-19
[root@half-server4 ~]# fdisk -l /dev/mapper/testlun

Disk /dev/mapper/testlun: 34.4 GB, 34359738368 bytes
255 heads, 63 sectors/track, 4177 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 524288 bytes

The important bit there is highlighted in red. This device has a 4k physical blocksize (as all Violin devices do, as well as many other modern storage systems) but has a 512 byte logical blocksize. Essentially, this LUN is pretending to be a 512 byte based.

Now that’s all well and good. Operating systems and applications that cannot support 4k block sizes (e.g. Red Hat 5 and Oracle Linux 5) will happily use this, because they believe it to be 512 byte. But later versions of ASMLib have started being too clever for their own good.

Don’t Look Behind The Curtain

Let’s create an ASMLib label on this device:

root@half-server4 ~]# oracleasm createdisk TESTLUN /dev/mapper/testlun 
Writing disk header: done
Instantiating disk: done

And now we can attempt to put an ASM diskgroup on it:

SQL> CREATE DISKGROUP TEST EXTERNAL REDUNDANCY
DISK 'ORCL:TESTLUN'
ATTRIBUTE
     'sector_size'='512',
     'compatible.asm' = '11.2',
     'compatible.rdbms' = '11.2';  
CREATE DISKGROUP TEST EXTERNAL REDUNDANCY
*
ERROR at line 1:
ORA-15018: diskgroup cannot be created
ORA-15038: disk '' mismatch on 'Sector Size' with target disk group [4096]
[512]

What happened? Well, ASMLib has looked behind the smoke and mirrors and decided that this is actually a 4k device. It’s therefore presenting this to Oracle ASM as 4k, which causes the problem (because I explicitly asked for sector size to be 512 byte on this diskgroup).

One possible solution is to change the ASM_DISKSTRING from it’s default value of NULL (meaning ‘ORCL:*’) to ‘/dev/oracleasm/disks/*’, i.e. the location where ASMLib creates its own block devices. We can test this theory with fdisk:

[oracle@half-server4 ~]$ ls -l /dev/oracleasm/disks/TESTLUN 
brw-rw---- 1 oracle dba 252, 19 Feb 27 15:38 /dev/oracleasm/disks/TESTLUN
[oracle@half-server4 ~]$ fdisk -l /dev/oracleasm/disks/TESTLUN | grep "Sector size"
Sector size (logical/physical): 512 bytes / 4096 bytes

So that would work. But it would lose many of the claimed benefits of ASMLib such as reduced file descriptors and context switching. Also, it feels like a hack.

Setting ORACLEASM_USE_LOGICAL_BLOCK_SIZE

The answer, as you probably guessed, is to set this new parameter. It defaults, wrongly in my opinion, to using the physical block size. We can either edit the value in the file to be true in order to use the logical blocksize, or preferably use the oracleasm configure command:

root@half-server4 ~]# oracleasm configure -b
Writing Oracle ASM library driver configuration: done
[root@half-server4 ~]# oracleasm configure | grep ORACLEASM_USE_LOGICAL_BLOCK_SIZE
ORACLEASM_USE_LOGICAL_BLOCK_SIZE="true"

It can be set back to using the physical blocksize with the following command:

[root@half-server4 ~]# oracleasm configure -p
Writing Oracle ASM library driver configuration: done
[root@half-server4 ~]# oracleasm configure | grep ORACLEASM_USE_LOGICAL_BLOCK_SIZE
ORACLEASM_USE_LOGICAL_BLOCK_SIZE="false"

Finally, a word of warning. If you are like me, then you are a bit stupid and can’t follow instructions properly. I set the value of the parameter to TRUE in upper case and then spent hours wondering why it didn’t work. The answer, to my embarrassment, is that it’s case sensitive. TRUE is not a valid value so it defaults to false. Doh.

Understanding 4KB Sector Support for Oracle Files By Karen Reliford

Understanding 4KB Sector Support for Oracle Files

By Karen Reliford

An important decision that DBAs make when they are first creating a new Oracle database is what the standard database block size should be. Once the database is created, it is virtually impossible to change the standard block size without recreating the entire database. Read on to learn how to create tablespaces with different block sizes.

An important decision that DBAs make when they are first creating a new Oracle database is what the standard database block size should be. Oracle generally supports five options, 2K, 4K, 8K (now the default), 16K and 32K. The blocksize is determined by the DB_BLOCK_SIZE parameter and once the database is created, it is virtually impossible to change the standard block size without recreating the entire database.
The block size is important because it has inherent performance impacts that range from contention to reads. The smaller blocks are better to reduce contention because there are usually fewer rows per block and this is generally favored for online transaction systems. However, data warehouse or DSS systems benefit from a larger block size because Oracle is able to retrieve more rows per block read. Fortunately, since Oracle 9i, we have had the ability to create tablespaces with different block sizes, which allows for transportable tablespaces between databases and gives DBAs the ability to even further control storage options.
It is well understood that the DB_BLOCK_SIZE becomes the default block size for the data files for any tablespace that is created without a specific blocksize option. However, folks may also assume that the default block size actually applies to ALL of the Oracle database files associated with their databases. Well, surprise! This is not actually the case. The DB_BLOCK_SIZE parameter does not control the size of the redo log files (this includes online redo logs, archived redo logs and standby redo logs) nor the control file.
In all of the versions of Oracle from 11gR1 and prior - it can be kind of tricky to determine exactly what block size is being used for these files. That is because this information is not readily available in most of the associated v$ views. There are three v$ views that are used to gather information about the logs and control files. These are v$log, v$logfile and v$controlfile.
Let's start by doing a describe on the v$log and v$logfile views (these examples are from a 10g database with the DB_BLOCK_SIZE parameter set to 8K), an 11gR1 database would show the same results). As you can see by the images below, neither view shows us any information about the actual block size for the files.

In order to really find out what the block size is for the redo files, we need to query one of the x$ tables. The table is x$kccle (Kernel Cache ControlfileComponent Log Entry). The lebsz column shows the actual block size being used by the redo logs.

As we can see by this view, the block size being used is 512 bytes- which does not match any of the valid values for DB_BLOCK_SIZE. This value is derived automatically by Oracle and is based on the standard sector size for hard drives, which for many years has been 512 bytes.
The other major file type associated with Oracle databases is the control file. We can confirm the block size of the control files by checking the cfbsz column of x$kcccf (Kernel Cache Current Control File).

As we can see, the control file uses a block size of 16K regardless of what the DB_BLOCK_SIZE is set to.
For many years and most systems, these settings for the log file block size and control file size have been fine, and fully compatible with the sector size of the actual hardware devices that we have been using.
However, hardware has been changing and evolving, and some storage systems now use a 4K sector size rather than the old 512 byte sector size. While this is not an issue for our control file block size of 16K because it is a multiple of the new sector size, it does present a possible performance degradation issue for the default log file block sizes because they do not match the hardware sectors.
With 11g R2, Oracle has introduced the necessary support for us to control the block size of the redo logs so that we are able to match them to the newer 4K hardware sector sizes, which will ultimately provide the performance benefit of ensuring the log write entries are going to align with the sector size of the hardware.
There are two types of 4K sector disks available. 4K emulation mode disks and 4K native mode disks.
The 4K emulation mode disks have a 4K physical sector, which is comprised of eight 512 byte logical sectors.

4K PHYSICAL SECTOR
Log Sec 1	Log Sec 2	Log Sec 3	Log Sec 4	Log Sec 5	Log Sec 6	Log Sec 6	Log Sec 8

With this configuration, the device still maintains a 512 byte interface to the disk maintained through the LBA (logical block address). If a LGWR write is not aligned with the beginning of a physical 4K sector, there will be a significant performance hit.
With 4K native mode disks, the physical sector and LBA are both 4K.

4K PHYSICAL SECTOR

Log Sec 1

With this type of disk, there is only a 4K interface available to the disk.
Beginning in Oracle 11g R2, Oracle has new recommendations for the block sizes for the redo log files and data files.

512 Byte Sector Disks

512K block size is mandatory for redo logs
any size can be used for the database block size
16K will be used for the control file block size by default

4K Emulation Mode Disks

4K block size is recommended for redo logs
a multiple of 4K is recommended for the database block size (which most systems are)
16K will be used for the control file block size by default

If log files are created with a 512 byte size on a system using 4K emulation, a warning will be written to the alert log regarding the potential for performance degradation.

4K Native Mode

16K will be used for the control file block size by default

To specify a 4K size when using ASM, we add a new attribute to the CREATE DISKGROUP command, which is the sector size. The two valid values for sector_size are 4096 or 512.

CREATE DISKGROUP group1 NORMAL REDUNDANCY
FAILGROUP f1 DISK
'/dev/diska1',
'/dev/diska2',
'/dev/diska3',
'/dev/diska4'
FAILGROUP f2 DISK
'/dev/diskb1',
'/dev/diskb2',
'/dev/diskb3',
'/dev/diskb4'
ATTRIBUTE 'sector_size'='4096';

To create log files with 4K blocks add the BLOCKSIZE option to the create log file command (this applies both to the CREATE DATABASE and ALTER DATABASE ADD LOGFILE GROUP commands). Again, the valid values are 4096 or 512. (1024 is support for some HP platforms).

CREATE DATABASE mydb NORESETLOGS FORCE LOGGING
ARCHIVELOG
LOGFILE
  GROUP 1 '$ORACLE_BASE/oradata/mydb/redo01.rdo'
   SIZE 100M BLOCKSIZE 4096,
  GROUP 2 '$ORACLE_BASE/oradata/mydb/redo02.rdo‘
   SIZE 100M BLOCKSIZE 4096
DATAFILE
....
 
 
 
ALTER DATABASE mydb ADD LOGFILE GROUP 3
('$ORACLE_BASE/oradata/mydb/redo03a.rdo',
'$ORACLE_BASE/oradata/mydb/redo03b.rdo')
SIZE 500K BLOCKSIZE 4096;

Also, with Oracle 11gR2 , a new column has been added to the v$log view which shows the blocksize.
If you are upgrading the hardware associated with your 11gR2 database from a system that formerly had 512 byte sectors to one that has the new 4K sector size, the easiest solution is to create new redo groups with the 4K block size, perform the ALTER SYSTEM SWITCH LOGFILE command until the new groups are in use and the old ones are inactive, and then drop the old 512 byte redo log groups.
If your hardware supports the 4K sector size, even in emulation mode, it is very important, for performance reasons, to make sure you adjust the database redo log files appropriately.

2015년 새해는 차 추돌 사고로 시작함.

2015년 새해 첫 출근길...

집 앞 아파트 이면도로에서 앞차를 추돌하다.
옆의 차가 앞에 있는 트럭을 피하면서 내 쪽으로 오는 것만 보고 피하면서 신호를 대기하고 있는 앞차를 늦게 보고 브레이크를 밟았는데...

살짝 얼어 있어서 주~욱 밀리면서 쿵...

여느해와는 달리 올해는 여러가지로 많이 나타해져서 아무런 준비를 하지 않고 시간이 지나는대로 새해를 맞이했다.

특히 신앙적으로 많이 나태해져서 새해 첫 특별새벽기도회도 나가지 않고...

올해는 정말 정신을 바짝 차려야겠다.
많은 일들이 일어날터인데... 자만치 말고...