データベース管理者

SQL "sa"アカウントが使用されるべきでない方法で使用されていることを発見したため、すべてのSQLインスタンスでsaパスワードを変更しています。 （SQL 2005〜2017のサーバーは混合認証モードで実行されています。すべてのユーザーとアプリケーションは、ドメインアカウントまたは非sa SQLアカウントを使用して接続する必要があります。監視していますが、他のアプリ、ユーザー、または非-saアカウントを使用した内部spid。） いくつかの質問： Q1：saパスワードを変更するには、SQLの再起動が必要ですか？ saアカウントのパスワードを変更した後、SQLサービスの再起動が必要であると言ういくつかの参照を見つけました。 DBA SE：saパスワードの変更 SQLAuthority：Management Studioを使用したSAログインのパスワードの変更 本当？または、認証モードを変更する場合にのみ？または、私が日常的にsaとしてログオンする場合のみ？ このSQL Server Centralスレッドは、変更すると既存のSQLエージェントジョブなどに影響を与える可能性があることを示唆しています。それは心配ですか？または、誰かがSAアカウントをSSISパッケージなどにハードコーディングした場合にのみ？ （重要な場合は、SQLサービスとSQLエージェントサービスにドメインアカウントを使用し、SSISパッケージまたはPowerShellスクリプトを呼び出すジョブにドメインプロキシアカウントを使用します。） Q2：saパスワードを「通常の」方法で変更できますか？ 他のアカウントと同じようにリセットできますか？SSMSを使用するか、より可能性が高い： ALTER LOGIN sa WITH PASSWORD = 'newpass'; または、シングルユーザーモードまたは計画的なダウンタイムを必要とするモードに入る必要がありますか？（「sa」として接続しているときではなく、ドメインアカウントから実行していることに注意してください。） Q3：このパスワードのローテーションを定期的に実行する必要がありますか？または、問題が見つかった場合のみ？ これは推奨される「ベストプラクティス」ですか？

13 sql-server  security  best-practices 

デフォルトを使用したPostgreSQL、および default_statistics_target=1000 random_page_cost=1.5 バージョン PostgreSQL 10.4 on x86_64-pc-linux-musl, compiled by gcc (Alpine 6.4.0) 6.4.0, 64-bit 掃除機をかけて分析しました。クエリは非常に簡単です。 SELECT r.price FROM account_payer ap JOIN account_contract ac ON ap.id = ac.account_payer_id JOIN account_schedule "as" ON ac.id = "as".account_contract_id JOIN schedule s ON "as".id = s.account_schedule_id JOIN rate r ON s.id = r.schedule_id WHERE …

13 postgresql  join  execution-plan  postgresql-10 

（I / O障害により修正された）破損に苦しんでいるデータベースを回復しようとする仕事をしました。私は、データベースまたはデータベースに含まれる内容に詳しくありません。 古い（最大3週間）フルバックアップと一連のトランザクションログが与えられました...しかし、トランザクションログが欠落しているため、特定の日付までしか回復できません。2.5週間分のデータが失われています（このデータベースには常に多くのデータが追加されています）。 また、破損したデータベースのコピー（アクセス可能ですが、多くのページが破損/欠落しています）のコピーも提供されています。 私は典型的なDBCC CHECKDBコマンドを試してみました（まだありrepair_allow_data_lossません。他に何も機能しない場合、それは私の最後の手段になります）。 多くの人がデータベースに出入りした後（dbは1.5テラバイトの小さな怪物で、私がすることはすべて遅くて時間がかかります）、破損したページの最後の正常なバックアップからオンラインページの復元を試みました。 それを行うためにRESTORE DATABASE <foo> PAGE='pages' FROM DISK='<bar.bak>'、DBCC CHECKDB出力から多くのコマンドを作成するスクリプトを作成しました（基本的には正規表現と異なる）...これまでのところ、これは1000ページの制限に達したと言った時点まで機能しました復元コマンドごとにファイルごと（このデータベースには8つのファイルがあります）。 そのため、「オンライン復元を完了する」ように求められますが、それを行う方法に途方に暮れています...私はテールログまたは最初の完全バックアップよりも完全なものを持っていないので、基本的に、残りのページで試行を続けるために復元を完了する方法がわかりません。 私は試してみましたRESTORE DATABASE <foo> WITH RECOVERYが、それでもうまくいきませんでした、私は持っていないログを要求します。 誰かがここから何かを回復しようとする方法についてのヒントを持っていますか？または、オンライン復元を「完了」して、さらに多くのページを復元しようとする方法はありますか？オフライン復元を試しても同じ問題が発生しますか（基本的WITH NORECOVERYにすべてを追加してから、最後に復元しようとしますか？） データベースを手作業で処理することは基本的に元に戻せません...数百万の行を持つ数百のテーブルがあり、それが何であるかについて明確な意味はありません。SELECT数百万行を超えると、破損したDBはクエリで失敗しますが、どこで解決できるかはわかりません。すべての非クラスター化インデックスを再構築しようとしましたが、行データを含む破損したページがあるため、どちらも機能しませんでした。 ある程度のデータ損失は許容されますが、DBでの一貫性の達成は少なくとも試みられるべきです。 破損したデータベースはまだオンラインであり、クライアントが作業しているため（新しいデータを取得し続けます）、ラボベンチで行うすべてのプロセスは、後で運用データベースで再現可能です（ダウンタイムは困難です）。 これはSQL Server 2014 Enterpriseです PS：私はDBAではありません...私はプログラマーですが、クライアントはいくつかの「エキスパート」SQLディザスタリカバリサービスを試してみましたが、彼らはあきらめました。何でもする。 更新：多くのテストの後、ページごとの復元は不要でしたので、アイデアを捨てました。手動リカバリ（破損したテーブルから不足しているレコードを手動で選択し、最後の既知の正常なバックアップに挿入する）を行い、自動化ツールを使用します（再び、何百ものテーブルがあります）。

13 sql-server  t-sql  sql-server-2014  restore  recovery 

ページ圧縮（ALTER INDEX IX1 REBUILD PARTITION = ALL WITH (DATA_COMPRESSION = PAGE)）を使用してSQL Serverインデックスを再構築した後、（特定の断片化しきい値を超えた一部のメンテナンススクリプトで行われるように）その後の再構築では、データ圧縮を再度指定する必要がありますか？そうでなければ、インデックスは効果的に圧縮解除されますか？

13 sql-server  index  compression  data-pages 

を使用するselect *と、読み取りがはるかに少ないだけでなく、使用するよりも大幅に少ないCPU時間を使用するクエリがありますselect c.Foo。 これはクエリです： select top 1000 c.ID from ATable a join BTable b on b.OrderKey = a.OrderKey and b.ClientId = a.ClientId join CTable c on c.OrderId = b.OrderId and c.ShipKey = a.ShipKey where (a.NextAnalysisDate is null or a.NextAnalysisDate < @dateCutOff) and b.IsVoided = 0 and c.ComplianceStatus in (3, 5) …

13 sql-server  sql-server-2014  query-performance  execution-plan 

この迷惑な機能をどのようにオフにしますか？DBマネージャーにできるだけ大きな声をかけたくありません。

13 configuration  toad 

行の推定が非常に間違っている理由を理解するのに苦労しています、ここに私の場合があります： 単純な結合-SQL Server 2016 sp2を使用（sp1と同じ問題）、dbcompatiblity = 130。 select Amount_TransactionCurrency_id, CurrencyShareds.id from CurrencyShareds INNER JOIN annexes ON Amount_TransactionCurrency_id = CurrencyShareds.Id option (QUERYTRACEON 3604, QUERYTRACEON 2363); SQLは1行を推定しますが、107131であり、ネストされたループを実行することを選択します（planへのリンク）。CurrencySharedsの統計が更新された後、見積もりは問題なく、マージ結合が選択されます（新しいプランへのリンク）。CurrencySharedsに1つのレコードが追加されるとすぐに、統計が「古く」なり、sqlが誤った推定に戻ります。 この単純なクエリについてはあまり心配しませんが、これは大きなクエリの一部に過ぎず、これはドミノの始まりです... 1つの行を100レコードテーブルに追加すると、このような損傷が発生するのはなぜですか？カーディナリティ推定トレースの出力を調べると、この警告***WARNING: badly-formed histogram ***が表示されますが、このトピックに関する詳細は見つかりませんでした。 ここに、カーディナリティ推定からの完全な出力が出力されます： Begin selectivity computation Input tree: LogOp_Join CStCollBaseTable(ID=1, CARD=107131 TBL: annexes) CStCollBaseTable(ID=2, CARD=100 TBL: CurrencyShareds) ScaOp_Comp x_cmpEq ScaOp_Identifier QCOL: [test.MasterData].[dbo].[CurrencyShareds].Id …

13 sql-server  query-performance  sql-server-2016  cardinality-estimates 

これは、この質問のフォローアップです。また、Microsoftからのこの機能要求に関連しています。 しかし、報告されてから長年が経過し、いくつかのメジャーリリースが市場に届きました。 質問： SQL Server 2017には、このエラーの根本原因の特定を容易にするメカニズムがありますか？または、問題が報告された約9年前と同じくらい調査するのは難しいですか？

13 sql-server  sql-server-2017  string  truncation 

次の表があります（Sakilaデータベースから取得）。 film：film_idはpkeyです 俳優：actor_idはpkeyです film_actor：film_idとactor_idは、映画/俳優のfkeyです 特定の映画を選択しています。この映画では、すべての俳優がその映画に参加することも望んでいます。これには2つのクエリがあります。1つのクエリLEFT JOINと1 つのクエリですLEFT JOIN LATERAL。 select film.film_id, film.title, a.actors from film left join ( select film_actor.film_id, array_agg(first_name) as actors from actor inner join film_actor using(actor_id) group by film_actor.film_id ) as a on a.film_id = film.film_id where film.title = 'ACADEMY DINOSAUR' order by film.title; select film.film_id, film.title, …

13 postgresql  join  execution-plan  postgresql-performance  postgresql-10 

SQL Server 2017（CU3）では、TDEデータベースの1つでバックアップ圧縮を有効にすると、バックアッププロセスによってデータベースの特定のページが常に破損します。圧縮せずにバックアップを実行しても、破損しません。この問題を確認して再現するために行った手順は次のとおりです。 データベース「TDE_DB1」でDBCC CheckDBを実行します。すべてが良好で、エラーはありません。 圧縮せずにデータベースを正常にバックアップします。RESTORE VERIFYONLYはすべてが良いと言っています。 データベースを「TDE_DB2」として正常に復元します。すべて良好で、DBCC CheckDBはエラーを表示しません。 「TDE_DB1」データベースを圧縮して正常にバックアップします。「バックアップセットへの損傷が検出されました」と言うVERIFYONLYエラーを復元します。 データベースを「TDE_DB2」として復元しようとします。「データベースでページ（1：92454）でエラーが検出されました」というエラー 手順1〜3を繰り返します。すべてが良いです; DROP "TDE_DB1"および "TDE_DB2"; バックアップから「TDE_DB1」を復元します。すべてが良いです; 手順1〜5を繰り返します。同じ結果が得られます。 要約すると、データベースと通常のバックアップは正常に見え、データベースでCHECKDBを実行し、バックアップでVERIFYONLYを実行してもエラーは報告されません。圧縮を使用してデータベースをバックアップすると、破損が発生するようです。 以下にエラーのあるコードサンプルを示します。（注：TDEデータベースで圧縮を使用するには、MAXTRANSFERSIZEが必要です） -- Good, completes with no corruption; BACKUP DATABASE [TDE_DB1] TO DISK = N'E:\MSSQL\Backup\TDE_DB1a.bak' WITH CHECKSUM; RESTORE VERIFYONLY FROM DISK = N'E:\MSSQL\Backup\TDE_DB1a.bak' WITH CHECKSUM; RESTORE DATABASE [TDE_DB2] FROM DISK = 'E:\MSSQL\Backup\TDE_DB1a.bak' WITH …

13 sql-server  corruption  transparent-data-encryption  sql-server-2017 

Windows 10 Fallアップデート（1709）をインストールしましたが、PostgreSQL 9.5サーバーが起動しなくなりました。更新前の昨日は機能していましたが、構成を変更していません。 イベントビューアを確認しましたが、次のエラーメッセージが見つかりました。 2017-10-19 11:32:32 CEST LOG: invalid value for parameter "lc_monetary": "Czech_Czech Republic.1250" 2017-10-19 11:32:32 CEST LOG: invalid value for parameter "lc_numeric": "Czech_Czech Republic.1250" 2017-10-19 11:32:32 CEST LOG: invalid value for parameter "lc_time": "Czech_Czech Republic.1250" 2017-10-19 11:32:32 CEST FATAL: configuration file "C:/Program Files/PostgreSQL/9.5/data/postgresql.conf" contains errors MicrosoftはFallアップデートでロケール名を変更したようです。利用可能なロケール名のリストが見つからなかったため、Postgres 10をインストールすることに決め、疑いを確認しました、Postgres …

13 postgresql  postgresql-9.5  windows-10 

どういうわけか、数十年前に、データベースで始まるテーブルが作成されました#。オブジェクトエクスプローラーでは、アプリのデータベースの下に表示されますが、ではありませんtempdb。何らかの理由で、Azureはこのようなデータベースをインポートしません。 ドロップしたり、名前を変更したり、操作したりすることはできません。オブジェクトエクスプローラーからの削除、スクリプトドロップ、GUIからの名前変更を試みましたが、いずれも機能しませんでした。 SQL 2008 R2を使用しています。 drop table [*app*].[dbo]."#OBSOLETE"; Database name '*app*' ignored, referencing object in tempdb. Msg 3701, Level 11, State 5, Line 1 Cannot drop the table '#OBSOLETE', because it does not exist or you do not have permission. exec sp_rename "dbo.#OBSOLETE", "dbo.obsolete" Msg 15225, Level 11, State 1, …

13 sql-server  sql-server-2008-r2  temporary-tables 

私はトレーニングを行っていますが、スクリプトの1つに次のコマンドがあります。 SELECT SUM(Col2) FROM clust_table WHERE Col1 % 3 = 1 WHERE句でこのスニペットの目的を知りたい： Col1 % 3 = 1 私はインターネットでいくつかの調査を行ったが、このコマンドに関する参照は見つかりませんでした。

13 sql-server  t-sql 

CACHESTORE_SQLCP SQLプランは、数日後に38 GBを超えます。 「アドホックワークロード用に最適化」オプションをオンにして既に実行しています。（Entity Frameworkとカスタムレポートにより、多くのアドホックが作成されます！） マルチAZミラーリングを使用するAWS RDS上のSQL Server 2016 SE 3.00.2164.0.v1 実行すると： DBCC FREESYSTEMCACHE('SQL Plans'); または DBCC FREEPROCCACHE または DBCC FREESYSTEMCACHE ('SQL Plans') WITH MARK_IN_USE_FOR_REMOVAL または DBCC FREESYSTEMCACHE ('ALL') WITH MARK_IN_USE_FOR_REMOVAL; それをクリアしていないようです： SELECT TOP 1 type, name, pages_kb FROM sys.dm_os_memory_clerks ORDER BY pages_kb desc type name pages_kb CACHESTORE_SQLCP SQL Plans …

13 sql-server  optimization  sql-server-2016  memory  amazon-rds 

私はSQL Server 2014を使用していますが、これは状況です： サーバーAとサーバーBがあります。 夜間ETLはサーバーAで処理されます。 ロードプロセスが完了した後、データベースXは（と、バックアップされるCHECKSUMとRESTORE VERIFYONLY信頼性を確保するため）、その後、サーバBに送信されます サーバーBはbakファイルを受信し、データベースをそこに復元します。 差分バックアップ戦略を使用して、次のことを行います。 完全バックアップは土曜日にのみ行わ れます。つまり、土曜日にサーバーAの完全バックアップ->サーバーBに出荷->サーバーBの完全バックアップを復元します。 残りの日は差分バックアップ、 つまりサーバーAの差分バックアップ->サーバーBに出荷->サーバーBの差分バックアップを復元します 試しましたが、エラーが発生しました： ロールフォワードの準備ができているファイルがないため、ログまたは差分バックアップを復元できません。 理由はわかりません。sys.database_filesサーバーAとサーバーB を確認しましたが、differential_Base_LSNとdifferential_base_GUIDは同じであることがわかります。どこでも/他に確認するものはありますか？ ちなみに、上記の手順2でサーバーBの差分バックアップを復元する場合、毎回完全バックアップと差分バックアップの両方を常に復元する必要がありますか？ WITH RECOVERY完全バックアップは前日にすでに復元されているため、差分バックアップのみを復元しました（そしてそのエラーメッセージが表示されました）。 明確にするために：はい、サーバーBのデータベースを差分間で読み取り可能にします。どうすればそれを回避できますか？毎晩RESTORE FULL (WITH NORECOVERY)+ RESTORE DIFF (WITH RECOVERY)コンボシーケンスを行う唯一のオプションはありますか？ どんなガイダンスでも大歓迎です。

13 sql-server  backup  restore