Oracle 質問総合スレ13 [無断転載禁止]©2ch.net
■ このスレッドは過去ログ倉庫に格納されています
>>577
クライアント互換性のあるバージョンだったら、統一されてなくてもいい。
互換性を確認してないなら、まず調べる。MOSで調べりゃすぐ出てくる
互換性のあるバージョンでも、下の記事にあるような事象が発生するので注意
https://www.ashisuto.co.jp/db_blog/article/201712-ora-01017.html >>578
回答ありがとうございます
互換性については確認済みです
統一されていなくても問題ない旨が
記載された記事はどこかにあるでしょうか？
ご紹介頂ければ助かります 全クライアントのバージョンを揃えないと使えないなら、おちおちパッチも当てられない。
問題ないと書いてあるページを探せって上司にでも言われたの？
責任取りたくない奴が誰かで対応が変わりそう
MOSが参照できるならSRでクライアントバージョン不統一での障害事例はありますかとか聞けばいいのでは
根拠なんてない！たぶん大丈夫
というベテラン様の回答だ
信じろ 接続互換マトリクスは、なんかあったら、原因追ってパッチ提供します。
ってだけで、バグがないこと保証するもんじゃないでしょうに。
複数のバージョンからDBリンク(DB自体が他DBのクライアント)されてる環境なんていくらでも聞くわ U.S.A!!
U.S.A!!
かーもんデータアメリカ！
データを高速にimport
Data Pump 実行計画はまったく同じなんだけど、統計情報を更新すると、SQLの速度が速くなることある、どういうこと？ >>586
1回目に実行した時に、データがキャッシュされたんじゃない？ 【ＯＫ出たギリギリの内容】 日本人は猿以下のジャップだと悪意に満ちた宣伝され……九条ないので開戦
http://rosie.5ch.net/test/read.cgi/liveplus/1536026951/l50
また９１１やるのか 実行計画はどうやって調べた? explain plan や set autotrace on では本当の実行計画は
取れない事がある。一見それらしいけど実際の計画とは違うことがある。
実行計画を得るには、経験的にSQLコマンドを実行中にカーソルからdbms_xplan.display_cursorで
取ると良い。 だとしたら、調べた実行計画はあまり参考にならないかもしれない。
統計取り直して速くなるようなら、CBOが正しく働いている証拠だと思う。
SQL実行中の実行計画を採って設計通りになるように調整する。例えばSQLヒントを
挿入してオプティマイザへ介入するか、EEのライセンスがあればならSQL計画管理。 【近畿】大阪、兵庫で空き巣など５５件
韓国籍の男を追送検し捜査終結
【東京】渋谷センター街で落書き、韓国籍の米国大学生(19)を再逮捕
【社会】最大で金利が342倍
元ヤミ金業者、韓国籍の男ら8人逮捕 【近畿】大阪、兵庫で空き巣など５５件
韓国籍の男を追送検し捜査終結
【東京】渋谷センター街で落書き、韓国籍の米国大学生(19)を再逮捕
【社会】最大で金利が342倍
元ヤミ金業者、韓国籍の男ら8人逮捕 >>593
直接は関係ない。
統計取って早くなったと勘違いしてんじゃないかと思っただけだ。
クエリ実行 => 遅いな（ ´_ゝ｀）
統計取得
クエリ再実行 => 速くなった(ﾟ∀ﾟ) (単にresult cachに乗っていただけ) result cacheデフォで有効になってると思ってそう。。 12c R1からデフォルトで有効ですが何か?
知らずにアップグレード後にライブラリキャッシュのラッチ待ちが多発しましたが >>586
DBが12c R1で>>600にもし引っかかているのなら、12c R1特有の動きだと思った方が良い。
統計情報が存在しないと12c R1だと動的に統計情報を取得して、そいつがresult cache領域で
latchを取りまくるというバグがある。
例えRESULT_CACHE_MODE = MANUALとしていてもこの動きとなる。
パッチ充てるか、12c R2に上げれば直る。 動的統計が内部的にリザルトキャッシュ使うのを、デフォルトで有効になるというのか？
この動きをしても、クエリの結果自体はキャッシュされないんだろ？ >>601
12c使ってるとこ見たことないと思ったら、バグだらけだったからなのね。
未だに、どこ行っても11gばっかりw adaptive featuresは本当にバグが多い。12cでパフォーマンス劣化は大概これ。
12.2と12.1のどっかのパッチセットから適応統計はデフォで無効になってるけどね。 >>602
勝手にresult cacheヒント区を内部で付与してSQL実行されるんだから、
当然ながら結果がキャッシュされるぞ。
そのせいで気がついたらあっという間にリザルトキャッシュエリアが食い尽くされて
ラッチが発生しまくってレスポンスが落ちまくるという状況になったから、
定期的にリザルトキャッシュエリアをモニタリングして利用率が80%になったら
フラッシュするというスクリプト書いて対応したわ。 >>604
それでも18cよりはマシだ。
Exadataを18cに上げて色々と遊んでいるが、新機能の半分も
まともに動きやしないw
こんなの良く世の中に出せるもんだといつも関心する。 いや、だからさ、リザルトキャッシュのヒントつくの動的統計の再帰コールだけなんじゃないの？って。 >>607
逆に新機能が半分近くもまともに動くとしたら驚きだ。検証足りてるかと疑いたくなる。 >>608
再起コールだけじゃない。
それだったらあんなにresult cache領域を使いまくる説明にならない。
あっという間に使い切るぞ。 そもそもリザルトキャッシュって役に立つこと無いよね。
ファンクションリザルトキャッシュは素晴らしいけど。 >>610
知らんがな。MOSドキュメントのどこにそんなこと書いてあるの？ 12c以降の新機能って特定の用途に向けられたものという気がしてならない。
むしろ11gR2を安くしてくれた方がありがたい。 >>613
そりゃやることがなくなってきているから仕方ない。 どこかの企業向けに作った機能が、新機能として登場するのは、Oracle Databaseにかぎった話ではない。 新機能出したら既存の機能に悪影響出さなければ良い
出ちゃうけど 現状困ってることが、まともに動かないにもかかわらず新機能で全部解決するみたいな詐欺まがいの売り方はいいかげんやめて欲しい。 現状機能面で（他DBMSに比べて）不足に感じることって何かある？
水平スケールくらいか そういう用途にはOracleの出番はないのでは?
自分的には基本的なRDBMSとしての仕様を何とかして欲しい。
SQL99以降のサポート、LOBを扱い易く、サーバサイドでPL/SQLやJava以外をサポート。 ローカルへのエクスポート
ローカルからのインポート >>622
それはすでにSQL Developerで実現している。 >>620
SQL99以降でなんか便利なのある？
Oracle独自とかPostgreSQL独自の方が進んでる感じするけど
>>621
それやっちゃうと過去資産への大きいからやらないんじゃないかなあ
WHERE RTRIM(COL) IS NULL
を沢山見たし自分でも書いてしまった
SELECTのエイリアスをWHEREやORDERに書けるようにならんかなあ
パーサの順序的な問題だったらWHERE句にエイリアス付けるとかでも
あとLEFT JOINの省略でLOINとか書けるようににしてくれると
JOINと縦並びでスッキリしそう >>624
> それやっちゃうと過去資産への大きいからやらないんじゃないかなあ
オプションで切り替えられるとかでいいと思うけど、まあ無理だろうな
> SELECTのエイリアスをWHEREやORDERに書けるようにならんかなあ
これOracleに限らずなんでサポートされないのか不思議でしょうがないわ
> あとLEFT JOINの省略でLOINとか書けるようににしてくれると
これは要らんわ w WHERE NULL = NULL
も真にしてくれれば、ほとんどの問題は解決するんだけどな。 >>625
使ってないからわからないだけだろうが。 >>627
MySQLの<=>演算子とか、非推奨だけどSQL-ServerでANSI_NULLSをOffにするとか
>>628
nullable な値の比較が面倒って話でしょ >>630
そういうこと。
そもそもLEFT JOIN以外でのNULL発生を禁止しなかったSQL標準化の失策 >>629
散々検討して使えなかったから
たしかに使ってない >>632
SQL Developerはどんどん変わってる。
あなたは12cのマルチテナントの管理操作をSQL Developerでする想定でオラクル社は説明し、SQL Developerがオラクルマスターの出題範囲になっていることも知らないのか？ >>634
日本語でお願いします。なんでもしますから >>631
あなたは自分の都合を言っているだけで、NULLの定義が気にいらないだけだろうが。
LEFT OUTER JOINのときだけNULL値が発生する仕様にしろと言っているのも支離滅裂だぞ。 >623
あれ、今のSQL Developerってそんなに便利なの？
11gぐらいの知識で止まっててよく知らないんだけど
imp/expの代わりに成り得るもの？
バッチ化してバックアップしたり復元したりできるなら個人的ハッピー insert文を泥臭くエクスポートして
インポートするくらいしか知らないなぁ
12cで機能増えたの？ ダメだこりゃ。SQL Developerの配付の基本ルートはOracle Databaseのインストーラではない。 SQL Developerっていつまでたってもバグだらけ。
いろいろ機能試してみても、内部的にバグったSQLが発行され、エラーでどうにもならないことが多い。 >>642
使えるけど、テーブル指定いっぱい指定すると、実行時に文字数制限オーバーでエラーとか出る。 配布ルートというのがよく分からんけどoracle databaseインストールすると、ORACLE_HOMEに入ってるけどな 結論からいうと
exp／impの代替はSQLDveloperじゃ、つとまらんです
サーバーサイド機能のデータポンプをキックするだけのゴミ機能があるだけ U.S.A!!
U.S.A!!
かーもんデータアメリカ！
データを高速にimport
Data Pump >>636
少なくとも、外部結合のみnullが発生するという建前があれば、空文字列がnullになってしまうようなヘンテコな仕様にはならなかっただろう。 >>652
まさかおまえの頭では空文字列とNULLがごっちゃなのか？ >>653
俺の頭の中では別物。そのせいでoracle使うときに苦しむ。 INSERT文、UPDATE文等ではシングルクォーテーション2つはNULLとみなす。
値がないことがNULLだから、Oracleは空文字列をNULL値にしている。
空文字列とNULLが同居するRDBMSの方がさらに面倒で、両方が混ざりあったりして、両方想定していないといけなくなる。 値が NULL と非 NULL の場合とで、ケースを区別していることと大差ないような >>657
> 空文字列とNULLが同居するRDBMSの方がさらに面倒で、両方が混ざりあったりして、両方想定していないといけなくなる。
バカには難しいってことか w >>657
そもそも値がないことと、空文字はそもそも違う。
選挙で投票しないのと、白票を投票するぐらい違う。
白票をカウントしない選挙制度と同じくらい雑な仕組み。 その件については白票しかカウントしない選挙制度が妥協の産物なだけやけどな なんか経緯があるのかね
最初に作った人が「こっちの方が便利じゃね？」と思ったとか
逆に
・文字列は空文字、数値はゼロ、日付は0001-01-01 00:00:00を初期値とする
・外部結合で結合結果が存在しない場合初期値とします
とかいうDBがあったらそれはそれで他の言語からデータを取り扱う際便利そう
プログラム言語は基本そっち側だよね >プログラム言語は基本そっち側だよね
だったらヌルポとか発生しないわ >>663
空文字列は空文字列がデータで良いのかどうかという判断が難しくなるので、リレーショナルデータベースではNULL値を採用している。 >>663
外部結合させた場合に発生するNULLは正確には不定値で、値がないというNULLとは少し異なる。 >>667
NULL値てw初心者スレいけよおまえw >>667
リレーショナルデータベースの一般の話ではなく、ORACLEのみの話 >>670
Oracle DatabaseではNULL値(NULL Value)という言葉を使います。Oracle Databaseのマニュアルくらいは見ましょう。 oracleのオプティマイザがアホすぎてなかなかexadataのsmart scanを生かし切れない。
インデックス無しでも必要なデータのみストレージで絞って返すというのが売りなのに、実行計画が悪いと大量データ返して来てHASH結合で一時表領域がパンクすることが多い。
なんかコツある？ direct path readになってないんしょ。
インデックスは最小限で、必要に応じてinvisible indexが基本じゃない？ Exadataが特別なものだと信じ込んでいるやつが多すぎて仕事でも会話が成立しない。 >>673
普通に索引作って回避してるぞ？
smartscanを過信しすぎるのは禁物。 ■ このスレッドは過去ログ倉庫に格納されています
