0

私がやろうとしているのは、T-SQL ステートメントの実行タスクを使用して、メンテナンス プランを介して以下のストアド プロシージャを自動的に実行することです。私が見ているのは、この手順が保守計画の一部として実行されると、何らかの理由で、INSERT ステートメントが 2 回実行されたかのように、追加されたレコードが 2 倍になることです。これがキッカーです。Management Studio を介して手動で実行すると、期待どおりに実行され、単一のレコード セットがテーブルに追加されます。回避策として TRUNCATE TABLE を使用すると問題が解決するように見えますが、SQL ミラーリング用にデータベースを準備する段階になると、振り出しに戻ります。

誰もこの種の行動を見たことがありますか？また、興味深いことに、このテーブルで発生する I/O は以下の手順だけであるため、再構築されたインデックスの 100% のフィル ファクターは意図的なものです。

ALTER PROCEDURE [dbo].[usp_Populate_SearchTable]
AS
BEGIN
    UPDATE ut_Update_Status SET [status] = 1, lastUpdate = getdate();

    DELETE FROM ut_Permit_Lookup;
    DBCC CHECKIDENT ('dbo.ut_Permit_Lookup', RESEED, 0);
    -- OR
    --TRUNCATE TABLE ut_Permit_Lookup;

    INSERT INTO ut_Permit_Lookup (
        NUMBER_KEY,
        ADDR_FRACTION,
        PARCEL_NO,
        TYPE_TITLE,
        TypDesc,
        SUB_TYPE,
        Location,
        [DESCRIPTION],
        DATE_A,
        DATA_STATUS
    )
    SELECT a.NUMBER_KEY,
        a.ADDR_FRACTION,
        a.PARCEL_NO,
        a.TYPE_TITLE,
        a.TypDesc,
        a.SUB_TYPE,
        a.Location,
        SUBSTRING(a.[DESCRIPTION], 1, 275),
        a.DATE_A,
        a.DATA_STATUS
    FROM PERMPLUS.dbo.vw_Permit_WebLookup as a
    WHERE a.TYPE_CAT = 'BLDG'
        AND a.DATA_LEVEL = 'A'
        AND (a.CLASS <> 'NA' OR a.CLASS IS NULL);

    DBCC DBREINDEX ('dbo.ut_Permit_Lookup', idx_SearchIndex, 100);
    UPDATE ut_Update_Status SET [status] = 0;
END
4

1 に答える 1

0

さて、私が提案する正式な答えを出すと思います...

私はその問題について聞いたことがありません。私が問題を抱えていたメンテナンス プランは、あなたが抱えているものとは異なりますが、SSMS ビルド番号が私が取り組んでいたインスタンスよりも低いことが原因でした。使用している SQL のビルドは明記されていませんが、SQL 2008 以降の場合は、http://connect.microsoft.com/sqlserverで接続項目を送信できます。

私がおそらく使用する唯一の代替手段は、SQL エージェント ジョブを使用してプロシージャ コールをスケジュールし、同じ結果が得られるかどうかを確認することです。SQL エージェント ジョブは、クエリ ウィンドウで SSMS から呼び出した場合と同じ結果になると思います。

于 2012-10-03T19:18:24.663 に答える