投稿

データ損失のリスクを軽減するための自動化の導入 (2022/08/29)

イメージ
データ損失のリスクを軽減するための自動化の導入 (2022/08/29) https://blogs.oracle.com/cloudsecurity/post/adopt-automation-to-help-reduce-the-risk-of-data-loss 投稿者: Niharika Kalra | Senior Product Marketing Manager, Cloud Platform データ損失、データ漏洩、データ侵害は、時々ぶつかるかもしれない言葉です。これらの用語は非常によく似ているため、互いに混同されることがあります。これらの用語の定義は若干重複しているかもしれませんが、全く異なる事象を指しています。情報漏えいとは、機密情報が不正にアクセスされたり、サイバー犯罪者に盗まれたりすることです。 従業員が日々の業務を遂行する上で、電子メールやクラウドベース・プラットフォーム、アプリケーションを通じて互いに情報を交換することが増えています。ビジネス目標を達成し、新たなビジネスチャンスを発見し、競争優位を獲得するためには、データの共有が不可欠になっています。しかし、デジタルデータの共有には、情報漏えいのリスクも伴います。 データ損失は、生産性やスケジュールを後退させ、企業が顧客を失う原因になることがあります。データ損失の不便さは、大量のデータが失われた場合、ビジネスにとって さらに大きな影響 を与える可能性があります。     深刻なデータ損失を経験した企業の94パーセントは回復していません。     51%の企業がデータ損失から2年以内に倒産しています。     43%の企業が再起不能に陥っています。     小規模企業の70%は、大規模なデータ損失の発生から1年以内に倒産しています。 データ損失を防ぐために、企業はクラウドサービスに注目している データ損失の最も一般的な理由の1つは、安全対策が不十分であること、または安全対策が失敗していることです。災害が発生し、フェイルオーバーシステムやバックアップが影響を受けた場合、企業はデータを復元する手段を失うことになります。 企業は、クラウドサービスやアプリケーションの柔軟性、拡張性、耐障害性を活用し、進化するビジネス環境...

Oracle CloudでAPEXを始める - QuickStart (2022/08/29)

イメージ
Oracle CloudでAPEXを始める - QuickStart (2022/08/29) https://blogs.oracle.com/apex/post/getting-started-with-apex-on-oracle-cloud-quickstart 投稿者: Toufiq Mohammed | Senior Product Manager - Oracle APEX Oracle Cloud InfrastructureのQuickstartsは、個々のOCIリソースの導入や設定に必要なすべての手順(データベース名、表示名、ワークロード・タイプ、インフラストラクチャ(共有または専用)、ライセンス・タイプなどの定義)を自分で行うことなく、テナントに必要なOCIリソースを自動的に導入できる方法を提供するものです。これらは、Free Tierまたはトライアルアカウントを含む、OCIアカウントですぐに立ち上げることができる完全なソリューションです。 このブログ記事は、 APEX on Autonomous Databaseブログ・シリーズ の一部であり、APEX Quickstartを使用してAutonomous Database上にローコード・アプリをデプロイする方法を使用して、Oracle APEX on OCIを開始する方法を学習します。このクイックスタートでは、Terraform を使用して Autonomous Database 上に APEX インスタンスをデプロイします。 前提条件     Oracle Cloud Infrastructureのアカウント:Oracle Cloudアカウントをまだお持ちでない方は、30日間の無料トライアルアカウントに登録することができます。詳しくはこちら: https://www.oracle.com/in/cloud/free/     OCIコンパートメント:Oracle Cloudアカウントには、テナント(rootコンパートメント)とManagedCompartmentForPaaS(Oracle Platformサービス用にOracleが作成)の2つのコンパートメントが事前に設定されています。     ログインしたユーザーは、このコンパー...

LoggingサービスによるOCIでAuditdのログを利用 (2022/08/29)

イメージ
LoggingサービスによるOCIでAuditdのログを利用 (2022/08/29) https://learnoci.cloud/use-auditd-logs-in-oci-with-logging-service-5caa13719315 投稿者: Birzu Alexandru-Adrian ログは重要です。ログが適切に設定されていれば、通常は見逃す可能性のある情報を提供することができるからです。Windowsインスタンスでは、通常のイベントの他に、Windowsログを充実させるために Sysmon を使用するのが私のお気に入りです。 auditdとOCI Loggingの設定を始める前に読むことをお勧めするブログの1つは、.NET Frameworkを提供しています。     Linux監査システムのクイック・イントロダクション     監査ルールを作成する際のヒント     セキュリティ監視のための設定     auditdで何を記録するか     ノイズを管理するためのヒント Linux auditd for Threat Hunting [パート1]|IzyKnows|Medium| 監視できるAuditdのイベントに関連して、以下のリストを確認することができます。 Audit Event Fields - bfuzzy/auditd-attack Wiki - GitHub とredhat OS Audit Record Typesの2種類があります。 B.2. 監査記録の種類 Red Hat Enterprise Linux 6|Red Hat Customer Portal 第7章 システム監査 システム監査 Red Hat Enterprise Linux 7 | Red Hat Customer Portal 第14章 システムの監査 システムの監査 Red Hat Enterprise Linux 8 | Red Hat Customer Portal 第12章 システムの監査 システムの監査 Red Hat Enterprise Linux 9 | Red Hat Customer Portal OracleLinux (OL) は Re...

OIC integrationの一括移行 (2022/08/29)

イメージ
OIC integrationの一括移行 (2022/08/29) https://blogs.oracle.com/cloud-infrastructure/post/migrate-oic-integrations 投稿者: Gaurav Aneja この投稿では、OIC REST APIを使用して、すべてのOracle Integration Cloud(OIC)Integrationをある環境から別の環境に移行する方法を説明します。移行プロセスを監視し、移行プロセス中に発生した問題を特定することができます。 クローンユーティリティのREST APIを使用することで、以下の例のように移行することができます。     Integration     コネクション     パッケージ     ライブラリ     証明書     ルックアップ オンプレミスシステムに接続するための接続エージェントがある場合、ターゲットインスタンス上で手動で設定する必要があります。 前提条件     両方のインスタンスで管理者権限を持つOICサービス     作成と更新のアクセス権限を持つ認証局(CA)クラウドストレージコンテナ     PostmanのようなAPIコールを実行するツール 移行の手順 このブログ記事では、次のステップを説明します。     OCIソース環境にOracle Cloud Infrastructure (OCI) Object Storageバケットを作成     REST API を使用してストレージ・コンテナにアクセスするための認証トークンを生成     エクスポートアーカイブ API を実行し、統合アーカイブをソース OIC インスタンスからストレージコンテナにエクスポート     統合アーカイブのエクスポートを検証     インポートアーカイブAPIを実行して、IntegrationアーカイブをターゲットOICインスタンスにインポート     ターゲット環境で...

異なるデータベースブロックサイズを持つCDB間でPDBを最小限のダウンタイムで移動する方法 (2022/08/29)

イメージ
異なるデータベースブロックサイズを持つCDB間でPDBを最小限のダウンタイムで移動する方法 (2022/08/29) https://database-heartbeat.com/2022/08/29/clone-pdbs-different-block-sizes/ はじめに Doc ID 2027614.1 にあるように、異なるデータベースブロックサイズを持つ CDB に PDB をプラグインすることは可能です。ターゲットのCDBバッファキャッシュがプラグインされるPDBのブロックサイズのバッファを持つように設定する必要があるだけです。これはターゲットCDBでdb_nk_cache_sizeデータベースパラメータを設定することで行われます。 しかし、アンプラグ/プラグにはダウンタイムが必要で、特に大規模なデータベースの場合、ネットワーク上でデータファイルを移動する必要があります。最近、PDBクローン、特にリフレッシュ可能なクローンが、異なるデータベースブロックサイズを持つCDB間でも動作するのかという疑問がわきました。 いくつか調べてみましたが、このような使用例に関する情報は見つかりませんでした。私は、プラグインが機能するように、クローニングも機能するものと思っていました。しかし、これまで何度、思い込んだことが間違いだと証明されたことでしょう。 そこで、試してみることにしました。 環境について Oracle Cloudで稼働している19cのデータベースで、データベースブロックサイズが8kのものをターゲットCDBとして使うことにします。 しかし、待ってください、異なるデータベースブロックサイズを持つソースCDBをどこで入手すればよいのでしょうか?Oracle Cloudのデータベースはすべて、デフォルトで推奨の8kブロックサイズになっています。考える...考える...考える...あ、DBCAというのがあった。最後に使ったのは、Oracleに入社して100%Cloudで仕事をする前の2018年のいつかのことでした。確かにGoogleで検索してみると、dbcaは$ORACLE_HOME/bin/の中にあることがわかりました。Linuxマシンに 表示転送の設定 をして、dbcaを実行しました。デフォルト以外のデータベースブロックサイズを指定するには、「高度な構成」と「...

MySQL HeatWave MLで機械学習モデルの学習を25倍高速化 (2022/08/29)

イメージ
MySQL HeatWave MLで機械学習モデルの学習を25倍高速化 (2022/08/29) https://blogs.oracle.com/mysql/post/train-your-machine-learning-models-faster-with-mysql-heatwave-ml 投稿者: Salil Pradhan | Principal Product Manager ML技術の急速な普及、爆発的なデータの増加、データサイエンスの専門家の不足により、業界では、速いペースで開発・展開されるモデルのライフサイクルに対応するため、ますます厳しい要求に直面するようになりました。様々なアプリケーション、デバイス、センサーなどから生成されるデータの量と速度の増加、およびリアルタイムの意思決定の必要性により、これらのデータを使用して構築される機械学習モデルの頻繁な変更が必要になっています。学習データと推論データの間のドリフトを管理するために、精度の高いモデルを生成し、変化するデータに対して常に最新の状態に保つ必要があります。このような迅速なモデル開発サイクルには、手動で生成したモデルに近い予測値を正確に生成するための、効率的で自動化されたMLパイプラインが必要です。 与えられたデータセットに適したモデルを特定するためには、最適なアルゴリズム、最適な行と特徴のセット、最適なアルゴリズムのハイパーパラメータを選択する必要があります。潜在的な組み合わせは何百、何千とあります。 従来のソリューションでは、様々なパイプラインの設定パラメータを最適化し、パラメータ間の依存関係を効果的に把握することでこの問題に対処してきました。このアプローチは反復的である傾向があり、多数のパイプラインの順列を評価する必要があるため時間がかかり、反復的なパイプラインは非現実的なものとなっています。 MySQL HeatWave ML の学習時間は、Redshift ML などの競合製品に比べ、平均で 25 倍の速さです。一部のデータセットでは、Redshift MLより数百倍も高速になります。MySQL HeatWave MLは、Redshift MLと比較して、クラスタサイズが大きくなっても、より良くスケールします。また、HeatWaveのML機能は、データベース内に組み込むことで実現...

Migration Workbenchを使った安全策を講じたOracle Databaseのマイグレーション (2022/08/27)

イメージ
Migration Workbenchを使った安全策を講じたOracle Databaseのマイグレーション (2022/08/27) https://blogs.oracle.com/observability/post/migrate-oracle-database-with-a-safety-net-using-migration-workbench 投稿者: Rajendra Patil | Product Manager 企業は、レガシーなOracle Databasesを新しいバージョンや新しいプラットフォームへ移行する道を歩んでいます。これらの新しいプラットフォームは、クラウドやExadata Engineered Systemsである可能性があります。アーキテクトと管理者は、これらのデータベースを最小限のダウンタイムで安全に移行し、移行後のデータベースがアプリケーションとシームレスに連携するためのパフォーマンスを確保するためのソリューションを求めています。 Enterprise Manager Database Migration Workbench は、新しいExadata、ExaCC、ExaCS、DBCS、Autonomousなどのさまざまな移行先に、データベースを迅速かつ安全に移行するのに役立ちます。移行は、移行元データベースに影響を与えることなく行うことができるため、移行プロセス中も完全に動作することを保証し、アプリケーションのダウンタイムを最小限に抑えることができます。 Migration Workbenchは、データベース全体、またはスキーマや必要なテーブルスペースのみを移行することができます。また、移行元データベースをマルチテナント環境へ移行することも可能です。 データベースを移行するビジネス上の3つの人気理由     Oracle Cloudへのワークロードの引き上げとシフト     マルチテナントアーキテクチャの標準化     新しいインフラストラクチャへの再プラットフォーム Migration Workbenchは以下を提供します。       REST APIまたは直感的なユーザーインターフェイスを使用したエンドツーエンドの自動化...