SQL Server のデータベースバックアップですが、完全バックアップではトランザクションログの切り捨てはされません。 トランザクションログの切り捨てを行うためには、トランザクションログのバックアップまたは、復旧モードを [単純] に 設定する必要があります。 ただし例外が一つだけあり、初回のデータベースバックアップ時にはトランザクションログが切り捨てられるようです。 まずはデータを挿入して、トランザクションログが使用されている状態にしてみました。 – トランザクションログの使用状況の取得 – DECLARE @logspace TABLE( DatabaseName sysname, LogSize int, LogSpaceUsed int, Status int ) INSERT INTO @logspace EXEC (‘DBCC SQLPERF(”LOGSPACE”)’)SEL

Twitterで検索したりすると、SQLが分からないという人が相も変わらず非常に多い。おそらく、分からないという人は文法から入っているよね、いや、ほぼ間違いない。しかし、遠回りに見えてもイメージから入るべきです。 初めのうちは、AccessなどGUIでSQLが書けるツールを利用して、FROM句だけを徹底的にやってみてはどうかと思う。 SQL以外の言語はボトムアップ できない人のほとんどは、文法を元にバラして考えているから出来ないし、理解に時間が掛かる。他の言語をやった後に、文法から理解しようとすると、あまりのギャップに苦労することになる。挫折する人のほとんどが、そこで挫折してしまうようです。 他の言語は、プラモデルを組み立てるかのごとく作っていきますから、ある程度の規模になると設計書が必要であったりします。SQL以外の言語をやっているときは積み上げ型（ボトムアップ）の思考回路になっています

適用対象: SQL ServerAzure SQL Managed Instance リンク サーバーを使用すると、SQL Server データベース エンジンおよび Azure SQL Managed Instance では、リモート データ ソースからデータを読み取ったり、SQL Server のインスタンスの外部にあるリモート データベース サーバー (たとえば、OLE DB データ ソース) に対してコマンドを実行したりすることができます。 通常、リンク サーバーは、SQL Server の別のインスタンスまたは別のデータベース製品 (Oracle など) のテーブルを含んだ Transact-SQL ステートメントをデータベース エンジンから実行できるように構成されます。 サードパーティのデータベース プロバイダーや Azure Cosmos DB など、さまざまな種類の OLE

前回のおさらい＆今回の概要 前回では、ユーザから受け取ったSQLに対して、DBMSがどのような手順を踏んでデータを取り出す（または更新する）か、という一連の流れを解説しました。今回は、そこから一歩進んで、実際にシステムに性能問題が発生したとき、どのように対処するか、という実践的なところに踏み込んで解説したいと思います。 前回の内容を前提とするものではありませんが、オプティマイザを中心とするクエリ評価エンジンの機能については、知っていたほうが理解しやすいでしょう。忘れてしまったという方は、第4回（1）で簡単におさらいしてください。 パフォーマンスチューニングは医療に近い 筆者は、仕事でパフォーマンスチューニングを引き受けることがよくあります。性能試験の一環として遅延が発生した処理のチューニングを行うこともあれば、すでにカットオーバーされて運用に入っているシステムが遅延を起こして、お祭りの会場

RDBMSのボトルネックは99%ディスクI/Oにある。CPUや物理メモリに比べて、ハードディスクの速度はかなり遅い。気が遠くなるぐらい遅い。インデックスを効果的に設計すれば劇的にディスクI/Oコストを減らすことができる。 インデックスって何だ？まず簡単に基礎知識。インデックスには、クラスタ化インデックスと非クラスタ化インデックスがある。 大雑把に言えば、クラスタ化インデックスとはレコードデータ自体のディスク上での順序を表す。だから、テーブル毎に一つしか作れない。クラスタ化インデックスの順序が隣接しているという事は、データが物理的に隣接されてディスクに格納されているという事である。 SQL Serverは、データを「ページ」という概念で格納する。I/Oは全てこの8KBのページが最小単位である。レコードをたった一行取得する場合でもページ毎に読み出される。クラスタ化インデックスの順序が近いデータ

実行計画を取得する対象のクエリは、次のような予約の存在する店舗を選択するSELECT文です。 SELECT shop_name FROM Shops S INNER JOIN Reservations R ON S.shop_id = R.shop_id; 結合のアルゴリズム 一般的に、DBMSが結合を行うアルゴリズムは3種類あります。最も基本的でシンプルなのがNested Loopです。片方のテーブルを読み込み、その1つのレコードに対して、結合条件に合致するレコードをもう一方のテーブルから読み込みます。手続き型言語で書くと二重ループで実装するので、この名前があります。 2つ目は、Sort Merge[9]です。結合キー（今のケースでは店舗ID）でレコードをソートしてから、順次アクセスを行って2つのテーブルを結合します。結合の前処理として必ずソートを行うので、そのための領域を必要とします。

データベース管理者にとって今年の課題とは？ これからインパクトがある技術とは？ クロスプラットフォームの管理とクラウドでの運用 データベース管理者にとって、今年最大の課題は複数のプラットフォームに分散したデータベースの管理。これからの技術でもっともインパクトがあるのは、クラウド対応のデータベース。米エンバカデロ（旧ボーランド）が昨年、1000人以上のデータベース管理者や開発者を対象に行った調査で、このような結果が明らかになりました。 エンバカデロが公開した「Database Trends Survey」は、データベース管理者を中心に1230人以上の回答をまとめたもの。データベース管理者中心の調査はあまり聞いたことがありません。いまデータベース管理者がどのような状況に置かれているのかが分かる資料といえます。一部抜粋して紹介しましょう。 企業の重要なシステムはOracle、SQL Server

データベースには，「トランザクション分離レベル」というものがある。 以下では，それが なぜ必要なのか？ デフォルトのレベルでは，どうして駄目なのか？ PostgreSQLでは，どうやってレベルを変更・確認するのか？ などを取り上げる。 トランザクション分離レベル トランザクション分離レベルとは： 複数のトランザクションが同時に実行された場合に、他のトランザクションからの影響がどのくらい「分離」するか，のレベル。 ANSI規格では，４つのレベルがある。 READ UNCOMMITTED （一番低い） READ COMMITTED REPEATABLE READ SERIALIZABLE（一番高い） 徹底比較!! PostgreSQL vs MySQL　第３回：トランザクションの比較 http://thinkit.co.jp/free/article/060... トランザクション処理に詳しく

今回は、いわゆるMySQLでレプリケーションを行う方法を記してみます。非常に今更感がありますが、自分にとってかゆいところに手が届く文献がなかったので、自分でも一度まとめてみようと思いました。 【MySQLにおけるレプリケーションとは】 MySQLにおけるレプリケーションとは、マスターサーバでの更新情報がほぼリアルタイムにスレーブサーバに同期化される仕組みのことを指します。 マスターサーバ上で更新が起こると、バイナリログ(更新ログとも呼ばれる)に更新情報が記録されていきます。スレーブサーバは随時マスターサーバ上の更新情報を追いかけることでマスターサーバ上のデータをスレーブサーバ上で再現していきます。 レプリケーションにはシングルマスタ構成とマルチマスタ構成があり、通常はシングルマスタ構成を使います。シングルマスタ構成は1台のマスターサーバの下に複数台のスレーブサーバがぶらさがっているイメージ

DB管理者がいますぐ確認すべき3つの設定：真・Dr. K's SQL Serverチューニング研修（4）（1/3 ページ） 管理者の力量があらわれる3つの設定 前回、設定された値を見るだけでDB管理者の力量が見える、ということに触れました。今回も必ず押さえておきたいパラメータを、なぜそのように設定すべきかという理由と併せて解説していきます。 設定すべきポイントは大変シンプルです。 tempdbの数をCPUコア数にあわせよ x64環境なら「メモリ内のページロック指定」を変えよ OLTP環境では、並列処理の最大限度（Max DOP）はCPUコア数の「4分の1」に設定せよ もちろん、これだけ変更すれば、その部分における最低限のチューニングは完了します。しかし1つ上のエンジニアを目指すなら、その理由まできっちり知っておくべきでしょう。その理由を知ることで、監視ツールや動的管理オブジェクトが発する「