myVertica  

Vertica Blog

Introducing the Vertica ML-Python Library

This blog post was authored by Soniya Shah. One of the coolest things about working at Vertica is our amazing intern program, which often leads to full-time hires. Last year, the Vertica-ML-Python library, also known as vpython, was started as an internship project by Badr Ouali. A year later, he works for Vertica full time […]

Be Careful with the Sequence CACHE Value

Jim Knicely authored this tip. The default session cache for a sequence is 250,000. Although you can change the cache value of a sequence, setting the value too low can adversely affect performance! Example: dbadmin=> SELECT COUNT(*) FROM ten_thousand_records; COUNT ——- 10000 (1 row) dbadmin=> CREATE SEQUENCE default_cache; CREATE SEQUENCE dbadmin=> CREATE SEQUENCE non_default_cache CACHE […]

Faster CTAS Statements: Quick Tip

Jim Knicely authored this tip. In a CREATE TABLE statement, you can specify an AS clause to create a table from a query (a.k.a. CTAS statement). When dealing with a large SELECT statement result set, your CTAS should perform much better if you specify the DIRECT load method! Example: dbadmin=> SELECT TO_CHAR(COUNT(*), ‘999,999,999,999’) row_count FROM […]

Analyze Statistics at the Schema Level (Part 2): Quick Tip

Jim Knicely authored this tip. The ANALYZE_STATISTICS function only accepts a table/projection/column name as input. In yesterday’s Vertica Quick Tip we learned how to get Vertica to generate and execute ANALYZE_STATISTICS SQL statements, one for each table in a given schema. It was an okay solution, but not very convenient. A better option would be […]

Analyze Statistics at the Schema Level (Part 1): Quick Tip

Jim Knicely wrote this tip. The ANALYZE_STATISTICS function collects and aggregates data samples and storage information from all nodes that store projections associated with the specified table. The function accepts a table/projection/column name as input. What if you wanted to get stats for all of the tables in a schema? One option is to have […]

Verticaのアップグレード方法

Verticaは、すべてのリリースで、新しい機能を追加し既存の機能を強化します。新機能あるいは改良された機能を使用するには、Verticaを最新リリースにアップグレードしてください。 前提条件 アップグレードする前に、次の手順を実行します。 データベースのフルバックアップを実行します。アップグレードが成功しなかった場合、フルバックアップで現在のバージョンにロールバックすることができます。ハードリンクでのバックアップの取得を検討可能です。ディスク障害が発生すると、バックアップが破損することに注意してください。 新しいバージョンのプラットフォーム要件を確認します。 カタログ用のストレージスペースを確認します。 HDFSコネクタをアンインストールします(Vertica 7.2.xより前のバージョンからアップグレードする場合のみ必要です)。 vertica-R-langなどのVerticaサーバーパッケージと依存関係のあるものについても、アンインストールを実施します。 最高のパフォーマンス結果を得るために、すぐに次のバージョンにアップグレードすることをご推奨します。 例:次の増分バージョンのVerticaにアップグレードします。たとえば、7.1から7.2または8.0から8.1にアップグレードします。詳細については、Vertica Documentation の Upgrade Paths を参照してください。 これらのタスクの完了後、データベースをシャットダウンし、次の手順を実行します。 ステップ タスク 結果 1 既存のデータベースの完全なローカルバックアップを取得し、データベースを停止します。 $ /opt/vertica/bin/admintools -t stop_db -d db-name バックアップが成功した場合、Step 2 に進みます。 バックアップが失敗した場合、Vertica Documentation の Creating Full Backups を参照してください。 2 各ホストにインストールした追加のパッケージをアンインストールします。 rpm -e vertica-package-nameこの手順を省略し、追加のパッケージをアンインストールしない場合、次のステップでVerticaサーバーパッケージのインストールに失敗します。 アンインストールが成功した場合、Step 3 に進みます。 アンインストールが失敗した場合、エラーを確認し、Verticaテクニカルサポートまでお問い合わせください。 3 任意のホストに新しいVerticaサーバーパッケージをrootまたはsudoでインストールします。 # rpm -Uvh pathname $ sudo […]

新規ノードをクラスターに追加する場合の対処方法

より多くのストレージを必要としますか?追加のストレージが必要な場合、データベースにノードを追加することを検討してください。新しいノードは、すべて同時に追加することをご推奨します。 このチェックリストを使用して、ノードを追加することができます。これらは基本的なステップです。Vertica Documentation には、追加のオプションが掲載されています。 ステップ タスク 結果 1 既存のデータベースの完全なローカルバックアップを取得します。 $ vbr -t backup –config $FULLBAK_CONFIGデフォルトでは、進行状況バー以外の出力は表示されません。追加の進行状況情報を含めるには、1-3の間の値が指定可能な「–debugオプション」を使用します。 バックアップユーティリティを実行している際にconfigファイルを指定します。 ファイルが存在しない場合、バックアップはエラーで失敗します。エラーを解決し、Step 2 に進みます。 2 古い、あるいは、未使用のテーブルパーティションを削除します。 => SELECT DROP_PARTITION(table-name, partition value); テーブルパーティションが削除された場合、Step 3 に進みます。 テーブルパーティションが削除されていない場合、テーブル名とパーティションの値を確認して、もう一度やり直してください。 3 ローカルセグメンテーションが無効であることを確認します。無効になっていない場合、無効にします。 => SELECT DISABLE_LOCAL_SEGMENTS(); ローカルセグメンテーションが無効になっていることを確認後、Step 4 に進みます。 4 クラスターのネットワーク帯域幅とCPUパフォーマンスを確認します。 $ /opt/vertica/bin/vnetperf $ /opt/vertica/bin/vcpuperf ノード間のネットワークのレイテンシとスループットを測定し、ハードドライブの速度を測定します。 レイテンシとスループットが初期ベンチマークよりも低い場合、システム管理者に連絡し、性能劣化の問題を解決してください。 5 リバランスを実行するのに十分なストレージ(データベースのサイズの少なくとも40%)があるかどうかを確認します。 各ノードのスナップショットを取得するには、HOST_RESOURCESシステムテーブルの次のフィールドを確認します。 => SELECT host_name, disk_space_used_mb, disk_space_total_mb disk_space_free_mb FROM host_resources; 各ノードのディスクストレージの容量がリバランスを実行するのに十分であることを確認します。十分である場合、Step […]

AHM(Ancient History Mark)が進まない場合の対処方法

AHMが進んでいない場合、次のチェックリストを使用してトラブルシューティングを行います。 ステップ タスク 結果 1 Last Good Epoch(LGE)が進んでいるかどうかを確認します。 => SELECT CURRENT_EPOCH, LAST_GOOD_EPOCH, AHM_EPOCH FROM SYSTEM; LGEが進んでいる場合、Step 2 へ。 LGEが進んでいない場合、Step 5 へ。 2 すべてのノードがUPしているかどうかを確認します。 => SELECT * FROM NODES WHERE NODE_STATE = ‘UP’; すべてのノードがUPの場合、Step 3 へ。 1つ以上のノードがDOWNの場合、下記コマンドを使用してすべてのノードをUPにします。 $ admintools -t restart_node -d <database name> -s <node_name> すべてのノードがUPになった後、Step 4 へ。 3 リフレッシュが実行されていないプロジェクションがないかどうか確認します。 => SELECT PROJECTION_NAME, NODE_NAME, IS_UP_TO_DATE FROM PROJECTIONS WHERE IS_UP_TO_DATE […]

メンテナンスのためにVerticaノード停止する場合の対処方法

メンテナンスのためにVerticaノードをシャットダウンする必要がある場合、このチェックリストが役立ちます。 ステップ タスク 結果 1 すべてのノードがUPであることを確認します。 $ /opt/vertica/bin/admintools -t view_cluster シャットダウン後の長時間にわたるノードリカバリを避けるには、1つ以上のノードが停止している場合、Restarting Vertica on a Host 内の説明にしたがって、なるべく早く検知し、再起動します。 2 ノードを再起動できない場合、 AHMが長い間進んでいないかどうか確認します。 => SELECT current_epoch, ahm_epoch, last_good_epoch FROM system; デリートベクター数を確認します。 => SELECT COUNT(*) FROM delete_vectors; AHMが長時間保持されていて、デリートベクター数が多く、また、複数のテーブルにまたがっている場合、ノードリカバリが遅延する可能性があります。 この場合、ノードリカバリのチェックリスト内の手順に従います。 次の内容があてはまるとします。 データの3%以上に影響を与える削除や更新を行っています。 ノードが長い間停止しています。 多くの更新と削除を行うステージングテーブルがある場合、ノードをリカバリする前にテーブルを削除します。 最後の選択肢は、次のコマンドでAHMを強制的に進めることです。 => SELECT MAKE_AHM_NOW(true); 続いて、停止ノードをリカバリすると、Verticaはバディーノードからデータをコピーすることによって、そのノードを初期状態からリカバリします。 3 ノードの依存関係を確認します。 => SELECT GET_NODE_DEPENDENCIES(); 想定するノード依存関係の場合、(ノードの数 + 1)行をリストします。 ノードの依存関係が正しい場合、Step 4 へ。 ノードの依存関係が正しくない場合、クラスター内のデータをリバランスします。 => […]

ノードのリカバリ処理遅延の対処方法

7.2.x以降を使用している場合、テーブルごとにリカバリを実行してください。詳細については、Vertica Documentation の Recovery By Table を参照ください。 7.1.xより前のVerticaバージョンを使用している場合、ETLジョブ等の更新処理を行う処理を停止してノードリカバリを再開してください。 ステップ タスク 結果 1 リカバリの進捗状況をモニターします。 => SELECT node_name, is_running FROM RECOVERY_STATUS;「is_running = f」 の場合、リカバリは完了しています。 このステートメントを繰り返し実行し、current_completedの値が増加しているかどうかを確認します。増加している場合、リカバリが進行中であることを意味します。 リカバリは進行中ですか? リカバリが進行していない場合、Step 3 へ。 リカバリが進行している、あるいは、終了している場合、Step 2 へ。 2 ノードリカバリは正常に完了しましたか? 正常に完了している場合、チェックリストは完了です。 正常に完了しておらず、リカバリがエラーで終了している場合、Step 6 へ。 3 リカバリは予想よりも遅いですか? 遅くない場合、Step 4 へ。 遅い場合、次の内容を実施します。 iostatを使用し、ディスクI/Oをチェックします。問題がある場合、ディスクI/Oスケジューラをdeadline(HDDの場合)あるいはnoop(SSDの場合)に変更します。 同時に実行されているクエリの数が最大数、あるいはそれに近いかどうかを確認します。=> SELECT node_name, pool_name, max_concurrency, running_query_count from RESOURCE_POOL_STATUS; 「max_concurrency = running_query_count」の場合、クエリのロードが非常に高いと言えます。 a. MAXCONCURRENCY の増加 b. リカバリの再開 c. […]