2

ランダムにエラーを引き起こしているコードを本番環境にリリースしました。クエリの実行方法を完全に変更することで、すでに問題を修正しました。しかし、そもそも何が問題を引き起こしているのかわからないので、誰かが答えを知っているのではないかと思っていました。ストアド プロシージャ内に次のクエリがあります。ネストされた関数呼び出しなどでクエリを作成するのは良い習慣ではないというコメントは探していません:-)。一貫して機能しない理由を本当に知りたいだけです。ランダムに、クエリ内の関数が数値以外の値を返し、結合でエラーが発生します。ただし、クエリをすぐに再実行すると、正常に動作します。

SELECT      cscsf.cloud_server_current_software_firewall_id,
                dbo.fn_GetCustomerFriendlyFromRuleName(cscsf.rule_name, np.policy_name) as rule_name,
                cscsf.rule_action,
                cscsf.rule_direction,
                cscsf.source_address,
                cscsf.source_mask,
                cscsf.destination_address,
                cscsf.destination_mask,
                cscsf.protocol,
                cscsf.port_or_port_range,
                cscsf.created_date_utc,
                cscsf.created_by
    FROM        CLOUD_SERVER_CURRENT_SOFTWARE_FIREWALL cscsf
    LEFT JOIN   CLOUD_SERVER cs
    ON          cscsf.cloud_server_id = cs.cloud_server_id
    LEFT JOIN   CLOUD_ACCOUNT cla
    ON          cs.cloud_account_id = cla.cloud_account_id
    LEFT JOIN   CONFIGURATION co
    ON          cla.configuration_id = co.configuration_id
    LEFT JOIN   DEDICATED_ACCOUNT da
    ON          co.dedicated_account_id = da.dedicated_account_id
    LEFT JOIN   CORE_ACCOUNT ca
    ON          da.core_account_number = ca.core_account_id
    LEFT JOIN   NETWORK_POLICY np 
    ON          np.network_policy_id = (select dbo.fn_GetIDFromRuleName(cscsf.rule_name))
    WHERE       cs.cloud_server_id = @cloud_server_id
    AND         cs.current_software_firewall_confg_guid = cscsf.config_guid
    AND         ca.core_account_id IS NOT NULL
    ORDER BY    cscsf.rule_direction, cscsf.cloud_server_current_software_firewall_id

合流に気づいたら

ON          np.network_policy_id = (select dbo.fn_GetIDFromRuleName(cscsf.rule_name))

関数を呼び出します。

その関数は次のとおりです。

ALTER FUNCTION [dbo].[fn_GetIDFromRuleName]
(
    @rule_name              varchar(100)
)
RETURNS varchar(12)
AS
BEGIN
    DECLARE     @value      varchar(12)

        SET @value = dbo.fn_SplitGetNthRow(@rule_name, '-', 2)
        SET @value = dbo.fn_SplitGetNthRow(@value, '_', 2)
        SET @value = dbo.fn_SplitGetNthRow(@value, '-', 1)

    RETURN      @value
END

次に、この関数を呼び出します。

ALTER FUNCTION [dbo].[fn_SplitGetNthRow]
(
    @sInputList     varchar(MAX),
    @sDelimiter     varchar(10) = ',',
    @sRowNumber     int = 1
)
RETURNS varchar(MAX)
AS
BEGIN
    DECLARE     @value      varchar(MAX)

    SELECT      @value = data_split.item
                        FROM
                        (
                            SELECT *, ROW_NUMBER() OVER (ORDER BY (SELECT 1)) as row_num FROM dbo.fn_Split(@sInputList, @sDelimiter)
                        ) AS data_split
                        WHERE
                        data_split.row_num = @sRowNumber

    IF          @value IS NULL
        SET     @value = ''

    RETURN      @value  
END

最終的にこの関数を呼び出します:

ALTER FUNCTION [dbo].[fn_Split] (
    @sInputList VARCHAR(MAX),
    @sDelimiter VARCHAR(10) = ','
) RETURNS @List TABLE (item VARCHAR(MAX))
BEGIN
    DECLARE @sItem VARCHAR(MAX)
    WHILE CHARINDEX(@sDelimiter,@sInputList,0) <> 0
        BEGIN
            SELECT @sItem=RTRIM(LTRIM(SUBSTRING(@sInputList,1,CHARINDEX(@sDelimiter,@sInputList,0)-1))), @sInputList=RTRIM(LTRIM(SUBSTRING(@sInputList,CHARINDEX(@sDelimiter,@sInputList,0)+LEN(@sDelimiter),LEN(@sInputList))))
            IF LEN(@sItem) > 0
                INSERT INTO @List SELECT @sItem
        END

    IF LEN(@sInputList) > 0
        INSERT INTO @List SELECT @sInputList -- Put the last item in
    RETURN
END
4

1 に答える 1

7

さまざまなものを「ランダムに」返す理由は、SQL Serverがクエリを最適化する方法と、クエリが短絡する場所に関係しています。

この問題を解決する1つの方法は、fn_GetIDFromRuleNameの戻り値を変更することです。

return (case when isnumeric(@value) then @value end)

または、結合条件を変更します。

on np.network_policy_id = (select case when isnumeric(dbo.fn_GetIDFromRuleName(cscsf.rule_name)) = 1)
                                       then dbo.fn_GetIDFromRuleName(cscsf.rule_name) end)

根本的な問題は評価の順序です。「case」ステートメントが問題を修正する理由は、変換前に数値をチェックし、SQLServerがcaseステートメントの評価の順序を保証するためです。注意として、整数ではなく数値である「6e07」や「1.23」などの数値の変換で問題が発生する可能性があります。

なぜ時々動作するのですか？まあ、明らかにクエリ実行プランは静的または動的に変化しています。失敗したケースは、WHERE条件によって除外された行にある可能性があります。なぜ変換しようとするのですか？問題は、変換がどこで行われるかです。

変換が発生するかどうかは、クエリプランによって異なります。これは、問題のテーブルcscfがいつ読み取られるかに依存する可能性があります。すでにメンバーになっている場合は、クエリの最初のステップとして読み取られ、変換が試行される可能性があります。次に、エラーが発生します。別のシナリオでは、別のテーブルがフィルター処理され、変換される前に行が削除される場合があります。

いずれにせよ、私のアドバイスは次のとおりです。

  • クエリで暗黙の変換を行わないでください。
  • 明示的な変換にはcaseステートメントを使用します。
  • 変換を機能させるためにデータをフィルタリングするためにWHERE句に依存しないでください。caseステートメントを使用します。
于 2012-09-05T18:29:47.347 に答える