สวัสดีค่าา ทุกคน ยังจำหน่องเตยคนนี้กันได้มั้ยเอ่ยยย กลับมาพบกันในรอบปีอีกแล้ว คราวนี้หน่องเตย จะชวนทุกคนมาลองเล่น Feature Data Redaction บน Database ค่าย EDB Postgres กันค่ะ… ขอเสียงสาวก Database Postgres หน่อยค่าาา วู้วววๆ :D

สำหรับใครที่ยังงงว่า เอ๊ะ! Postgres กับ EDB Postgres นี่มันเหมือนกันหรือเปล่านะ !?

ทางนี้มีคำตอบให้ค่าา ❤ ใครที่คุ้นเคยกับ Postgres อยู่แล้ว ก็จะทราบกันดีว่า Postgres เป็น Database open source ใน ฉายาที่ว่า “The World’s Most Advanced Open Source Relational Database” ที่ร่วมพัฒนาโดย developer ที่ทราบกันในชื่อ PostgreSQL Global Development Group เป็นที่นิยมใช้กันอย่างแพร่หลาย ทั้งระบบเล็กๆ ไปจนถึงองค์กรใหญ่ๆ ที่มี transaction ตลอดทั้งวัน โดย Logo ของเค้าจะเป็น คุณช้างสีฟ้ามีงา น่ารักสุดๆ แบบนี้เลยค่ะ

ส่วนเจ้า EDB Postgres จะเป็น Database ที่มีการทำงาน base on Postgres แต่เพิ่มความเป็น Enterprise เข้ามาได้แก่ Security, Productivity, Performance และ Oracle database compatibility ค่ะ นอกจากนี้ ยังมี subscription ในการเปิดเคส support issue กับทีมงานที่มีความเชี่ยวชาญด้าน Postgres ด้วยนะคะ ใครที่เคยเจ็บหัวใจกับการแก้เคส Postgres โดยไม่มีที่ปรึกษา และ knowledge center น่าจะถูกใจมากๆ เลยล่ะค่ะ ส่วน Logo ของ EDB จะเป็นคุณช้างสีส้ม โมเดิร์นๆ แบบนี้เลยค่ะ

เกริ่นมาพอสมควร ขอเข้าเรื่องเลยแล้วกันนะคะ เนื่องจากกระแส การใช้งาน Database Postgres เริ่มมีมากขึ้นในทุกปี รวมถึงบางองค์กรเริ่มเห็นถึงความสำคัญด้าน Security มากขึ้นตามกฎหมายคุ้มครองข้อมูลส่วนบุคคล (PDPA) จึงได้เริ่มขยับขยายมาใช้งาน EDB Postgres กันบ้างเพื่อให้ครอบคลุม ด้าน Security ในราคา subscription ที่น่ารัก วันนี้หน่องเตยเลยเลือก feature ด้าน security อย่าง Data Redaction มาเล่นให้ดูกันค่ะ มาดูกันเล้ยยยย GO! GO! GO!

Demo วันนี้หน่องเตยมี environment ที่เป็น EDB Postgres 2 เครื่อง set replicate ข้อมูลกันอยู่ แต่การ configure redaction จะทำที่เครื่อง Master เท่านั้นค่ะ
Master hostname: edb-postgres
Slave hostname: edb-postgres-slave
โดยจะมี 5 ขั้นตอนง่ายๆ ตามนี้เลย

เริ่มจากต้องตรวจสอบการเปิด Feature Redaction ที่ parameter edb_data_redaction ในไฟล์ postgresql.conf

ตรวจสอบ parameter จากคำสั่งใน psql

Show edb_data_redaction;

ตรวจสอบ parameter จากไฟล์ postgres.conf ที่ path data

cat postgresql.conf |grep edb_data_redaction

โดยปกติแล้ว ค่า Default ของ parameter edb_data_redaction จะ enable ไว้ ซึ่งเมื่อมีการตั้ง redaction policy จะมีผล redaction ได้เฉพาะ user ที่ match กับ policy condition ยกเว้น Superusers และ table owner ที่จะถูก bypass data redaction และจะยังเห็น Original data ได้ค่ะ

เมื่อ enable parameter เรียบร้อยแล้ว จะเข้าสู่ database ด้วย user enterprisedb ซึ่งเป็น superuser ของ database

ตรวจสอบ connection information ของ user enterprisedb

\conninfo
\du enterprisedb

ขั้นตอนนี้ให้ เลือก table ที่มี sensitive data มาค่ะ แต่เนื่องจากเป็น demo หน่องเตยขอสร้าง table ขึ้นมาใหม่นะคะ

ทำการสร้าง table ตัวอย่างในการทำ redaction

CREATE TABLE edb_redaction_tab (
id_card varchar(17) NOT NULL,
first_name varchar(40) NOT NULL,
last_name varchar(40) NOT NULL,
phone varchar(10),
birthday date,
salary money,
email varchar(100));

ทำการ Insert ข้อมูลตัวอย่างที่มี Sensitive data

INSERT INTO edb_redaction_tab (id_card, first_name, last_name, phone, birthday, salary, email) VALUES
( ‘1–1234–56789–01–2’, ‘Thongjai’, ‘Saisom’, ‘0961234567’, ‘19-Jun-1984’,84550.25, ‘thongjai.s@srs.com’),
( ‘3–1267–84989–03–9’, ‘Manita’, ‘Chujai’, ‘0871234567’, ‘2-Jan-1990’, 65750.00,’manita.c@srs.com’),
( ‘1–3214–88079–05–7’, ‘Samachet’, ‘Ketsuwan’, ‘0631234567’, ‘15-Nov-1994’, 44500.00, ‘samachet.k@srs.com’);

ขั้นตอนนี้ให้เลือก user ที่ต้องการจัดการสิทธิ์ในการดูข้อมูล หรือต้องการ ปกปิดข้อมูล

ใน Demo นี้จะทำการสร้าง user ตัวอย่าง 2 users โดยจะตั้ง redaction ให้ user hr มีสิทธิ์ในการเห็น sensitive data และ user app_adm มีสิทธิ์เห็นเพียงข้อมูลบางส่วนของ table

CREATE USER hr;
alter user hr password ‘welcome1’;
CREATE USER app_adm;
alter user app_adm password ‘welcome1’;

ให้สิทธิ์ 2 users สามารถใช้งาน table ตัวอย่าง

GRANT ALL ON edb_redaction_tab TO hr, app_adm;

ตรวจสอบ Privilege บน table ตัวอย่างที่ Grant ให้กับ 2 users

SELECT * FROM information_schema.role_table_grants
WHERE table_name=’edb_redaction_tab’ and grantee in (‘hr’,’app_adm’);

ทำการสร้าง Redaction function ตาม column ที่ต้องการปกปิกข้อมูล sensitive data โดย demo นี้ทำ 3 columns คือ id_card, phone, salary

CREATE OR REPLACE FUNCTION myredact_id_card (id_card varchar(17)) RETURN varchar(17) IS
BEGIN
/* replaces 1–1234–56789–01–2 with 1-xxxx-xxxx9–01–2 */
return overlay (id_card placing ‘xxxx-xxxx’ from 2) ;
END;

CREATE OR REPLACE FUNCTION myredact_phone (phone varchar(10)) RETURN varchar(10) IS
BEGIN
/* replaces 0961234567 with 096xxxx567 */
return overlay (phone placing ‘xxxx’ from 4) ;
END;

CREATE OR REPLACE FUNCTION myredact_salary ()
RETURN money IS
BEGIN
return 0::money;
END;

ตรวจสอบ Function ที่สร้างสำเร็จ

select proname,prosrc from pg_proc where proname like ‘myredact%’;

ทำการสร้าง Policy Redaction จาก Function ที่สร้างไว้ โดยให้เงื่อนไขว่า user ที่ไม่ใช้ hr (และ superuser) ถูกปกติปิดข้อมูลตาม policy

CREATE REDACTION POLICY myredact_personal_data ON edb_redaction_tab FOR (session_user != ‘hr’)

ADD COLUMN id_card USING myredact_id_card(id_card) WITH OPTIONS (SCOPE query, EXCEPTION equal),

ADD COLUMN phone USING myredact_phone(phone) WITH OPTIONS (SCOPE query, EXCEPTION equal),

ADD COLUMN salary USING myredact_salary() ;

ตรวจสอบ redaction policy ที่สร้างสำเร็จ

Select * from edb_redaction_policy;

หลังจากสร้าง Policy เสร็จแล้ว ก็ไปลอง Test กันเลยค่าาาา เริ่มจากการทดสอบบนเครื่อง Master กันก่อนเลย

1. เข้า database ด้วย user enterprisedb (superuser, table owner) จะเห็นข้อมูล original ใน table

2. เข้า database ด้วย user hr (privilege user) จะเห็นข้อมูล original ใน table

3. เข้า database ด้วย user app_adm (non-privileged user) จะเห็นข้อมูล sensitive data ถูก redaction ใน table

มาถึงการทดสอบบนเครื่อง Slave ที่ replicate data ไว้ ก็ได้รับ replicate policy ด้วยเช่นกันค่ะ ทำให้ user app_adm ที่เข้าเครื่อง Slave ถูกปกปิดข้อมูล sensitive ด้วยค่ะ

เป็นยังไงกันบ้างคะ 5 steps ง่ายๆ ก็ได้ redaction policy มาป้องกันข้อมูล sensitive data แล้วค่ะ

Note ไว้หน่อยนึงนะคะ เรื่องข้อจำกัดของการทำ data redaction

- Redaction Policy ที่สร้างใช้กับ table ที่เป็น inheritance hierarchies (parent table) จะไม่สามารถสืบทอดไปใช้กับ child table ได้ ทำให้ user ที่ access ผ่าน child table ยังสามารถเรียกดู original data ได้

- Redaction Policy ไม่สามารถสืบทอดไปยัง Materialized view ของ table ได้ ถ้าหาก superuser หรือ table owner ได้ GRANT SELECT on table และ materialized view ให้กับ non-superuser ทำให้ user คนนั้นสามารถเรียกดู original data ได้ผ่าน materialized view

- Objects ที่เกี่ยวข้องใน redaction function ต้องมีการใส่ schema ที่เป็น owner กำกับไว้ หากไม่ใส่อาจส่งผลให้การทำ pg_dump operation fail ได้ค่ะ

นอกจากตัว Feature Data Redaction ที่ลองมาเล่นให้ดูกันแล้ว ทาง EDB Postgres ก็ยังมีอีกหลาย Feature ด้าน security ที่เพิ่มความเป็น enterprise มากขึ้นให้กับ Postgres ทุกคนสามารถไปลองศึกษาและลองเล่นกันดูได้นะคะ list feature ด้าน security มีดังนี้ค่ะ

สำหรับชาว Medium หลายคนที่ตอนนี้น่าจะ Work From Home กันยาวๆ มาตั้งแต่ช่วงต้นปี ด้วยสถานการณ์ Covid-19 ในบ้านเราช่วงนี้ ยังไงก็ขอให้ทุกคนรักษาตัวกันให้ดีนะคะ ด้วยความห่วงใย จากใจดวงน้อยๆของหน่องเตย ❤

ถ้าอยู่บ้านกันเหงาๆ ลองเล่น Database EDB Postgres กันดูได้นะคะ :D

❤-❤-❤-❤-❤-❤-❤-❤-❤-❤-❤-❤-❤-❤-❤-❤-❤-❤-❤-❤-❤-❤-❤-❤-❤

สำหรับผู้ที่สนใจติดต่อทีมงาน DBA ( Database Administrator) ไปช่วยตรวจสอบและดูแลระบบของท่าน ไม่ว่าจะเป็น
- ต้องการผู้ช่วยตรวจสอบปัญหา Database
- ต้องการผู้ช่วยดูแลระบบ Database ขององค์กร
- ต้องการย้ายระบบ และต้องการคำปรึกษาด้านการออกแบบระบบฐานข้อมูล
- ต้องการทำ Database Security
- ต้องการปรึกษาเรื่อง Tool Database Security หรือ Tool ในการ Monitor ระบบ
และอีกหลากหลายบริการด้าน Database

สามารถติดต่อมาที่ Facebook Sirisoft
ทาง website www.sirisoft.co.th
หรือทาง LINE Sirisoft Official ได้นะคะ

ทางเรามีทีมงาน DBA ที่พร้อมให้บริการด้าน Database Oracle, MSSQL, PostgreSQL, EDB Postgres เสมอค่ะ

ติดต่อมาได้เลยน้าา ทีมงานพร้อมจะดูแลทุกท่านค่าาา

Work From Home เหงาๆ มาเล่น Data Redaction บน EDB Postgres กันดีกว่า was originally published in Sirisoft on Medium, where people are continuing the conversation by highlighting and responding to this story.

สวัสดีค่ะ ทุกคน กลับมาพบกับหน่องเตยอีกแล้วนะคะ Blog นี้เป็น Blog ที่ 4 ของหน่อยเตยแล้วน้า ขอบคุณมิตรรักแฟน Blog Medium ทุกท่านที่ยังเหนียวแน่นแวะเวียนเข้ามาด้วยนะคะ ส่วนใครตกรถ มาไม่ทัน ไปตามอ่านย้อนหลังกันได้ ที่นี่ เลยค่ะ

เข้าเรื่องกันดีกว่า.. หน่องเตยมาวันนี้ ก็ต้องมีเรื่องดี๊ดีย์ มานำเสนอให้ทุกคนแน่นอนค่ะ นั่นก็คืออออออ การ Monitor Oracle Database Performance นั่นเองงงง :3

เหตุผลที่เราควรจะ Monitor Database Performance นั้น ก็เป็นเพราะว่าเราต้องคอยตรวจสอบการทำงานของระบบ Database ในช่วงเวลาที่ User มีการใช้งานเยอะ หรือที่เรียกว่าช่วง Peak เพื่อจะได้ประเมิน Resource ของระบบ ว่าเพียงพอต่อการใช้งานหรือไม่

ซึ่งหากในช่วง Peak ที่เรา Monitor อยู่นั้นมีการทำงานของระบบที่ดูผิดปกติ เราจะได้ตรวจสอบและแก้ไขปัญหาได้ทัน ลดโอกาสระบบฐานข้อมูลล่ม ซึ่งอาจเป็นสาเหตุหนึ่งของการที่ Website หน้าบ้านไม่สามารถใช้งานได้ ด้วยนะคะ

โดยปกติ การ Monitor หรือ Diag ปัญหา เราจะต้อง Focus เส้นทางการทำงานของระบบนั้นๆ ตั้งแต่ Application > Network > OS > Database ซึ่งในวันนี้ หน่องเตยจะขอตัดตอนมา Focus ที่ Database level กันนะคะ เพราะ Database Retrieve ข้อมูลไว ก็มีชัยไปกว่าครึ่งแล้วค่ะ :D

4 จุด เบื้องต้น ในการเริ่ม Monitoring Database มีดังนี้ค่ะ

1. Database Alert log

Alert log ของ Database นั้นนับว่าเป็นไฟล์ที่ค่อนข้างมีความสำคัญมากค่ะ เพราะ Database จะ Logging ข้อมูลที่เกิดขึ้นใน Database เช่น Error ต่างๆของระบบ, การเกิด Deadlock, Log ระหว่างการ Start up-Shut down Database รวมถึง Statement การ Drop, Create, Alter ต่างๆภายในระบบ

โดยเราสามารถหาไฟล์ Alert log ได้จาก

$ORACLE_BASE/diag/rdbms/<dbname>/<SID>/trace/alert_<SID>.log

หรือสามารถ query เพื่อดู path ของ alert log ด้วยคำสั่ง

select * from v$diag_info;

เมื่อเข้าไปที่ Path /u01/app/oracle/diag/rdbms/kulicodb/kulicodb/trace ก็จะเปิดไฟล์ alert_<SID>.log ซึ่งสามารถช่วยเราในการ Diag ปัญหาหรือเห็นความผิดปกติของระบบที่เกิดขึ้นใน Alert log ได้ ตัวอย่างข้อมูลในไฟล์ ดังรูปต่อไปนี้ค่ะ

ถ้า Database ของเรามีปัญหา อาจจะสังเกตได้จาก Error Code ที่ขึ้นอยู่ใน Alert log ค่ะ อย่างเช่น ORA-00020: maximum number of processes (400) exceeded ดังรูปนี้ค่ะ

จากรูปตัวอย่างนี้ Error ตัวนี้ มีผลทำให้ User ไม่สามารถ Connect Database ได้เนื่องจาก Process เต็ม ก็จะเป็นข้อมูลให้เราวิเคราะห์ต่อไปได้ว่า ระบบมีจำนวนผู้เข้าใช้งานเพิ่มขึ้นจริง, การเขียน Logic ของ Application ที่ยิงเข้ามาไม่ถูกต้อง, ถูกก่อกวนโดยผู้ไม่หวังดี หรืออาจเป็นที่การตั้งค่า Parameter ไม่เหมาะสมกับการใช้งานจริง จากนั้นจึงหาวิธีการแก้ไขปัญหานี้ต่อไปค่ะ

2. Database Cache

การ Monitor Database Cache นั้นเป็นการตรวจสอบความเพียงพอต่อการใช้งานในส่วน Memory ที่ได้ Allocate ให้กับ Database ค่ะ ถ้าใครทำงานสาย DBA จะทราบกันดีเรื่อง Memory Component ภายใน Database Instance ตามรูปนี้เลยค่ะ

วันนี้จะขอพูดถึงส่วนของ Cache ใน Memory นะคะ ที่ประกอบไปด้วย Cache หลักๆ ดังนี้

❤ DB Buffer Cache: เป็น Memory cache ส่วนที่เก็บ Data ที่ถูก Retrieve จาก Physical ไฟล์ขึ้นมาไว้บน Memory

❤ Library Cache: เป็น Memory cache ส่วนย่อยของ Share pool ที่ใช้สำหรับเก็บ SQL Statement และ Objects ที่ถูกเรียกใช้ขึ้นมาไว้บน Memory

❤ Data Dictionary Cache: เป็น Memory cache ส่วนย่อยของ Share pool ที่เก็บข้อมูล Database Table, View, Structure และ ข้อมูล User จะถูก Access บ่อยๆ เมื่อมี SQL Statement Executes บน Database

ซึ่งวิธีการ Monitor Cache นั้นก็จะเป็นการ Select ค่า Cache Hit Ratio ขณะที่ระบบมีการใช้งานอยู่ เพื่อตรวจสอบว่า Cache มีขนาดเพียงพอในการเก็บข้อมูลที่ถูกเรียกใช้บ่อยหรือไม่ค่ะ โดยใช้คำสั่ง

SELECT ‘DB_Buffer_Cache_Hit_ratio ‘
||round(100*(1 — (physical_reads / (db_block_gets + consistent_gets))),2)
|| ‘%’ AS “Cache Hit Ratio [%]”
FROM v$BUFFER_POOL_STATISTICS
union all
SELECT ‘Library_Cache_Hit_ratio ‘
||round(100*(sum(pinhits)/sum(pins)),2)
|| ‘%’ AS “Cache Hit Ratio [%]”
FROM v$LIBRARYCACHE
union all
SELECT ‘Dictionary_Cache_Hit_ratio ‘
||round(100*(1-(sum(getmisses)/sum(gets))),2)
|| ‘%’ AS “Cache Hit Ratio [%]”
FROM v$ROWCACHE;

โดยค่า Hit Ratio ที่ได้ควรมีค่า 95–100% หมายความว่า Retrieve Data ได้จาก Cache (Cache Hit) เลย ไม่ต้องไปดึงจาก Physical File นั่นหมายความว่า ระบบ Return ข้อมูลได้ไวค่ะ แต่ถ้าหากค่าที่ได้น้อยกว่า 95% ต้องมาพิจารณาการใช้งานแล้วค่ะ ว่าระบบนี้ได้ Allocated Memory และ แบ่ง Pool ต่างๆใน SGA ไว้พอใช้หรือเปล่า หรือมีสาเหตุอื่นร่วมด้วยหรือเปล่า ซึ่งจะเป็นเรื่องของการ Tuning Memory Parameter ค่ะ

3. Database Session

การ Monitor Database Session แบบพื้นฐาน หน่องจะใช้วิธีเข้าไป Select Session ดูจากใน Database เลยค่ะ โดย Query จาก View v$session ซึ่งสามารถดูจำนวน Session ได้แบบ Real-Time เลยค่ะ โดยใช้ Query ดังนี้

select sid,serial#,username, program, machine,osuser, inst_id, count(*)

from gv$session where username is not null

group by sid,serial#,username, program, machine, inst_id, osuser

order by 6;

ก็จะพบกับข้อมูล ของ Session ที่ต่อเข้ามาที่ Database ถ้าเป็นระบบที่ Implement แบบ RAC ที่ column INST_ID จะเป็นตัวบอกว่า Session นั้นๆ ต่อไปที่ Instance ไหนด้วยค่ะ ซึ่งตรงนี้จะช่วยให้เราตามสืบได้ ว่า SID ไหนเป็นตัวการทำให้ CPU ของ Database Instance ขึ้นสูงได้ด้วยนะคะ อิอิ ตัวอย่าง Session ตามรูปด้านล่างนี้เลย

และหากต้องการตรวจสอบว่ามี Query Lock กันอยู่ เป็นสาเหตุให้เกิด Blocking session และมี wait หรือเปล่า สามารถใช้คำสั่งต่อไปนี้เพื่อตรวจสอบได้เลยค่ะ

SELECT
DECODE (l.BLOCK, 0, ‘Waiting’, ‘Blocking ->’) user_status
,CHR (39) || ses.SID || ‘,’ || ses.serial# || CHR (39) sid_serial
,(SELECT instance_name FROM gv$instance WHERE inst_id = l.inst_id) conn_instance
,ses.SID ,ses.PROGRAM ,ses.osuser ,ses.machine
,DECODE (l.TYPE,’RT’, ‘Redo Log Buffer’,’TD’, ‘Dictionary’,’TM’, ‘DML’,’TS’, ‘Temp Segments’,’TX’, ‘Transaction’,’UL’, ‘User’,’RW’, ‘Row Wait’,l.TYPE) lock_type
,DECODE (l.lmode,0, ‘None’,1, ‘Null’,2, ‘Row Share’,3, ‘Row Excl.’,4, ‘Share’,5, ‘S/Row Excl.’,6, ‘Exclusive’,LTRIM (TO_CHAR (lmode, ‘990’))) lock_mode
,ctime ,object_name
FROM gv$lock l JOIN gv$session ses ON (l.inst_id = ses.inst_id AND l.SID = ses.SID)
JOIN gv$locked_object o ON (o.inst_id = ses.inst_id AND ses.SID = o.session_id)
JOIN dba_objects d ON (d.object_id = o.object_id)
WHERE (l.id1, l.id2, l.TYPE) IN (SELECT id1, id2, TYPE FROM gv$lock WHERE request > 0)
ORDER BY id1, id2, ctime DESC;

จากรูปก็จะเห็นข้อมูลว่า Session ไหนบ้างที่กำลัง lock กันอยู่ที่ Object ไหน ซึ่งการ lock นี้อาจเกิดจาก Query ทำงานช้าต้อง Tuning หรือเกิดจากการเรียง Sequence ของงานไม่สอดคล้องกับระยะเวลาที่ใช้ในแต่ละ Transaction อาจะเป็นตัวช่วยให้เราปรับแก้ที่ logic, sequence งานหรือหน่วงเวลาการทำงานได้ด้วยค่ะ วิธีการแก้ไขขึ้นอยู่กับความเหมาะสมของระบบด้วยนะคะ

และถ้าต้องการดูข้อมูลเพิ่มเติมว่า ณ เวลานั้นมี Statement ไหนกำลัง Running อยู่ใน Database สามารถใช้ Query ต่อไปนี้ เพื่อตรวจสอบ SQL Statement ที่ Running ณ เวลานั้น ได้เลยค่ะ

select a.sid,a.serial#,a.username,a.sql_id,a.sql_child_number,optimizer_mode,hash_value,address,sql_text

from v$sqlarea sqlarea ,v$session a

where a.sql_hash_value = sqlarea.hash_value

and a.sql_address = sqlarea.address

and a.username is not null;

ผลที่ได้ก็จะเห็นว่า มี SID อะไร กำลัง Execute Statement อะไรอยู่ และเรายังสามารถนำ SQL_ID ของ Statement นั้นไปดู Plan และ Cost ของ Statement ได้อีกด้วยค่ะ

4. Monitoring SQL Plan

วิธีการ ดู Cost ของ Statement สามารถทำได้ โดยการระบุ SQL_ID ซึ่งได้มาจากการ Monitor Session ดังนี้ค่ะ

SELECT * FROM table(DBMS_XPLAN.DISPLAY_CURSOR(‘SQL_ID’,0));

จากตัวอย่าง ต้องการดู Plan และ Cost ของ Statement ‘select * from test_data;’ จะใช้คำสั่งนี้ค่ะ

SELECT * FROM table(DBMS_XPLAN.DISPLAY_CURSOR(‘fwmbhr3bckpsa’,0));

จากรูปจะเห็น ว่า การ select * นี้ใช้วิธี Table Access Full Scan ไม่ผ่าน Index ไปที่ Table ชื่อว่า TEST_DATA พร้อมทั้งบอกจำนวน Row ที่ Select ได้และ Size ของ Data ที่ Select มาค่ะ โดยจะมีค่า Cost และ % ของการใช้งาน CPU ให้เห็นค่ะ

ตัวอย่าง Statement ที่ใช้งานจริงก็จะเห็น Plan ประมาณนี้ค่ะ ตัวอย่างด้านล่างนี้จะเห็นได้ว่ามี Condition ที่ใช้ Cost และเวลาสูง เป็นช่วงๆ ซึ่งผลให้ Elapsed time ของ Statement นี้ใช้เวลานาน

และเมื่อได้ทำการ Tuning ไปนั้นทำให้ Statement นั้นมี Plan ที่เปลี่ยนไปและใช้ เวลาและ Cost ลดลงอย่างเห็นได้ชัดค่ะ

จะเห็นได้ว่าการดู SQL Plan เป็นการช่วยให้เราเห็นว่า ที่ Condition ส่วนไหนของ Statement ที่ใช้เวลาและ Cost มาก เพื่อเป็นแนวทางในการ Tuning statement ค่ะ

และจาก 4 หัวข้อที่ผ่านมา ก็เป็นเพียงขั้นตอน “เบื้องต้น” เท่านั้น ของการตรวจสอบการทำงานของระบบค่ะ หากจะ Monitor และแก้ปัญหาอย่างจริงจัง เราจะต้องใช้ข้อมูลส่วนอื่นๆ มาประกอบการวิเคราะห์และตัดสินใจ ทั้งในฝั่ง Application, Network, และ OS ค่ะ

ซึ่งการแก้ปัญหาด้วยการ Tuning SQL Statement ก็อาจจะไม่ได้ผล 100% เสมอไปค่ะ ยังมีการปรับแก้ที่ Configuration หรือโครงสร้างการเก็บข้อมูลอีกด้วย ที่จะช่วยให้ Performance ของระบบดีขึ้น ทางที่ดี เราควรติดต่อผู้เชี่ยวชาญด้าน Database มาช่วยตรวจสอบ วิเคราะห์ปัญหากันค่ะ

❤-❤-❤-❤-❤-❤-❤-❤-❤-❤-❤-❤-❤-❤-❤-❤-❤-❤-❤-❤-❤-❤-❤-❤-❤-❤

ช่วงงง… ขายของแบบไม่เนียน ต้องไปเรียนมาใหม่

สำหรับผู้ที่สนใจติดต่อทีมงาน DBA ( Database Administrator) ไปช่วยตรวจสอบปัญหา หรือช่วยดูแลระบบ Database ขององค์กร หรือต้องการย้ายระบบ ก็สามารถติดต่อมาที่ Sirisoft ได้นะคะ ทางเรามีทีมงาน DBA ที่พร้อมให้บริการด้าน Database Oracle และ MSSQL เสมอค่ะ

และสำหรับใคร ที่กำลังมองหา Tool ในการ Monitor Server อยู่นะคะ หน่องเตยอยากแนะนำ Tool ชื่อว่า Dynatrace ค่ะ เจ้า Tool นี้เป็นตัวช่วยให้เราแก้ปัญหาได้ตรงจุดมากยิ่งขึ้นและช่วยลดเวลาในการตรวจสอบของปัญหาว่าสาเหตุเกิดมาจากที่ไหน สามารถเห็นเส้นทางการทำงานของ Application ตั้งแต่การคลิกจาก Client มาเลย น่าสนใจใช่มั้ยคะ ไปลองอ่านทำความเข้าใจเจ้า Tool ตัวนี้กันได้ที่ Blog What is dynatrace? ได้เลยค่ะ และหากสนใจสามารถสอบถามมาได้ที่ ทีมงาน Sirisoft เลยค่ะ

สุดท้ายนี้ ขอขอบคุณทุกท่านที่อ่านมาจนจบนะคะ หน่องเตยหวังว่า ทุกท่านที่แวะเวียนเข้ามาจะได้ความรู้ หรือความเข้าใจในการตรวจสอบการทำงานของระบบ Database กันมากขึ้นนะคะ แล้วพบกันใหม่ โอกาสหน้า จะมีเรื่องดี๊ดีย์ อะไรมาแชร์กันอีก กดติดตามกันไว้นะคะ ❤

Basic Database Performance Monitoring ฉบับออกรบด้วยมือเปล่า* was originally published in Sirisoft on Medium, where people are continuing the conversation by highlighting and responding to this story.

สวัสดีค่ะ กลับมาพับกบ เอ้ยยย พบกับ!! หน่องเตยยยกันอีกแล้วนะคะ (กล้าเล่นนนน ) มารอบนี้เจอกันในวันฝนพรำ อย่าลืมดูแลสุขภาพกันด้วยนะคะ เข้าเรื่องกันเลยดีกว่า >o<”

จาก blog คราวก่อน หน่องได้แนะนำวิธีการสร้าง Database แบบ Automation โดยการสั่งผ่าน Jenkins วันนี้หน่องจะมาแนะนำวิธี Backup Oracle Database แบบง่ายเวอร์จนต้องเอามือทาบอกกันเลยทีเดียวค่ะ

รู้มั้ยคะ ว่าการ Backup Database มีความสำคัญยังไง?? แล้วทำไมเราถึงต้องมี Backup Database เก็บไว้ มาค่ะ… เดี๋ยวหน่องเตยจะเล่าให้ฟังแบบเข้าใจง๊ายยยง่ายยยยย

การ Backup Oracle Database เป็นการสำรองข้อมูลภายใน Database มาเก็บไว้ในรูปแบบของไฟล์นาม .bkp ซึ่งไฟล์ .bkp นี้จะสามารถนำกลับไป Restore ลง Database ทั้ง Database ตัวเดิม หรือ Database ตัวใหม่ เพื่อให้ได้ข้อมูลชุดเดิม ณ วันเวลาที่ทำการ Backup ไว้ ซึ่งวิธีการนี้เป็นหนึ่งวิธีที่ถูกใช้กันอย่างแพร่หลาย ในการสำรองข้อมูลค่ะ

การ Backup Oracle Database มี 2 แบบดังนี้ค่ะ

1. Hot Backup

เป็นการ Backup Database ในขณะที่ Database เปิดอยู่ใน State Open (Database ยัง Online และสามารถใช้งานได้ปกติค่ะ) การ Backup แบบนี้ได้จะต้อง Set Archivelog Mode ให้กับ Database เพื่อสำรอง Online Redo log ของ Database ออกมาเป็น Archive log เมื่อนำไฟล์ Backup ไป Restore จะสามารถนำ Archive log มา Restore ต่อเพิ่มได้ ทำให้ได้ข้อมูลถึงปัจจุบัน

ข้อดีคือ ไม่ต้องมี Downtime ให้กับ Database และข้อมูลที่ Restore ได้สามารถต่อได้ถึงปัจจุบัน หรือที่เรียกกันว่า Point In Time Recovery

ข้อเสียคือ ต้องมีการแบ่งพื้นที่เรียกว่า Fast Recovery Area (FRA) ไว้สำหรับเก็บไฟล์ Archive log ที่จะมีเพิ่มขึ้นตามจำนวนการใช้งานของ Database

2. Cold Backup

เป็นการ Backup Database ในขณะที่ Database เปิดอยู่ใน State Mount (ง่ายๆ คือเป็น state ที่จะไม่มี transaction เข้า Database ค่ะเหมือนปิดการใช้งาน Database เลยล่ะ) การ Backup แบบนี้จะได้ข้อมูลเท่ากับ ณ เวลาที่เริ่ม Backup เมื่อไป Restore ก็จะได้ข้อมูลคืนกลับมาแค่ ณ เวลาที่ Backup นั้นบันทึกมาค่ะ

ข้อดีคือ ไม่ต้องใช้พื้นที่ Disk เพื่อเก็บ log

ข้อเสียคือ มี Downtime ในขณะที่ทำการ Backup และข้อมูลที่ได้จากก้อน Backup จะไม่เป็นปัจจุบัน

หลายคนอ่านมาถึงตรงนี้อาจมีคำถามใช่มั้ยคะ ว่าแล้วแบบนี้เราจะเลือก Backup Database แบบไหนดีนะ ??

คำตอบก็คือ เราต้องดูลักษณะการใช้งานของ Database กันค่ะ ซึ่งโดยปกติ Database ที่ถูก Promote เป็น Production แล้วไม่ควรจะมี Downtime

ดังนั้น วิธีที่หน่องเตยแนะนำคือ การ Backup Database แบบ Hot Backup นะคะ ส่วนใครที่กำลังกังวลเรื่องมีพื้นที่ Disk จำกัดจะเก็บ Archive log พอได้ยังไง ไม่ต้องกังวลไปค่ะ เราสามารถตั้ง Job Schedule ในการ Purge Archive log เราที่ไม่จำเป็นสำหรับใช้ในการ Restore แล้วออกเพื่อคืนพื้นที่ให้กับระบบได้ค่ะ

มาเริ่มกันที่ การฝาก Script Backup ให้ Jenkins ช่วย Run กันค่ะ โดยปกติการ Backup Oracle Database สามารถทำได้ทั้งแบบ

* แบบ Manual โดยการ Connect ไปที่เครื่อง Oracle Database server และใช้ tool Recovery Manager (RMAN) เพื่อพิมพ์คำสั่ง Backup โดยตรง

* แบบ Shell Script เป็นการเขียน Script เพื่อสั่ง Backup โดยใช้การ Execute ไฟล์ Shell Script เป็นรายครั้งที่ต้องการ Backup หรือเป็นการใช้ Cron Schedule

การใช้ Cron Schedule ก็นับว่าเป็นการใช้ Script แบบ Automation ในการ Backup Database ค่ะ แต่เนื่องจากบางระบบมีการจำกัดสิทธิ์การเข้าใช้งาน Cron Schedule วันนี้หน่องเตยเลยจะมาแนะนำการตั้ง Schedule Job ในการ Backup Database ผ่าน Tool Jenkins ค่ะ ง่ายจนตกใจกันไปเลยยย ก่อนอื่น หน่องเตยขออนุญาตอธิบายคำสั่ง Backup ที่ใส่ลงไปใน Script ก่อนค่ะ

คำสั่งใน Script ประกอบไปด้วย 4 ส่วนค่ะ

1. การ Set ตัวแปรและ Environment Database

จะ set เหมือนกันทั้งใน Script Backup Full และ Script Backup Archive

#/bin/bash

export ORACLE_BASE=/u01/app/oracle

export ORACLE_HOME=/u01/app/oracle/product/18.0.0/dbhome_1

export ORACLE_SID=jellybear18

export PATH=/u01/app/oracle/product/18.0.0/dbhome_1/bin:/usr/sbin:/usr/local/bin:/usr/local/bin:/bin:/usr/bin:/usr/local/sbin:/usr/sbin:/home/oracle/.local/bin:/home/oracle/bin

g_date=`date +%d%b%Y`

คำอธิบาย Script

ORACLE_BASE : ตัวแปรสำหรับเก็บ path ไปถึง Oracle Software

ORACLE_HOME : ตัวแปรสำหรับเก็บ path ไปถึง Oracle Home

ORACLE_SID : ตัวแปรเก็บชื่อ Database System ID (ชื่อ Database Instance)

PATH : ตัวแปรเก็บ Path ของ Directory ทำให้เราสามารถ Executed Directly นั้นใน Shell ได้โดยไม่ต้องใส่ Full Path

g_date : ตัวแปรเก็บค่าวันที่ ใช้ในการนำไปตั้งชื่อไฟล์เพื่อไม่ให้ไฟล์มีชื่อ ซ้ำกัน

2. การสร้าง Path เก็บข้อมูลไฟล์ Backup และ Log ของการ Backup

จะ Set เหมือนหรือต่างกันก็ได้ค่ะ ตาม Path ที่ต้องการให้ไฟล์ Backup ไปลงเลย ในตัวอย่างนี้หน่องเตยตั้งไว้ไม่เหมือนกันค่ะ

ตั้งค่า Path เก็บ Backup Full และ Log Backup Full ของการ Backup

mkdir -p /home/oracle/backupdb/$g_date

g_logfile=/home/oracle/backupdb/$g_date/backup_log_`date +%d%b%Y`.log

ตั้งค่า Path เก็บ Backup Archive และ Log Backup Archive ของการ Backup

mkdir -p /home/oracle/backuparch/$g_date

g_logfile=/home/oracle/backuparch/$g_date/backup_arch_log_`date +%d%b%Y`.log

คำอธิบาย Script

mkdir -p : เป็นคำสั่งบน Os สำหรับการสร้าง Folder แบบ Full Path

g_logfile : ตัวแปรเก็บค่าชื่อไฟล์ Log Backup และต่อด้วยค่าวันที่เพื่อไม่ให้ไฟล์มีชื่อ ซ้ำกัน

3. การเข้าสู่ RMAN Mode และ Synchronize Physical Backup File บน Disk กับ Logical Records ใน RMAN Repository เพื่อเตรียม Backup Database

$ORACLE_HOME/bin/rman target=/ >$g_logfile 2>>$g_logfile <<EOF

crosscheck backupset;

คำอธิบาย Script

$ORACLE_HOME/bin/rman target : เป็นคำสั่งเข้าสู่ RMAN Mode โดยเข้าแบบ Full Path จากตัวแปร ORACLE_HOME เข้าไปถึง Utility RMAN

crosscheck : เป็นคำสั่งสำหรับตรวจสอบ Backup File บน Disk กับ Logical Record ของ RMAN ว่าไฟล์จริงยังมีตรงกันกับใน List File logical หรือไม่

4. การ Backup Database เป็นส่วนสำคัญเลยค่ะ เราจะรวบรวมคำสั่งที่ต้องการทำตาม Sequence ของคำสั่ง

4.1 การ Backup Database

run {

sql ‘alter system archive log current’;

backup as backupset device type disk tag ‘FULLBACKUP’ database format ‘/home/oracle/backupdb/$g_date/data_%T_%U.bkp’;

backup spfile tag ‘SPFILE’ format ‘/home/oracle/backupdb/$g_date/spfile_%T_%U.bkp’;

backup current controlfile format ‘/home/oracle/backupdb/$g_date/ctlfile_%T_%U.bkp’;

}

คำอธิบาย Script

sql ‘alter system archive log current’ : คำสั่ง Switch Log File ก่อนการ Backup

backup as backupset : คำสั่ง Backup Database แบบ backupset

backup spfile : คำสั่ง Backup Server Parameter File

backup current controlfile : คำสั่ง Backup Control File

4.2 การ Backup Archive log

run {

sql ‘alter system archive log current’;

backup archivelog from time ‘sysdate-3’ until time ‘sysdate’ tag ‘LAST3DAYS_ARC’ format ‘/home/oracle/backuparch/$g_date/arc_%h_%T_%U.bkp’;

}

allocate channel for maintenance type disk;

delete noprompt backup of archivelog until time ‘sysdate-14’;

release channel;

คำอธิบาย Script

sql ‘alter system archive log current’ : คำสั่ง Switch Log File ก่อนการ Backup

backup archivelog : คำสั่ง Backup Archive Log ย้อนหลัง 3 วันจากเวลาปัจจุบัน (sysdate)

allocate channel for maintenance type disk : เป็นคำสั่งจอง Channel เฉพาะสำหรับให้ RMAN ต่อไปหา Database โดยตรง

delete noprompt backup of archivelog until time ‘sysdate-14’ : เป็นคำสั่งลบ Archive ที่เกินกว่า 14 วันออก (sysdate-14)

release channel; : เป็นคำสั่งคืน resource ที่จองเป็น Channel

เมื่อเตรียม Script Backup Database และ Script Backup Archive เรียบร้อยแล้ว
ก็สร้างไฟล์ Script ไว้ที่เครื่อง Database Server เลยค่ะ โดยใช้คำสั่ง

$ vi bkup_db.sh

เพื่อสร้างไฟล์ชื่อว่า bkup_db.sh

นำคำสั่ง Backup Database ใส่ไฟล์ และ Save File

$ chmod u+x bkup_db.sh

เพื่อเพิ่มสิทธิ์การ Execute File bkup_db.sh

ทำเช่นเดียวกันกับ Script bkup_arch.sh โดยใส่เป็นคำสั่ง Backup Archive log

เมื่อสร้าง Script เรียบร้อย ก็ไปตั้ง Schedule การ Backup File ที่ Jenkins กันเลยค่ะ

สำหรับคนที่ยังไม่รู้วิธีการติดตั้ง Jenkins สามารถไปอ่านข้อมูลเพิ่มเติมจาก Blog ก่อนหน้าของหน่องเตยได้เลยน้า จิ้มตรงนี้เล้ยยย

ต่อจาก Blog ที่แปะ Link ไว้ข้างบนนี้นะคะ เราก็จะสร้าง Project ขึ้นมาเป็น แบบ Freestyle project

จากนั้นไปที่ส่วนของ Build แบบ Execute Shell และใส่คำสั่งในการเรียก Script Backup Database ที่เรานำไปวางไว้บนเครื่อง Database Server

echo welcome1 | su oracle bash -c ‘sh /home/oracle/backupdb/bkup_db.sh’

จากนั้นไปที่ส่วน Build Triggers เลือก CheckBox > Build Periodically เป็นส่วนในการตั้ง Schedule เพื่อให้ Jenkins Execute Script Backup Database

สามารถคลิกเครื่องหมาย คำถามทางขวามือเพื่ออ่านข้อมูลเพิ่มเติมในการตั้งเวลา

จากตัวอย่างเป็นการทดสอบตั้งเวลาให้ Execute Script Backup Database เวลา 03:50 ทุกวัน

เมื่อกด Save ก็รอเลยจ้า เมื่อครบเวลาที่ตั้งไว้ Jenkins จะเริ่มทำงาน Execute Script Backup Database แบบอัตโนมัติเลยค่ะ มาดูกันนนนน

สามารถกดเข้าไปดู Console ของ job ที่กำลัง Run ได้ด้วยน้าา

Job Backup เริ่ม Running แล้ววววว

หลังจากที่ Job ทำงานเสร็จเรียบร้อยแล้วก็ไปตรวจสอบไฟล์ Backup ที่ Path ที่เราตั้งไว้ใน Script กันค่ะ จะเห็นไฟล์ .bkp แบบในรูปเล้ยยย

เช่นเดียวกันกับ Script Backup Archive log ค่ะ สร้าง Project ขึ้นมาเป็น แบบ Freestyle project

ที่ส่วนของ Build แบบ Execute Shell ใส่คำสั่งในการเรียก Script Backup Archive log ที่เรานำไปวางไว้บนเครื่อง Database Server

echo welcome1 | su oracle bash -c ‘sh /home/oracle/backuparch/bkup_arch.sh’

ที่ส่วน Build Triggers เลือก CheckBox > Build Periodically ก็เหมือนเดิมเลยค่ะ โดยจะตั้ง Schedule เพื่อให้ Jenkins Execute Script Backup Archive log

จากตัวอย่างเป็นการทดสอบตั้งเวลาให้ Execute Script Backup Database เวลา 04:05 ทุกวัน เมื่อครบเวลาที่ตั้งไว้ Jenkins จะเริ่มทำงาน Execute Script Backup Archive log แบบอัตโนมัติ

จะเห็นว่าพอถึงเวลา 04:05 Job จะเริ่ม exceute ไหนนนน ตามไปดูที่ Database ซิ

ชอบจัง เวลาเห็นคำว่า Running เนี่ยยยยยย >0<

หลังจากที่ Backup Archive log completed แล้วก็ไปเช็คไฟล์ Backup กันซักหน่อย

File Backup Archive log มาแล้วจ้าาา

เห็นมั้ยคะ แค่สั่งผ่าน Jenkins แค่ 2 บรรทัดก็สามารถมี Job Backup Auto Runing ได้สบายเลย ไม่ต้องกังวลเรื่องข้อมูลสูญหาย มี backup ข้อมูลเอาไว้ก็จะอุ่นใจหน่อยๆ แต่ถ้าอยากอุ่นกายก็ใส่เสื้อกันหนาวเอานะคะ แฮร่!!

จาก File Backup Full และ Backup Archive log ที่ได้มา สามารถนำไป ใช้ Restore Database ตัวเดิมเพื่อกู้คืนข้อมูล หรือนำไป Restore ลง Database ตัวใหม่เพื่อทำเป็น environement ใหม่ที่มี Data เหมือนกันได้ค่ะ เช่นทำเครื่องเอาไว้ test โดยจำลองข้อมูลและ configuration ให้เหมือนกับ Production ที่ Backup มา

สำหรับ Blog นี้ถึงจะดู simple นิดหน่อย แต่ก็หวังว่าจะเพิ่มข้อมูลความรู้เกี่ยวกับการสำรองข้อมูลให้กับผู้อ่านได้ ไม่มากก็น้อย ไว้กลับมาพบกันใหม่ใน Blog หน้านะคะ จะเป็นเรื่องอะไร มารอลุ้นกันค่ะ สวัสดีค่ะ :3

Backup Oracle Scheduling by Jenkins was originally published in Sirisoft on Medium, where people are continuing the conversation by highlighting and responding to this story.

สวัสดีค่ะทุกคน กลับมาพบกันอีกแล้วนะคะ ยังจำหน่องเตยได้อยู่มั้ยน้า… หน่องเตยมาเขียน Blog แบบนี้ แสดงว่ามีอะไรดีๆ มานำเสนอนะจ๊ะ อิอิ :p

หลายๆ คนคงรู้จัก DevOps CI/CD (Continuous Integration และ Continuous Delivery/Deployment) กันใช่มั้ยคะ

DevOps เป็น Culture การทำงานที่มีหัวใจสำคัญ คือ ความสะดวกและรวดเร็วในการ Development, Test และการ Deployment ด้วยวิธีการแบบ Automation ซึ่งจะมีประโยชน์มากในการทำงานที่ต้องมีการทดสอบ แก้ไข และ release product version ใหม่อยู่บ่อยครั้ง

แต่เนื่องจากหน่องเตยเป็นสาย DBA จึงเลยอยากลองนำ หัวใจดวงน้อยๆของ devOps คือ Automation ของ DevOps มาประยุกต์ใช้กับ Database ดูบ้าง

วันนี้เลยจะขอนำเสนอการทำ Automate Create Oracle Database by Jenkins ค่ะ ชื่อตรงตัวเลย ก็คือ Install Oracle Database 18c Softwareพร้อมทั้ง Create Database แบบพร้อมใช้งานโดยใช้ tool คุณลุง Jenkins นั่นเองค่ะ

เพียงสั่งการไปที่ Jenkins คลิกเดียว ก็สามารถเนรมิต Oracle Database มาให้เราใช้บน OS Linux ได้อย่างง่ายดาย ทันใจ ทันใช้ฝุดๆ ไปเริ่มพร้อมกันที่ละ step เลยค่ะ

มาทำ Prerequisite กันทีละขั้นตอนเลยจ้าาา

# dd if=/dev/zero of=/tmp/newswap bs=8MB count=1024

# mkswap /tmp/newswap

# swapon /tmp/newswap

# free -m

# echo “/tmp/newswap swap swap defaults 0 0” >> /etc/fstab

# vi /etc/hosts

# systemctl stop firewalld

# systemctl disable firewalld

# wget -O /etc/yum.repos.d/jenkins.repo http://pkg.jenkins.io/redhat-stable/jenkins.repo

# rpm — import http://pkg.jenkins.io/redhat-stable/jenkins.io.key

# yum install jenkins -y

# systemctl start jenkins

# cat /var/lib/jenkins/secrets/initialAdminPassword

เมื่อ install plugins เสร็จก็ให้ทุกคน Create user สำหรับทำ operation ต่างๆ ผ่าน Jenkins ค่ะ

ส่วนนี้เป็นการกำหนด URL สำหรับการเข้าถึง Jenkins Management ค่ะ

Jenkins is ready! เย้ เย้

นี่ก็คือหน้าตา Dashboard ของ Jenkins ที่จะเป็นฐานบัญชาการสั่งทำงานแบบ Automation ค่ะ อิ้อิ้

และอย่าลืม install GitHub plugins ให้กับ คุณลุง Jenkins แกด้วยนะคะ เพราะเราจะทำการ clone scripts จาก GitHub มาค่ะ โดยไปที่เมนู Manage Jenkins

เลือก Manage Plugins

เลือกที่ Available tab และ search หา GitHub คราวนี้เตยเลือกแค่ plugin หลักๆ คือ GitHub Pull Request Coverage Status และ GitHub Integration เลือก download now and install after restart จ้าาา

เลื่อนลงมาข้างล่างแล้วเลือก เครื่องหมายถูก ให้ restart Jenkins ด้วยนะคะ เมื่อ download เสร็จก็ให้คลิก go back to the top page

ระหว่างนี้ไป prepare step ถัดไปกันค่ะ

pscp.exe C:\Users\Suphisara\Desktop\oracle_database_18c\LINUX.X64_180000_db_home.zip root@172.20.10.3:/home/

git status

git add .

git status

git commit -m “please work”

git push origin master

login GitHub

Scripts ที่ถูก push ขึ้นไปบน GitHub จ้าาาา

เลือกที่ create new jobs

เลือก freestyle project และตั้งชื่อ ครั้งนี้เตยจะสร้าง Project ไว้ 2 Project นะคะ

1. Automate_Install_SW18c : สำหรับการติดตั้งครั้งแรก โดยคำสั่งภายในจะเป็นการเรียก script เพื่อ install oracle database software และสร้าง database ตัวที่ 1 ชื่อว่า jelly1

โดยเราจะตั้งค่าลำดับการทำงานของ Jenkins ในการเรียก Scripts แต่ละตัวจากส่วนที่เป็น Build แบบ Execute Shell และใส่คำสั่งในการเรียก scripts ดังนี้

#1
#transfer file oracle18c.zip to /home/
#by using cmd
#pscp.exe C:\Users\Suphisara\Desktop\oracle_database_18c\LINUX.X64_180000_db_home.zip root@172.20.10.3:/home/

#put all script into github
#by using git bash
# git status
# git add .
# git status
# git commit -m “please work”
# git push origin master
# login GitHub

#2
#prepare clone script from git

echo P@ssw0rd | su root bash -c ‘mkdir /home/git_scripts’
echo P@ssw0rd | su root bash -c ‘yum install git -y’
echo P@ssw0rd | su root bash -c ‘git clone https://github.com/kulico/automate_install_sw_18c /home/git_scripts’

#3
#prepare environment for oracle

echo P@ssw0rd | su root bash -c ‘sh /home/git_scripts/control_script1.sh’

#4
#Install software 18c

echo welcome1 | su oracle bash -c ‘sh /home/git_scripts/runinstaller.sh’
echo P@ssw0rd | su root bash -c ‘sh /home/git_scripts/control_script2.sh’

#5
#Create database 18c

echo welcome1 | su oracle bash -c ‘sh /home/git_scripts/rundbca.sh’

#6
#listener

echo welcome1 | su oracle bash -c ‘sh /home/oracle/scripts/start_lsnrctl.sh’

echo Database 18c is Ready to use !!

2. Automate_Create_DB : สำหรับการติดตั้งครั้งที่ 2 ขึ้นไป โดยคำสั่งภายในจะเป็นการเรียก script เพื่อสร้าง oracle database โดยจะมีการนับจำนวนครั้งในการสร้างเพื่อนำจำนวนดังกล่าวไปสร้างเป็นชื่อ database เพื่อไม่ให้ชื่อซ้ำกัน โดย database จะมีชื่อว่า jelly[n] ** n แทนตัวเลขจำนวนครั้งที่ counter นับไว้

โดยเราจะตั้งค่าลำดับการทำงานของ Jenkins ในการเรียก Scripts แต่ละตัวจากส่วนที่เป็น Build แบบ Execute Shell และใส่คำสั่งในการเรียก scripts ดังนี้

#Create database 18c

echo welcome1 | su oracle bash -c ‘sh /home/git_scripts/rundbca_generate.sh’

#listener

echo welcome1 | su oracle bash -c ‘sh /home/oracle/scripts/start_lsnrctl.sh’

echo Database 18c is Ready to use !!

NOTE1: Password Oracle คือ welcome1 , Password Root คือ P@ssw0rd
NOTE2: Password SYS , SYSTEM ของ database คือ welcome1
สามารถแก้ไข password หลังจากสร้าง database แล้ว หรือสามารถแก้ไขใน script ก่อน execute Jenkins ค่ะ

เมื่อเราสร้าง Job ไว้ จะเห็น Job อยู่ที่หน้า Dashboard แบบนี้ค่ะ

คลิกเข้าไปใน Job จะเจอปุ่ม Build Now ที่ซ้ายมือ ถ้าต้องการแก้ไขคำสั่ง Execute shell ก็สามารถเข้าไปที่เมนู configure

ตัวอย่างจาก project : Automate_Create_DB

เมื่อสั่ง Build Now แล้วจะเกิด status การทำงานอยู่ที่ช่อง Build History สามารถคลิกเข้าไปดู console ขณะกำลัง Build เพื่อ Monitor การทำงานหากมีความผิดพลาด status จะเป็นสีแดง หากสำเร็จ status จะเป็นสีฟ้า และ status จะเป็นสีเหลือง กรณีที่บางคำสั่งทำงานไม่สมบูรณ์

ภายในหน้า console จะแสดงผลการทำงานเป็น log แบบนี้ค่ะ

เมื่อเสร็จ ก็จะมีคำว่า “Database 18c is Ready to use !!” ตามที่เรากำหนดไว้ใน Execute shell

เมื่อ คุณลุง Jenkins บอกว่าติดตั้งเสร็จแล้ว เราก็ไปลอง Connect Database กันค่ะ

$ ps -ef | grep pmon

$ lsnrctl status

Export ORACLE_SID = jelly[n]

$ sqlplus / as sysdba

sqlplus sys/welcome1@172.20.10.3:1521/jelly[n] as sysdba

เป็นยังไงกันบ้างคะ แค่สั่ง Build Now คลิกเดียว ก็มี Oracle Database พร้อมใช้งานอยู่ในเครื่องเลย

ประโยชน์และลูกเล่นของ Jenkins ยังมีอีกเยอะมากเลยนะคะ สามารถไปลองเล่นกันได้ สำหรับใครที่แวะเข้ามาชม Blog นี้และอยากจะแชร์ความรู้หรือแนะนำวิธีการใช้งาน Jenkins แบบ Advance แสดงความคิดเห็นมาได้เลยนะคะ

DBA ตัวน้อยๆ คนนี้ที่พึ่งหัดใช้ Jenkins เป็น ยินดีรับคำแนะนำเสมอค่ะ แล้วพบกันใหม่ Blog หน้านะคะ สวัสดีค่ะ :3

ติดตั้ง Database แบบ Automation คลิกเดียวรู้เรื่อง!! was originally published in Sirisoft on Medium, where people are continuing the conversation by highlighting and responding to this story.

안녕하세요? อันนยองฮาเซโย ทุกท่านที่หลงเข้ามาใน blog นี้นะคะ วันนี้หน่องเตยมีเรื่องการ Migrate Database to Docker Container มาแชร์ค่ะ

โดยเนื้อหาจะเป็นการประยุกต์ใช้ Oracle Database version 12c กับเทคโนโลยีใหม่ที่ชื่อว่า Docker นั่นเอง โดยการ Migrate Oracle Database ของเราแบบ physical เข้าไป apply ใน docker container เพื่อให้เรามี data เช่น tables, users, privileges ต่างๆ ครบเหมือนยกข้อมูลจาก Production มาไว้สำหรับทดสอบ applications บน docker ด้วยขั้นตอนง่ายๆ เพียง 6 ขั้นตอนเท่านั้นค่ะ

Step 1 Install Docker software

สามารถเข้าไปศึกษา concept การทำงานของ Docker และวิธีการติดตั้ง Docker พร้อมแถมวิธีการสร้าง container ที่มี SQL server ได้ที่ Blog: มารู้จักการใช้งาน Docker บน RedHat กันเถอะ :)เป็น Blog คุณภาพของเพื่อนหน่องเตยค่ะ

Step 2 Create Database Container

สามารถเข้าไปศึกษาการติดตั้ง Oracle Database 12c r2 บน docker ได้ที่ Blog:Install Oracle Database on Docker Container Blog ดีๆ จากพี่ชายใจดีย์ของหน่องเตยเองค่ะ

หลังจากที่ทุกคนรู้จักเจ้า Docker พร้อมทั้งติดตั้งและสร้าง Oracle Database container กันเรียบร้อยแล้ว สามารถตรวจสอบและเข้า container ด้วยคำสั่ง ดังนี้ค่ะ

คำสั่ง start container : docker start <container_name>

คำสั่งดู container ที่กำลัง start อยู่ : docker ps

คำสั่งเข้า container default user(oracle) : docker exec -it <container_name> bash

คำสั่งเข้า container root user : docker exec -it -u 0 <container_name> bash

เมื่อเข้ามาใน container ได้แล้ว ทดลองใช้คำสั่ง sqlplus เพื่อเข้าสู่ SQL* Plus และสามารถใช้คำสั่ง sql ต่างๆ เพื่อจัดการและเรียกดูข้อมูลได้ ตัวอย่างตามรูปค่ะ

คราวนี้เรามาลองสร้าง database ของเราเองนะคะ แต่เนื่องจาก docker container นี้ไม่มีโหมด GUI เราเลยต้องติดตั้ง database silent mode แทนค่ะ

Step 2.1 Create New Database in Container

(แนะนำว่าให้ตั้งชื่อ ORACLE_SID ให้เหมือนกับ database ที่เราจะย้าย Datafiles มานะคะ จะได้ไม่สับสน)

คำสั่งเข้า create database silent mode : dbca -silent -createDatabase -templateName General_Purpose.dbc -gdbName ora12cdb -sid ora12cdb -responseFile NO_VALUE -SysPassword welcome1 -SystemPassword welcome1 -emConfiguration NONE -characterSet AL32UTF8 -memoryPercentage 20

** ขั้นตอนนี้อาจะใช้เวลาสักพัก ขอให้ทุกคนรออย่างใจเย็นนะคะ แอบไปซื้อขนมระหว่างรอก็ได้ค่ะ กลับมาเสร็จพอดี**

เมื่อสร้าง database ตัวใหม่เสร็จแล้ว ลองตรวจสอบ process ด้วยคำสั่ง ps -ef|grep pmon จะเห็น process database ทั้งสองตัวทำงานอยู่ค่ะ ตามรูปเลยยยยย

เมื่อเราจะสลับไปใช้ database ตัวใหม่ต้องใช้คำสั่ง : export ORACLE_SID=ora12cdb ก่อนค่ะ จะสามารถใช้ sqlplus ในการ query ข้อมูลจาก database ตัวใหม่ค่ะ

Step 3 Check Datafiles Path

เราต้องตรวจสอบก่อนว่าเดิม datafiles สำคัญทั้งหมดของ Database ora12cdb เครื่อง Production (เครื่องต้นทาง) อยู่ที่ path ไหนบ้างค่ะ

Step 3.1 Check Datafiles Path on Production

คำสั่งดู path control file : show parameter control_files

คำสั่งดู path data file : select file_name, tablespace_name, bytes from dba_data_files;

คำสั่งดู path redo file : select * from v$logfile;

คำสั่งดู path temp file : select file_name, tablespace_name, bytes from dba_temp_files;

คำสั่งดู path spfile : show parameter spfile

คำสั่งสร้าง pfile : create pfile=’path/pfile.ora’ from spfile=’path/spfile.ora’;

จะสังเกตได้ว่า control file, data file, redo file, temp file อยู่ใน path เดียวกัน มีแค่ control file02 และ pfile ที่อยู่ path อื่นค่ะ หลังจากที่เรารู้ว่า path ของไฟล์ต่างๆ ในเครื่องต้นทางอยู่ที่ไหน ก็ให้ทุกคนนำคำสั่งทั้งหมดนี้ไป ใช้กับ Database ora12cdb ที่ Docker Machine (เครื่องปลายทาง) ใน container ด้วยเช่นกันค่ะ

Step 3.2 Check Datafiles Path on Docker Machine

คำสั่งดู path control file : show parameter control_files

คำสั่งดู path data file : select file_name, tablespace_name, bytes from dba_data_files;

คำสั่งดู path redo file : select * from v$logfile;

คำสั่งดู path temp file : select file_name, tablespace_name, bytes from dba_temp_files;

คำสั่งดู path spfile : show parameter spfile

จะสังเกตได้ว่าเครื่องปลายทาง มี control file02 อยู่ที่เดียวกับ data file, redo file, temp file มีแค่ pfile ที่แยก path ไปนะคะ

Step 4 Copy Datafiles

เมื่อเรามี list ไฟล์สำคัญ และ path เรียบร้อยแล้ว เราจะทำการ copy files ทั้งหมดนี้จากเครื่องต้นทาง ไปยังเครื่องปลายทางกันค่ะ

Step 4.1 Copy Datafiles from Production to Docker Machine

ก่อนอื่นถ้าเครื่องต้นทางมีการใช้งานอยู่ตลอดเวลาแนะนำว่าให้ shutdown database ก่อน copy files ค่ะ (ถ้าเป็น production อาจจะต้องมี downtime สักพักค่ะ)

คำสั่ง shutdown immediate

เพื่อไม่ให้ทุกคนสับสน เราจะย้าย files ทั้งหมดนี้ไปรวมกันที่ folder dbfile ที่เครื่องปลายทางก่อนค่ะ ให้ทุกคนลอง cd เข้าไปตาม path ที่เรา list ไว้นะคะแล้ว copy files

คำสั่ง : scp path_file_on_host1 username@ip-address_host2:path_on_host2

* ถ้าใครงง ให้ดู ของหน่องเตยเป็นตัวอย่างไปเด้อออ เครื่องต้นทาง = host1 เครื่องปลายทาง = host2 ส่วนวิธีการดู IP นั้นใช้คำสั่ง ifconfig -a ค่ะ (OS linux) จะได้ IPhost2 : 192.168.1.159

สำหรับตัวอย่างนี้ จะได้คำสั่ง copy ตามนี้ค่ะ

scp /u01/app/oracle/oradata/ora12cdb/* root@192.168.1.159:/home/caramel/dbfile/

scp /u01/app/oracle/fast_recovery-area/ora12cdb/control02.ctl root@192.168.1.159:/home/caramel/dbfile/

scp /u01/app/oracle/product/12.2.0.1/db_1/dbs/pfile12122017 root@192.168.1.159:/home/caramel/dbfile/

หลังจากย้ายไฟล์ครบทั้งหมดแล้ว อย่าลืมกลับไป start database ต้นทางด้วยนะคะ คำสั่ง startup

มาดูกันค่ะว่า files ที่เรา copy มาที่ปลายทางครบหรือไม่…. คำสั่ง : cd /path_on_host2 และ คำสั่ง : ls -lhrt ทา ดา ~ *0* มากันพร้อมหน้าเชียววว

Step 4.2 Copy Datafiles from Docker Machine to Container

ขั้นตอนนี้ เราจะต้องย้าย files ทั้งหมดนี้เข้าไปใน docker container ก่อนค่ะ โดยใช้คำสั่ง : docker cp path_on_host2 container_name:path_in_container สำหรับตัวอย่างนี้จะได้ คำสั่งนี้ค่ะ docker cp /home/caramel/dbfile/ oracledb:/home/oracle

ลองเข้าไปดูใน container กันค่ะว่าไฟล์เข้าไปหรือยัง ลืมคำสั่งเข้า container กันยังคะ คำสั่ง : docker exec -it <container_name> bash

และ ใช้คำสั่ง : cd path_in_container กับคำสั่ง : ls -lhrt เข้าไปเช็คไฟล์กันเล้ยยยยย (ลุ้นนนนน)

ไฟล์มาครบแล้วค่ะ แต่ทุกคนเห็นเหมือนกันไหมคะว่า ทุกไฟล์มี owner และ group เป็นของ root หมดเลย แต่เราเป็น user oracle group oinstall จะไม่สามารถกระทำการใดๆ กับไฟล์เหล่านี้ได้เลย เพราะฉะนั้นเราต้องเรา container อีก session นึงเป็น user root ค่ะเพื่อ เปลี่ยน owner files เป็น oracle เข้า container เป็น root ด้วย

คำสั่ง : docker exec -it -u 0 <container_name> bash

และใช้คำสั่ง : chown -R oracle:oinstall dbfile/ ลองคำสั่ง : ls -lhrt อีกครั้งจะเห็นว่า owner และ group เปลี่ยนไปแล้วค่ะ กลับไป session แรกกันค่ะ

ตอนนี้เราจะย้ายไฟล์ต่างไปตาม path ของ container ตาม list ที่เราเก็บไว้ตอนแรกค่ะ (อย่าลืม backup files เดิมของ database ตัวนี้ไว้ก่อนด้วยนะคะ) และต้อง shutdown database ora12cdb ก่อนย้ายไฟล์ด้วยนะ

คำสั่ง : shutdown immediate

ส่วนการย้ายไฟล์ก็ง่ายๆค่ะ ใช้คำสั่ง : mv path_in_container path_db_in_container สำหรับตัวอย่างนี้จะได้ คำสั่งนี้ค่ะ mv /home/oracle/dbfile/* /opt/oracle/oradata/ora12cdb/

ทุกไฟล์จะย้ายไปอยู่ที่ /opt/oracle/oradata/ora12cdb/ และจะเห็นไฟล์จะมี pfile ที่ติดมาด้วยและต้องย้ายไปอยู่ที่ path /opt/oracle/product/12.2.0.1/dbhome_1/dbs/ เหมือน spfile เราจะใช้คำสั่ง mv /home/oracle/dbfile/pfile12122017.ora /opt/oracle/oradata/ora12cdb/dbs/

ตามไปดูที่ /opt/oracle/oradata/ora12cdb/dbs/ ไฟล์มาแล้วค่ะ เมื่อไฟล์จากต้นทางไปแทนที่ไฟล์ของปลายทางเรียบร้อยครบทุกไฟล์แล้ว เมื่อเราจะเปิด database ด้วยไฟล์ใหม่เหล่านี้ หน่องเตยขออธิบายคร่าวๆให้เข้าใจตรงกันก่อนค่ะว่า การ startup database เริ่มจากไฟล์ไหนบ้างที่เราพึ่ง copy มา

โดย database มี 4 states คือ shutdown, no mount, mount, open

1. State Shutdown จะหยุดการทำงานและไม่สามารถเรียกดูข้อมูลใน database ได้

2. State Nomount จะอ่านจาก init file (pfile) หรือ spfile โดยใน pfile จะเป็นตัวชี้ไปที่ control file ทำให้ไปยัง State Mount ต่อไปได้

3. State Mount ที่จะอ่าน control file โดยใน control file จะชี้ไปยัง data file, redo file, temp file ที่เป็นข้อมูลข้อ Database นั้นๆ จึงไปยัง state open ได้

4. State Open สามารถ query ข้อมูลได้เนื่องจาก database สามารถอ่านไฟล์ได้ทั้งหมด ดังนั้นไป ตรวจสอบความถูกต้องของไฟล์ที่จะถูกอ่านในแต่ละ state กันค่ะ

Step 5 Startup Database Step by Step

โดย state NOMOUNT ต้องอ่านข้อมูลจาก spfile/init file (pfile) ใช้คำสั่ง cd ไปที่ path pfile แล้วใช้คำสั่ง cat pfile12122017.ora

จะเห็นว่ามีข้อมูลหลายอย่างในนี้ที่ยังเป็น ข้อมูลอ้างอิงจาก database ต้นทางเช่น path ของ control file เราจะต้องทำการแก้ไข ให้ถูกต้องเพื่อ pfile จะได้ชี้ไปอ่าน control file ใน state ถัดไป แต่เนื่องจากไม่สามารถใช้คำสั่ง vi ในการแก้ไขไฟล์ได้จึงใช้ cat << EOF > แทน ให้ทุกคน copy ข้อมูลในไฟล์ที่ cat pfile12122017.ora แสดงผลไว้ มาแก้ไขข้างนอกอาจจะวางใน notepad แล้วแก้

จากนั้นใช้คำสั่ง : cat << EOF > แล้ววางข้อมูลที่เราแก้ไขไปทั้งหมด ตามด้วย EOF

ลองใช้คำสั่ง cat pfile12122017.ora อีกครั้งจะเห็นว่าข้อมูลในไฟล์เปลี่ยนไปเรียบร้อยแล้ว คราวนี้เราก็สามารถเปิด database ที่ state nomount ได้แล้วค่ะ โดยเข้า sqlplus ใช้คำสั่ง : startup nomount

และใช้คำสั่ง : select status from v$instance; เพื่อตรวจสอบ state ของ database ซึ่ง no mount คือ START แบบในรูปค่ะ

เมื่อเข้า state nomount ได้ เราจะไป state ถัดไปคือ mount ค่ะ โดยใช้คำสั่ง : alter database mount;

state MOUNT

เมื่อเข้า state mount ได้ แสดงว่า pfile ชี้มาที่ control file path ที่ถูกต้อง ซึ่งใน control file นี้เป็นของ database ต้นทาง ซึ่งภายในจะเก็บข้อมูล file ต่างๆ ตาม path ในเครื่องต้น ทางเราต้องทำการ rename เพื่อเปลี่ยน path ให้ control file ชี้ไปที่ datafile ตาม path ปัจจุบันใน container โดยใช้คำสั่ง : alter database rename file ‘ path_file_on_host1_filename’ to ‘ path_db_in_container ‘;

สำหรับตัวอย่างนี้ จะได้คำสั่งตามนี้ค่ะ

alter database rename file ‘/u01/app/oracle/fast_recovery_area/ora12cdb/control02.ctl’ to ‘/opt/oracle/oradata/ora12cdb/control02.ctl’;

alter database rename file ‘/u01/app/oracle/oradata/ora12cdb/users01.dbf’ to ‘/opt/oracle/oradata/ora12cdb/users01.dbf’;

alter database rename file ‘/u01/app/oracle/oradata/ora12cdb/undotbs01.dbf’ to ‘/opt/oracle/oradata/ora12cdb/undotbs01.dbf’;

alter database rename file ‘/u01/app/oracle/oradata/ora12cdb/system01.dbf’ to ‘/opt/oracle/oradata/ora12cdb/system01.dbf’;

alter database rename file ‘/u01/app/oracle/oradata/ora12cdb/sysaux01.dbf’ to ‘/opt/oracle/oradata/ora12cdb/sysaux01.dbf’;

alter database rename file ‘/u01/app/oracle/oradata/ora12cdb/ts_test01.dbf’ to ‘/opt/oracle/oradata/ora12cdb/ts_test01.dbf’;

alter database rename file ‘/u01/app/oracle/oradata/ora12cdb/ts_test02.dbf’ to ‘/opt/oracle/oradata/ora12cdb/ts_test02.dbf’;

alter database rename file ‘/u01/app/oracle/oradata/ora12cdb/temp01.dbf’ to ‘/opt/oracle/oradata/ora12cdb/temp01.dbf’;

alter database rename file ‘/u01/app/oracle/oradata/ora12cdb/redo03.log’ to ‘/opt/oracle/oradata/ora12cdb/redo03.log’;

alter database rename file ‘/u01/app/oracle/oradata/ora12cdb/redo02.log’ to ‘/opt/oracle/oradata/ora12cdb/redo02.log’;

alter database rename file ‘/u01/app/oracle/oradata/ora12cdb/redo01.log’ to ‘/opt/oracle/oradata/ora12cdb/redo01.log’;

เมื่อเปลี่ยน path file ใน control s ครบแล้ว จะไป state ถัดไปคือ open โดยจะใช้คำสั่ง : alter database open; แล้วลอง เช็ค state database กันค่ะ

state OPEN

ทา ดา ~ เห็นแบบนี้ค่อยชื่นใจหน่อย ในที่สุดเราก็สามารถวาร์ป database มาไว้บน docker ได้สำเร็จ มาลอง select ข้อมูลจาก table ที่เราย้ายมากันค่ะ

เย้~ ตอนนี้ทุกคนก็มี database บน docker container ที่สามารถใช้ข้อมูลจริงของเราในการทดสอบ applications ต่างๆ ผ่าน docker กันเรียบร้อยแล้วนะคะ แต่!! อย่าพึ่งรีบปิดหนีกันไปไหนนะคะ หน่องเตยมี ทริปการ connect database แบบ GG EZ มาฝากค่ะ

step 6 Test Database Connection

โดยการ connect เข้า database แบบง่ายๆ command เดียว ก็ select ข้อมูลได้เลยนั้นทำไม่ยากค่ะ ให้ทุกคน ใช้คำสั่ง : cd $ORACLE_HOME/network/admin/ และลอง คำสั่ง : ls -lhrt ดู จะเจอไฟล์ชื่อว่า tnsname.ora เมื่อเราใช้คำสั่ง : cat tnsames.ora จะเห็นว่าในไฟล์นี้มีแค่ข้อมูล connection ของ database ชื่อว่า oracledb

ให้ทุกคน copy ข้อมูลนี้ออกมา และเปลี่ยนชื่อ เป็นชื่อ database ของเรา สำหรับตัวอย่างนี้ จะเปลี่ยนจาก oracledb เป็น ora12cdb ค่ะ แล้วใช้คำสั่ง cat << EOF >> tnsname.ora เพื่อเพิ่มชุดข้อมูลนี้ต่อท้ายจากข้อมูลของ oracledb เดิมในไฟล์ค่ะ

แล้วลองใช้คำสั่ง cat tnsname.ora เพื่อดูว่าข้อมูลเพิ่มเข้าไปในไฟล์หรือไม่

หลังจากนี้ให้ทุกคน exit ออกมาจาก container มาอยู่ใน เครื่อง host ด้วย user root นะคะ แล้วใช้คำสั่ง : cat /etc/hosts เพื่อดูว่ามีการกำหนด ชื่อ host และ เลข IP ของเครื่อง host ไว้หรือไม่ จากในรูปยังไม่มี IP ของเครื่องเราค่ะ

เราจะใช้คำสั่ง : vi /etc/hosts เพื่อ insert 192.168.1.159 Caremel เพิ่มไป จะได้ตามนี้ค่ะ

แล้วบันทึกไฟล์ ด้วยการพิมพ์ :wq

ตอนนี้เราก็มาเริ่ม connect database แบบ Easy สุดๆ กันด้วยคำสั่งเหล่านี้เลยค่ะ

คำสั่ง : docker exec -it oracledb sqlplus system/welcome1@ora12cdb ด้วยชื่อ database

คำสั่ง : docker exec -it oracledb sqlplus system/welcome1@0.0.0.0:1521/ora12cdb ด้วย localhost:port

คำสั่ง : docker exec -it oracledb sqlplus system/welcome1@0.0.0.0:1521/ora12cdb ด้วย container IP:port

คำสั่ง : sqlplus system/welcome1@192.168.1.159:1521/ora12cdb ด้วย command prompt จากเครื่องอื่น ผ่าน IP host ที่ติดตั้ง docker database ไว้ค่ะ

เป็นยังไงกันบ้างคะทุกคน หน่องเตยหวังว่า Blog นี้จะให้ความรู้กับทุกคนที่แวะมาเยี่ยมชมกันไม่มากก็น้อยเนอะ ส่วนใครมีคำแนะนำ ข้อเสนอแนะอะไร สามารถ comment ไว้ได้นะคะ ยินดีน้อมรับทุกคำติชมมาปรับปรุงค่ะ แล้วพบกันใหม่ Blog หน้า จะเป็นเรื่องเกี่ยวกับอะไรนั้น มาลุ้นกันเด้อออ

ช่วงขายของส่งท้าย ใครที่สนใจอยากรู้เรื่องการจัดการ docker cluster ด้วย kubernetes สามารถเข้าไปศึกษาต่อได้ที่ Blog: Getting Start … with Kubernetes ! Blog คุณภาพของ เจ้เบน ชุมชนบางซื่อส่งเข้าประกวดได้เลยค่ะ (แซว)

또 만납시다. โต มันนับชีดา แล้วพบกันใหม่นะคะ ฝากไลค์ ฝากแชร์ กันด้วยเด้ออออออออ จุ้บบบ :3

Migrate Database to Docker Container ง่ายเวอร์ มาดูกันนน :D was originally published in Sirisoft on Medium, where people are continuing the conversation by highlighting and responding to this story.