最近のトラックバック

最近のコメント

2017年3月
      1 2 3 4
5 6 7 8 9 10 11
12 13 14 15 16 17 18
19 20 21 22 23 24 25
26 27 28 29 30 31  
無料ブログはココログ

« 2006年6月 | トップページ | 2006年12月 »

2006年11月

2006年11月29日 (水)

ORA-00980

【現象】

リモートのDBに存在するテーブルからSELECTするPL/SQLプログラムを流したところ以下のエラーが発生

ORA-00980: synonym translation is no longer valid
Cause: The synonym used is based on a table, view, or synonym that no longer exists.
Action: Replace the synonym with the name of the object it references or re-create the synonym so that it refers to a valid table, view, or synonym.

その時点で確認したことは

  • テーブルはちゃんと存在
  • テーブルへのアクセス権限も付与済み(直接ユーザではなくロールに対してですけど)
  • DBリンクもOK
  • SQL*PLUSからSELECTするSQLを実行するとOK

掲示板等インターネットで検索してみると同じエラーが発生している人は日米あわせても結構いたんですが、これだっ!!という回答は見つからず。

たいていの場合は、

  • シノニムが指しているテーブル等が存在しない
  • シノニムが指しているテーブル等への権限がない(直接ユーザに権限を振ったほうがよいらしい)

  →PL/SQLで実行したらダメな場合はこれに該当するらしい

  • シノニムを作り直す
  • Create public synonym権限を付与する

といったところが対策らしい。

こちらは上記の対策はクリアしていたので原因不明だったが、インスタンスを立ち上げなおしたら正常にアクセスできるようになってしまった。このまま迷宮入りしそう。

文字列を横に連結する方法

pmlのメーリングリストと以下のブログからまとめたメモ。

数値は SUM() 関数で集計、文字列を集計的に結合するには( Transact-SQL で aggregate concatenation )

文字列を集計的に結合する(ユーザー定義関数経由で GROUP BY 対応)

【テーブル】

SQLServerだとNothwindデータベースにあるCategoriesテーブル、Oracleでは同じデータ・設定でCategoriesテーブルを作成してお試し

【Categoriesテーブルのデータ】

CategoryID CategoryName Description
1 Beverages Soft drinks, coffees, teas, beers, and ales
2 Condiments Sweet and savory sauces, relishes, spreads, and seasonings
3 Confections Desserts, candies, and sweet breads
4 Dairy Products Cheeses
5 Grains/Cereals Breads, crackers, pasta, and cereal
6 Meat/Poultry Prepared meats
7 Produce Dried fruit and bean curd
8 Seafood Seaweed and fish

【SQLServerで実行】

実行したSQLは↓

DECLARE @STR NVARCHAR(3000)
SET @STR=''
SELECT @STR=@STR+CategoryName FROM Categories
SELECT @STR 

かえってきた結果は↓

BeveragesCondimentsConfectionsDairy ProductsGrains/CerealsMeat/PoultryProduceSeafood

【ORACLEで実行】

実行したSQLは↓

SELECT REPLACE(SYS_CONNECT_BY_PATH(CATEGORYNAME,':'),':','') FROM CATEGORIES
WHERE CATEGORYID=8
START WITH CATEGORYID = 1
CONNECT BY PRIOR CATEGORYID = CATEGORYID - 1
/

 ※SYS_CONNECT_BY_PATHは階層問合わせでのみ使用可能な関数で、CONNECT BY条件でもどってきた値を区切り文字ありで連結した文字列として返す関数です。空文字('')とかは指定できないのでダミーでとりあえずコロンを指定してReplaceで空文字に置き換えてます。

かえってきた結果は↓

CATEGORYID

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

BeveragesCondimentsConfectionsDairy ProductsGrains/CerealsMeat/PoultryProduceSeafood

1行が選択されました。

2006年11月22日 (水)

TEMP領域について

【備忘のため】

temporary領域の使用率がずっと90%以上でおかしいのでは?と問い合わせを受けたので、備忘のため調べてわかったことをメモ。

temporary表領域はDBが稼動していれば、ほぼfullに使用されているような状態となる。Extentsはいったんアロケートされると、システムによって管理されるとともにアロケートされたままの状態となる。これはいたって正常なことで、temporary領域の空きがないということを意味しない。

<<temporary tablespace >>

2006年11月21日 (火)

見える化とは

見える化とは単に可視化するだけではなく、いやでも目に入るようにするところまでやってこそ。

2006年11月20日 (月)

UNDO領域は再利用されない?

ある日のUNDO領域使用率状況を見て「あれっ?再利用されないの?」と不思議に思い、いろいろ調べてわかったことのメモ

  • UNDO_RETENTIONの値にしたがってSHRINKするのでは?と思っていたがTom Kyte(アメリカで数々のORACLE本を執筆してる人)に言わせると、UNDO_RETENTIONの値は目安程度でしかないらしい(彼は "desire"と表現してました。また別の人は"does not guarantee the retention"とも)
  • データファイルが拡張可能だったりUNDO表領域で使用可能な領域が存在している場合、UNDO_RETENTIONの値にしたがってshrinkせず、むしろ拡張してしまうらしい。拡張する余地がない状態になって初めてreuseするとのこと

      ※ORACLE 10gでは事情が違うらしいけど・・

【環境】
 ORACLE9i 9.2
 undo_management = AUTO

調べたところは↓

<<Undo tablespace keeps growing>>

UNDOセグメントについて

UNDOセグメントについて

  • UNDO表領域のdatafileは、headerとして64KBを使用する
  • UNDOセグメントを作る単位

     →UNDO表領域に十分に空きがある場合、10個のUNDOセグメントを作る

     →空きが十分ない場合は10以下のセグメントが作成される

  • 各UNDOセグメントのサイズは128KBで、2つのextentsからなる。各extentのサイズは64KB
  • 9iでは各UNDOセグメントは必ず1block使用不可となる。ブロックサイズがが8KBの場合、セグメントのサイズは128KBだが使用できるのは120KBまでとなる。なお、10gだとすべて使えるらしい

詳細は以下のリンク。
UNDO behavior in Oracle 9i and 10g under microscope

2006年11月15日 (水)

初歩的なこと

SP1では動いていたパッケージソフトがSP1を適用後動かなくなったときの対処。 dcomcnfg.exeで、DCOMのセキュリティ設定だけでなく、COMの設定も行うことで動作するようになった。正確には、起動とアクティブ化のアクセス許可がEVERYONEはローカルのみOK、匿名ユーザはNGだったのを両方ともローカル・リモートのいずれからもOKとしたことで起動した。パッケージのマニュアルはSP1の前に出ていたヤツなので、DCOMのセキュリティ設定の仕方しか記載されていなかったのでMSのサイトを見つつ設定。

以下MSのサイトにのっていた文章の転記。

DCOM のセキュリティ強化では、COM に対するアクティブ化権限が追加されています。さらに権限をローカルとリモートに分割し、Everyone や Anonymous アカウントがリモートからアクティブ化や起動を行う権限をなくし、Administrators グループのユーザーのみがリモートからのアクティブ化と起動の権限を持ちます。

権限 Administrators Everyone Anonymous

起動およびアクティブ化

ローカルおよびリモートからの起動とアクティブ化

ローカルのみの起動とアクティブ化

アクセス

ローカルおよびリモートからのアクセス

ローカルおよびリモートからのアクセス

ローカルおよびリモートからのアクセス

2006年11月13日 (月)

つまんないこと

VBScriptで、除算の演算子(/)は最大922,337,203,685,477.5807の数値データを扱うことができるが、剰余演算子(mod)は、最大2,147,483,647まで。それ以上の値だとoverflowのエラーとなる。
つまり、
・除算はcurrency型まで対応
・剰余はlong型まで対応
というのが仕様らしい

※とあるアメリカ人(名前もサイトも忘れたけど)の投稿情報より

Big5コードの処理について

RubyはまだBig5に対応していないとのこと。UTF-8に変換して処理する必
要があり。1.9でBig5にも対応される予定らしい。

空き番号が無いかチェック

【状況】

あるテーブル(T_TEST)の列(RNO int)は1から999999までの連続番号で書き込まれている。
連続番号にするために空き番号が無いかチェックをし、空き番号があれば、それを優先的に使用したいとした場合。

【対処】

ROW_NUMBER関数で先頭から空いてる番号を見つける(SQLServer2005以降)

select
min([仮名].[連番]) as [空き番号]
from
(select [番号], ROW_NUMBER() over(order by [番号]) as [連番] from [テーブル名]
) [仮名]
where [番号]<>[連番]

【補足】

SQL Server2005 Beta 2 Transact-SQL の機能強化

ROW_NUMBER

ROW_NUMBER 関数を使用して、クエリの結果行に整数の一連番号を割り当てることができます。 たとえば、すべての講演者の speakertrackscore を返し、スコアの降順に 1 から始まる連続値を結果行に割り当てるとします。 ROW_NUMBER 関数で OVER (ORDER BY score DESC) を指定した次のクエリを実行すると、希望する結果が出力されます。

SELECT ROW_NUMBER() OVER(ORDER BY score DESC) AS rownum, 
  speaker, track, score
FROM SpeakerStats
ORDER BY score DESC

結果セットは以下のようになります。

rownum speaker    track      score
------ ---------- ---------- -----------
1      Jessica    Dev        9
2      Ron        Dev        9
3      Suzanne    DB         9
4      Kathy      Sys        8
5      Michele    Sys        8
6      Mike       DB         8
7      Kevin      DB         7
8      Brian      Sys        7
9      Joe        Dev        6
10     Robert     Dev        6
11     Dan        Sys        3

スコアが最も高い講演者には行番号 1 が割り当てられ、スコアが最も低い講演者は行番号 11 が割り当てられます。ROW_NUMBER 関数は、要求した順序に従ってすべての行に異なる行番号を返します。 OVER() オプションの中で指定した ORDER BY リストが一意ではない場合、結果は 1 とおりに決まりません。 つまり、正しいクエリの結果が 2 つ以上存在することになります。クエリを呼び出すごとに異なる結果が得られることもあります。 たとえば、上記の例では 3 人の講演者 Jessica、Ron、Suzanne に同一の最高スコア (9) が与えられています。 異なる講演者には異なる行番号が割り当たることになっているので、Jessica、Ron、Suzanne にそれぞれ割り当てられた値 1、2、3 は、この 3 人に順不同で割り当てられたと考えてください。 値 1、2、3 がそれぞれ Ron、Suzanne、Jessica に割り当てられたとしても、結果が正しいことに変わりありません。

« 2006年6月 | トップページ | 2006年12月 »