2019年9月30日 (月)

なぜ、そこに、LONG型があるんだ / FAQ

all/dba/user_tab_columns

https://docs.oracle.com/cd/E82638_01/refrn/ALL_TAB_COLUMNS.html#GUID-F218205C-7D76-4A83-8691-BFD2AD372B63

これらのビューは、列の属性関連の情報を持つビューです。
たまに、便利なびゅーではあるのですが、これらのビューをアクセスする使うスクリプトというかPL/SQLでコード書くこともあるのですが、一箇所だけ、使いにくいところがあります。

 

どこかわかります?

続きを読む "なぜ、そこに、LONG型があるんだ / FAQ"

| | コメント (0)

2019年8月25日 (日)

FAQ / PL/SQL PACKAGEでパプリックスコープを持つ定数をSQL文中で利用するには...

かなーり、ご無沙汰しておりました。(本業でいっぱいいっぱいで、という言い訳はこれぐらいにしてw) 偶に聞かれることがあるので、FAQネタから。 パッケージでパブリックなスコープを持つ定数は無名PL/SQLブロックやパッケージ、プロシージャ、ファンクションでしか参照できないんですよねー 例えば、DBMS_CRYPTOパッケージでHASHファンクションを利用してSH-256を作成したいなーと思って、

39.4 DBMS_CRYPTOのアルゴリズム
https://docs.oracle.com/cd/F19136_01/arpls/DBMS_CRYPTO.html#GUID-CE3CF17D-E781-47CB-AEE7-19A9B2BCD3EC

続きを読む "FAQ / PL/SQL PACKAGEでパプリックスコープを持つ定数をSQL文中で利用するには..."

| | コメント (0)

2019年3月25日 (月)

Temp落ち #10 - パーティションワイズジョインはどうよ

Temp落ちシリーズ、久々ですが、今回は、そもそもメモリーに乗り切らないなら、一時表領域に落ちる量をなんとかできないのか。。。というおはなし

pgaとして利用できるメモリーサイズには限界もありますし、その範囲のデータサイズで、ずーーーーーつと収まっていてくれていればいいですが、そうじゃない状況のほうが圧倒的に多いのではないでしょうか。
であれば、オンメモリーで処理させようなんて考えずに、ある程度落ちることは仕方ないと諦め、一時表領域の利用サイズを減らせないか。。。その方法の一つがパーティションワイズジョイン
ただし、パーティションを利用するので、Enterprise Editionでしか使えません。それ以外の場合は。。。別の手を考えるとか。。。方法は少ないですけど。。(それは別の機会にでも。。)


では、非パーティション表とパーティション表のパーティシィンワイズジョインのPGAの使い方の差異を確認してみましょう。
思いつきで作ったにしてもよくない例ではりますが(やっつけ感満載wで、セグメントサイズを稼いでぐための表定義となっています)PGAの利用サイズの変化は見ることができると思います。

非パーティション表の定義と統計情報取得、それに登録した各表のセグメントサイズは以下のとおり。

create table m
(
id number(10) not null
,foo varchar2(4000)
,bar varchar2(4000)
,constraint pk_m primary key(id) using index
);


create table d
(
id number(10) not null
,rev# number(3) not null
,foo varchar2(4000)
,bar varchar2(4000)
,constraint pk_d primary key(id, rev#) using index
);

SCOTT> exec dbms_stats.gather_table_stats(ownname=>'SCOTT',tabname=>'M',cascade=>true,no_invalidate=>false);
SCOTT> exec dbms_stats.gather_table_stats(ownname=>'SCOTT',tabname=>'D',cascade=>true,no_invalidate=>false);

SCOTT> select segment_name,bytes/1024/1024 "MB" from user_segments where segment_name in ('M','D')

SEGMENT_NAME MB
------------------------------ ----------
M 192
D 3766

1つの操作で利用可能なPGAサイズは約80MBにしてあります。この状態で上記の2表を結合すれば、いい感じで一時表領域へ落ちるはずです。

SCOTT> select * from v$pgastat;

NAME VALUE UNIT CON_ID
---------------------------------------------------------------- ---------- ------------ ----------
・・・略・・・
global memory bound 83886080 bytes 0
・・・略・・・

2表をハッシュ結合するようにヒントで強制しています。
想定通り、PGAを使いきっても足りずに、580MBほど一時表猟奇が利用されています。

SQL Monitoring Report

SQL Text
------------------------------
SELECT /*+ MONITOR LEADING(m d) USE_HASH(m d) */ * FROM m INNER JOIN d ON m.id = d.id

Global Information
------------------------------
Status : DONE (ALL ROWS)
Instance ID : 1
Session : SCOTT (302:21504)
SQL ID : 44pfxjgnt7bcq
SQL Execution ID : 16777216
Execution Started : 03/24/2019 09:40:48
First Refresh Time : 03/24/2019 09:40:48
Last Refresh Time : 03/24/2019 09:41:07
Duration : 19s
Module/Action : SQL*Plus/-
Service : orcl
Program : sqlplus@localhost.localdomain (TNS V1-V3)
Fetch Calls : 16001

Global Stats
===========================================================================================
| Elapsed | Cpu | IO | Other | Fetch | Buffer | Read | Read | Write | Write |
| Time(s) | Time(s) | Waits(s) | Waits(s) | Calls | Gets | Reqs | Bytes | Reqs | Bytes |
===========================================================================================
| 11 | 4.41 | 5.53 | 1.28 | 16001 | 777K | 217K | 6GB | 2292 | 555MB |
===========================================================================================

SQL Plan Monitoring Details (Plan Hash Value=1876521935)
=====================================================================================================================================================================================
| Id | Operation | Name | Rows | Cost | Time | Start | Execs | Rows | Read | Read | Write | Write | Mem | Temp | Activity | Activity Detail |
| | | | (Estim) | | Active(s) | Active | | (Actual) | Reqs | Bytes | Reqs | Bytes | (Max) | (Max) | (%) | (# samples) |
=====================================================================================================================================================================================
| 0 | SELECT STATEMENT | | | | 19 | +1 | 1 | 240K | | | | | . | . | 10.00 | Cpu (1) |
| 1 | HASH JOIN | | 240K | 232K | 19 | +1 | 1 | 240K | 2292 | 555MB | 2292 | 555MB | 84MB | 579MB | 60.00 | Cpu (1) |
| | | | | | | | | | | | | | | | | direct path write temp (5) |
| 2 | TABLE ACCESS FULL | M | 12000 | 6609 | 1 | +1 | 1 | 12000 | 4344 | 219MB | | | . | . | | |
| 3 | TABLE ACCESS FULL | D | 240K | 130K | 16 | +1 | 1 | 240K | 210K | 5GB | | | . | . | 30.00 | Cpu (1) |
| | | | | | | | | | | | | | | | | db file sequential read (2) |
=====================================================================================================================================================================================

続きを読む "Temp落ち #10 - パーティションワイズジョインはどうよ"

| | コメント (0)

2019年3月24日 (日)

Oracle VM VirtualBox 6.0 でも治ってなかった、ドラッグするとDesktopが取り残される問題 / FAQ

Oracle VM VirtualBox 5.x台からあった問題、6.0でも修正されていないですね。
ただ、解決方法はあって、一旦、Dockにしまって再度取り出すと症状は治まるんですよね。これw

以下、タイトルバーをクリックしてドラッグするとなぜかデスクトップだけが取り残されてのっぺらぼう状態になってしまったスクリーンショット

20190324-152727

| | コメント (0)

2019年3月22日 (金)

ORA_HASH()を使ってリストパーティションにハッシュパーティションのような均一配分を

ハッシュパーティションってリストパーティションみたいにパーティション狙い撃ちできて、かつ、ハッシュパーティションみたいに、データをパーティション間で均一化できないのかなぁ
というずいぶん昔の話を思い出して、そう言えば書いてないかもしれない。いつの話だよってぐらい昔の話だけどw
どうやったかというと、
ハッシュキーにふさわしい値をもつ列を決める(一意キーとか主キー列が理想、カーディナリティの低い、分布に偏りのあるデータを持つ列は使わない)

続きを読む "ORA_HASH()を使ってリストパーティションにハッシュパーティションのような均一配分を"

| | コメント (0)

2019年3月21日 (木)

in-memory関連の謎パラメータ 18c

12cR2と18cのin-memory関連の隠しパラメータ以外の違い。
Database Reference Release 18
inmemory_optimized_arithmeticってパラメータ、SIMD向け最適化っぽい(デフォがDESABLEDみたいだが)
inmemory_prefer_xmem_memcompress と inmemory_prefer_xmem_priority inmemory_xmem_sizeこれらのパラメータ、隠しパラメータじゃないのにundocumented なのはなぜ?
もしかして、xmem って略語、Exadataの資料でヒットした。。。Exadata オンリー? なやつかな?
BANNER_LEGACY                                                                   BANNER                                                                          
------------------------------------------------------------------------------- -------------------------------------------------------------------------------
Oracle Database 18c Enterprise Edition Release 18.0.0.0.0 - Production Oracle Database 12c Enterprise Edition Release 12.2.0.1.0 - 64bit Production

ORCL@SYS> show parameter memory orcl12c@SYS> show parameter memory

NAME TYPE VALUE NAME TYPE VALUE
------------------------------------ ----------- ------------------------------ ------------------------------------ ----------- ------------------------------
hi_shared_memory_address integer 0 hi_shared_memory_address integer 0
inmemory_adg_enabled boolean TRUE inmemory_adg_enabled boolean TRUE
inmemory_automatic_level string OFF
inmemory_clause_default string inmemory_clause_default string
inmemory_expressions_usage string ENABLE inmemory_expressions_usage string ENABLE
inmemory_force string DEFAULT inmemory_force string DEFAULT
inmemory_max_populate_servers integer 0 inmemory_max_populate_servers integer 0
inmemory_optimized_arithmetic string DISABLE
inmemory_prefer_xmem_memcompress string
inmemory_prefer_xmem_priority string
inmemory_query string ENABLE inmemory_query string ENABLE
inmemory_size big integer 0 inmemory_size big integer 0
inmemory_trickle_repopulate_servers_ integer 1 inmemory_trickle_repopulate_servers_ integer 1
percent percent
inmemory_virtual_columns string MANUAL inmemory_virtual_columns string MANUAL
inmemory_xmem_size big integer 0
memory_max_target big integer 0 memory_max_target big integer 0
memory_target big integer 0 memory_target big integer 0
optimizer_inmemory_aware boolean TRUE optimizer_inmemory_aware boolean TRUE
shared_memory_address integer 0 shared_memory_address integer 0

| | コメント (0)

ハッシュパーティションでのデータの偏り / FAQ

ぼやき漫才みたいな感じですが、Oracleに限らず、ハッシュパーティションでパーティション間のデータを均一にしたいなら、ユニークな値かそれに準ずる列を選ぶべきなわけですが、なにを間違ってしまったのか、稀ではありますが、少々残念なことになっていすることもあります。
とは言え、早めに気づけば影響も小さくて済むわけで:)


というわけで、今回はそんなおはなし。

id_code列の値はユニーク
ORCL@SCOTT> select count(*),count(distinct id_code) from org;

COUNT(*) COUNT(DISTINCTID_CODE)
---------- ----------------------
400000 400000
type列の値は、一意性がなくカーディナリティーも低い、かつ、大きな偏りがある。。
ORCL@SCOTT> select type,count(1) from org group by type;

type COUNT(1)
---------- ----------
1 60000
2 60000
9 60000
0 220000
ハッシュパーティションを選択する主な理由は、パーティションへのデータの均一分散なので、列の値がユニークな列をパーティションキーとしてパーティション化することが多いわけですが、。。
以下は、ハッシュキーに一意な値を持つ列を選択した場合の例
ORCL@SCOTT> r
1 create table hash_p_tab
2 partition by hash(id_code)
3 (
4 partition hash_p_tab_p1
5 ,partition hash_p_tab_p2
6 ,partition hash_p_tab_p3
7 ,partition hash_p_tab_p4
8 )
9 as select
10 id_code
11 ,foo
12 ,type
13 from
14* org

Table created.

ORCL@SCOTT> alter table hash_p_tab add constraint gpk_hash_p_tab primary key(id_code) using index global;

Table altered.

ORCL@SCOTT> exec dbms_stats.gather_table_stats(ownname=>'SCOTT',tabname=>'hash_p_tab',cascade=>true,no_invalidate=>false,granularity=>'ALL');


ORCL@SCOTT> select table_name,partition_name,num_rows from user_tab_partitions order by 1,2;

TABLE_NAME PARTITION_NAME NUM_ROWS
------------------------------ ------------------------------ ----------
HASH_P_TAB HASH_P_TAB_P1 99901
HASH_P_TAB HASH_P_TAB_P2 100194
HASH_P_TAB HASH_P_TAB_P3 100056
HASH_P_TAB HASH_P_TAB_P4 99849


しかし、値の分布に偏りのあるカーディナリティの低い列を選んで残念なことになっているケースも稀にあったりします。

なぜ、ハッシュキーにこの列を選んだんだ! みたいな。。。

そんな時は、設計した人に聞くしかないです。何がやりたかったのかを。。。私に聞かれてもハッシュキーの選択をミスったんですよねーたぶん、としか言えないので。
ORCL@SCOTT> r
1 create table hash_p_tab_skew
2 partition by hash(type)
3 (
4 partition hash_p_tab_skew_p1
5 ,partition hash_p_tab_skew_p2
6 ,partition hash_p_tab_skew_p3
7 ,partition hash_p_tab_skew_p4
8 )
9 as select
10 id_code
11 ,foo
12 ,type
13 from
14* org

Table created.

ORCL@SCOTT> alter table hash_p_tab_skew add constraint gpk_hash_p_tab_skew primary key(id_code) using index global;

Table altered.

ORCL@SCOTT> exec dbms_stats.gather_table_stats(ownname=>'SCOTT',tabname=>'hash_p_tab_skew',cascade=>true,no_invalidate=>false,granularity=>'ALL');

PL/SQL procedure successfully completed.

ORCL@SCOTT> select table_name,partition_name,num_rows from user_tab_partitions where table_name = upper('hash_p_tab_skew') order by 1,2

TABLE_NAME PARTITION_NAME NUM_ROWS
------------------------------ ------------------------------ ----------
HASH_P_TAB_SKEW HASH_P_TAB_SKEW_P1 0
HASH_P_TAB_SKEW HASH_P_TAB_SKEW_P2 280000
HASH_P_TAB_SKEW HASH_P_TAB_SKEW_P3 60000
HASH_P_TAB_SKEW HASH_P_TAB_SKEW_P4 60000

続きを読む "ハッシュパーティションでのデータの偏り / FAQ"

| | コメント (0)

Join Elimination(結合の排除)と 参照整合性制約 / FAQ

偶に聞かれることがあるので、再び、Join Elimination(結合の排除)について
まずは、以下のSQL文を。
order表とcustomers表をinner joinしている単純な文ですが、重要なのは、実行計画の方!


order表とcustomers表をinner joinしているのに、order表だけ(この場合、order表の主キー索引だけのIndex Only Scanになっていますが)で、customes表を結合していせん。

理由は単純で、以下のSQL文では、customsers表の結合が不要なだけなんです。なぜかわかりますか?
以前、浅瀬でジャブジャブしていたセッション資料にヒントがあります。
order表に定義されている参照整合性制約によりcustomer_idがcustomsers表に存在していることを確認するための結合は不要と、オプティマイザーが判断した結果なんですよね。これ。
上記以外のケースでも無駄な結合を排除しようとする最適化を行うことがあります。内部的にはSQL文を書き換えてくれているわけですね。無駄に結合を行わないために。。。10053トレースをとって、 Join Elimination で grep をかけてみるとオプティマイザの気持ちが見えてきます:)
ORCL@OE> explain plan for
2 select
3 distinct
4 order_id
5 from
6 orders o
7 , customers c
8 where
9 o.customer_id = c.customer_id
10 and order_id < 2400;

Explained.

ORCL@OE> @?/rdbms/admin/utlxpls

PLAN_TABLE_OUTPUT
-----------------------------------------------------------------------------
Plan hash value: 1653993310

-----------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
-----------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 46 | 184 | 1 (0)| 00:00:01 |
|* 1 | INDEX RANGE SCAN| ORDER_PK | 46 | 184 | 1 (0)| 00:00:01 |
-----------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

1 - access("ORDER_ID"<2400)

続きを読む "Join Elimination(結合の排除)と 参照整合性制約 / FAQ"

| | コメント (0)

2019年3月17日 (日)

Oracle VM VirtualBoxが6.0になってた

自分のことに気を取られて、ネットを泳ぎきれてない日が続いてるなーと思う今日この頃ですが、
また、一つ、遅れ気味で、気づいたw

VirtualBox 、 6.0になってたのでアップデートdone

https://www.virtualbox.org/wiki/Changelog-6.0#v4
https://www.virtualbox.org/wiki/Downloads

20190317_123051


| | コメント (0) | トラックバック (0)

2019年3月16日 (土)

Oracle Database入学式 2019 – 保護者の方はご遠慮ください

毎年恒例の
Oracle Database入学式 2019 – 保護者の方はご遠慮ください
https://jpoug.doorkeeper.jp/events/88273
が開催されます。

開催場所は エヌ・ティ・ティ・データ先端技術株式会社コラボレーションルーム です。

すでに満席となっていますが、キャンセル待ち登録可能です。

| | コメント (0) | トラックバック (0)

2019年2月21日 (木)

Wait Events

データベース関連で待機イベントと言えば、これまでは、Oracle Database しか浮かばなかったわけですが、今は、PostgreSQL、そして、MySQL にも実装された。

待機イベントを知らずして、どうするの? でも大丈夫。 今までOracleの待機イベントに親しんできたデータベースエンジニアの活躍の場が広がるんじゃないかなぁ。。。と遠くをみている。。。

続きを読む "Wait Events"

| | コメント (0) | トラックバック (0)

2019年2月12日 (火)

RDS Oracle 雑多なメモ#17/ FAQ

Oracle DB インスタンスの一般的な DBA タスクに記載されているAmazon RDS OracleとオンプレのOracleの操作方法の違は意外に多く、長年かけて体に染み付いていて、脊髄反応でタイプしてしまうとエラー、あ”〜っなんてこともしばしばw

仕方ないので、慣れるしかないわけですが、脊髄反応でオンプレのコマンドをタイプして、あ”〜っ! となったことのある個人的な Top5 を備忘録として書いておきます:)
脊髄反応でそんな権限ないよーというショックなエラーうけとる回数を少しでも減らせるようAmazon RDSパッケージのタイプ練習中の日々w (いずれ、うまく切り替えられるようになれるだろうと信じてw

Oracle DB インスタンスの一般的な DBA システムタスク
Oracle DB インスタンスの一般的な DBA データベースタスク
Oracle DB インスタンスの一般的な DBA ログタスク
Oracle DB インスタンスの一般的な DBA のその他のタスク

個人的に、つい、オンプレと同じ操作をして、エラーになってしまった Top5 w

1位. sysオブジェクトへ権限付与で grant文をタイプしてしまう。
2位. つい、alter system kill session をタイプしてしまう。
3位. オンラインログファイルを切り替えたり、追加、削除で、alter database add logfile..をタイプしたり、alter system switch logfileをタイプしてしまう。
4位. ディレクトリオブジェクトを作成しようとして、create directory...をタイプしてしまう。
5位. rmanの検証コマンドを使おうとして、生のrmanは使えなかった、と気づくw

私がつい、脊髄反応でオリジナルのコマンドをタイプして、エラー? なぬ? あ、RDSではAmazon RDS向けのパッケージ使うんだった!!と 気づく典型的な操作の数々(^^;;;;; 長年しみついた手癖で脊髄反応しちゃうのでどうしようもないのですw
みなさんはどのコマンドで、あ”! となることが多いのでしょうか?(おそらく Top.1は、私と同じ、grant関連ではないでしょうか?w 一番使う機会が多いですからね)

続きを読む "RDS Oracle 雑多なメモ#17/ FAQ"

| | コメント (0) | トラックバック (0)

2019年2月11日 (月)

\copy コマンド de CSVファイルからのロード

今回はOracleネタではなく、Aurora PostgreSQLネタです。(RDS PostgreSQLでも同じ

csvファイルをロードしてみます。

csvファイルは前回SQL*Plusで作成したファイルを使います:)

discus-mother:~ oracle$ echo $LANG
ja_JP.UTF-8
discus-mother:~ oracle$
discus-mother:~ oracle$ cat loaddata_test.csv
1,"テスト","note"
2,"平成","note"
3,"abcdbef","note"
4,"あ","note"
5,"A","note"
6,,"note"

つづいて、Aurora PostgreSQLへcsvデータをロードする準備。
事前に表を作成しておきました。

discus-mother:˜ oracle$ psql --host=xxxxxxxxxxxxxxxxxxxxx.rds.amazonaws.com --port=5432 --username=hoge --password --dbname=testdb

testdb=> select aurora_version();
aurora_version
----------------
2.1.0
(1 row)

testdb=> select version();
version
-----------------------------------------------------------------------------
PostgreSQL 10.5 on x86_64-pc-linux-gnu, compiled by gcc (GCC) 4.9.3, 64-bit
(1 row)

testdb=> \l testdb
List of databases
Name | Owner | Encoding | Collate | Ctype | Access privileges
--------+-------+----------+---------+-------+-------------------
testdb | hoge | UTF8 | C | C |
(1 row)

testdb=>
testdb=> create schema hoge;
CREATE SCHEMA
testdb=> set search_path=hoge,public;
SET
testdb=>
testdb=> create table test (
testdb(> id numeric not null primary key
testdb(> ,data character varying(10)
testdb(> ,foo character varying(10) not null
testdb(> );
CREATE TABLE
testdb=> \d+ test
Table "hoge.test"
Column | Type | Modifiers | Storage | Stats target | Description
--------+-----------------------+-----------+----------+--------------+-------------
id | numeric | not null | main | |
data | character varying(10) | | extended | |
foo | character varying(10) | not null | extended | |
Indexes:
"test_pkey" PRIMARY KEY, btree (id)

testdb=>

続きを読む "\copy コマンド de CSVファイルからのロード"

| | コメント (0) | トラックバック (0)

SQL*Plusでcsv出力できるんですよ #2 null はどうなる? / FAQ

前回は、SQL*Plusでcsvファイルをお手軽にできることを確認したので、今回はもう少し細かいところを確認しておきます。

csvファイルを作成するOracle Databaseのバージョン等は以下のとおり。

SQL> select
2 banner_full
3 from
4 v$version;

BANNER_FULL
--------------------------------------------------------------------------------
Oracle Database 18c Enterprise Edition Release 18.0.0.0.0 - Production
Version 18.3.0.0.0

データベースキャラクタセットは最近では一般的なAL32UTF8

SQL> r
1 select
2 parameter
3 , value
4 from
5 nls_database_parameters
6 where
7* parameter in ('NLS_CHARACTERSET')

PARAMETER VALUE
---------------------------------------- ------------------------------
NLS_CHARACTERSET AL32UTF8

SQL>
SQL> !echo $NLS_LANG
Japanese_Japan.AL32UTF8

SQL> !echo $LANG
ja_JP.UTF-8

適当に作成した表は以下のとおり。NULLの取り込みを見ておきたかったのでnullも含めてあります。

SQL> desc test
名前 NULL? 型
----------------------------------------- -------- ----------------------------
ID NOT NULL NUMBER
DATA VARCHAR2(10)
FOO NOT NULL VARCHAR2(10)

SQL> select * from test order by id;

ID DATA FOO
---------- ---------- ----------
1 テスト note
2 平成 note
3 abcdbef note
4 あ note
5 A note
6 note

6行が選択されました。


id=6のdata列は null なのですが空白区別しにくいので可視化して確認しておきます。
注意)set null コマンドで設定した文字列は csv作成時のにも反映されるため空にリセットすることをお忘れなく。

SQL> set null [null]
SQL> select * from test order by id;

ID DATA FOO
---------- ---------- ----------
1 テスト note
2 平成 note
3 abcdbef note
4 あ note
5 A note
6 [null] note

6行が選択されました。

SQL> set null ""

続きを読む "SQL*Plusでcsv出力できるんですよ #2 null はどうなる? / FAQ"

| | コメント (0) | トラックバック (0)

SQL*Plusでcsv出力できるんですよ / FAQ

SQL*Plusでcsv出力する簡単な方法って、意外に知られてないようなのでメモ程度に書いておきます。
自分でもコピペネタとするためにw

SQL> select * from q order by id;

ID DATA
---------- ----------
1 テスト
2 平成
3 abcdbef
4 あ
5 A

SQL> set markup csv on
SQL> select * from q order by id;

"ID","DATA"
1,"テスト"
2,"平成"
3,"abcdbef"
4,"あ"
5,"A"

SQL> set markup csv off

続きを読む "SQL*Plusでcsv出力できるんですよ / FAQ"

| | コメント (0) | トラックバック (0)