rink_rewさんの助け合いフォーラム投稿一覧
少し古い情報にはなりますが、私が受験した際にはテストセンターで受付済ませて試験を受ける部屋に入室する前に、厚紙をラミネートしたようなペラペラのホワイトボード代わりのシートと黒のマーカーが配布されました。
他の設問ですが26677の参考のNULLIF関数の説明部分に以下の記載がありました。
なお、第1引数にはリテラルのNULL値以外の値を指定しなければなりません。
上記のように第1引数にリテラルのNULL値は指定できませんが、第1引数で指定した列の値などが結果としてNULL値となる場合は問題ありません。
第1引数が結果としてNULL値となる場合は、第2引数がいかなる値であっても、NULL値が返されます。（第2引数がNULL値であれば等しいのでNULL値、第2引数がNULL値以外であれば等しくないので第1引数のNULL値が返される為）
実際にsalary列にnullが含まれるデータで、選択肢のSQLを実行した場合エラーにはなりません。
NULLIF関数の結果としてnullが返され、DECODE関数の条件と一致して、結果、「-」として表示されます。
SQL> select employee_id, employee_name, salary from employees where salary is NULL;
EMPLOYEE_ID EMPLOYEE_NAME SALARY
----------- -------------------- ----------
1017 渡辺和也
1018 塚本孝
1019 野口圭子
SQL> select employee_id, employee_name, NULLIF(salary, 500000) from employees where salary is NULL;
EMPLOYEE_ID EMPLOYEE_NAME NULLIF(SALARY,500000)
----------- -------------------- ---------------------
1017 渡辺和也
1018 塚本孝
1019 野口圭子
SQL> SELECT employee_id, employee_name, DECODE(NULLIF(salary, 500000), NULL, '-', salary) sal FROM employees;
EMPLOYEE_ID EMPLOYEE_NAME SAL
----------- -------------------- -------------------------
1001 山田二郎 -
1002 佐藤昭夫 -
1003 山口洋子 -
1004 田中浩介 -
1005 加藤昭彦 -
1006 佐々木明子 800000
1007 菊池浩二 800000
1008 中山大輔 400000
1009 星野健一 400000
1010 斎藤京子 400000
1011 吉田亜希 400000
1012 阿部伊吹 400000
1013 米村真司 350000
1014 伊藤佳奈 300000
1015 橋本淳 300000
1016 井上悦子 200000
1017 渡辺和也 -
1018 塚本孝 -
1019 野口圭子 -
1020 内田雄介 200000
1021 高田明 200000
1022 坂本真 200000
22行が選択されました。
このSQL文自体には特段問題はなく、言語環境の問題だと思います。
私はUTF8環境ですが、解説と同じ出力結果でした。
※検証用データの提供ページに「DBのキャラクタセットは「Unicode（AL32UTF8）」を想定」と記載されていたのでそれに従っていました。
問題文の冒頭で「実行環境は日本語とする」と言及しているのは、通貨記号「¥」が含まれているからですかね。
SQL> !echo $NLS_LANG
Japanese_Japan.AL32UTF8
SQL> select parameter, value from NLS_DATABASE_PARAMETERS where parameter = 'NLS_CHARACTERSET';
PARAMETER VALUE
-------------------- --------------------
NLS_CHARACTERSET AL32UTF8
SQL> SELECT TO_NUMBER('¥500,000.0', 'L999G999D0') FROM dual;
TO_NUMBER('¥500,000.0','L999G999D0')
------------------------------------
500000
試しに英語に変えてみると、ORA-01722のエラー（「数値が無効です」のエラー）が発生しました。
通過記号「¥」が一致しなくなるためだと思います。
SQL> !echo $NLS_LANG
American_America.WE8MSWIN1252
SQL> SELECT TO_NUMBER('¥500,000.0', 'L999G999D0') FROM dual;
SELECT TO_NUMBER('¥500,000.0', 'L999G999D0') FROM dual
*
ERROR at line 1:
ORA-01722: invalid number
余談ですが、「$」などとすればエラーは発生しません。
SQL> !echo $NLS_LANG
American_America.WE8MSWIN1252
SQL> SELECT TO_NUMBER('$500,000.0', 'L999G999D0') FROM dual;
TO_NUMBER('$500,000.0','L999G999D0')
------------------------------------
500000
すでに実際に試されているとおり、自己結合の場合にUSING句を使用してもエラーにはなりませんよね。
・USING句に結合条件を指定する
USING句は同じ名前の列のみを結合することができます。自己結合の実行例のように結合列に表接頭辞（表別名）を使用できないので、誤りです。
おそらくこの解説文で言いたいのは、USING句を用いる場合で「結合条件としての結合列に表接頭辞（表別名）を使用できない」ということだと思いますが、自己結合のクエリでUSING句に結合条件を指定する（表接頭辞を含まない列名を指定する）こと自体は不可能ではないので、この問題の選択肢として「USING句に結合条件を指定する」が「正しくない」とは言えないですよね。問題の修正をお願いしたいところです。
SQL> SELECT emp.employee_name, mgr.employee_name FROM employees emp JOIN employees mgr USING(emp.manager_id);
SELECT emp.employee_name, mgr.employee_name FROM employees emp JOIN employees mgr USING(emp.manager_id)
*
行1でエラーが発生しました。:
ORA-01748: ここでは修飾された列名は使用できません。
これは、上司の人はmanager_idを持たず、上司のいる従業員のmanager_id列に上司のemployee_idが入るという認識で合ってますでしょうか。
そうですね。その理解で良いと思います。
前提として「manager_id列に値が入っているレコードは、上司がいることを意味する」と判断しておく必要はありますが、実際の表データは見なくても問題は解けるかなと思います。
以下の2つの選択肢は構文エラーになるので除外。
・SELECT emp.employee_name, mgr.employee_name FROM employees emp NATURAL JOIN employees mgr;
・SELECT employee_name, mgr.employee_name FROM employees JOIN employees mgr ON manager_id = mgr.employee_id;
以下の選択肢は、同じ名前が表示されるだけなので、期待する結果（従業員名とその上司の氏名）にはならないと判断できる。
・SELECT emp.employee_name, mgr.employee_name FROM employees emp JOIN employees mgr USING (employee_id);
そして残りの2つについては、manager_id列に値を持つemployee_nameと、そのmanger_idに該当するemployee_nameが表示されるので、本設問で期待されている「従業員名とその上司の氏名」（と思われるもの）が表示されるので正答である、と判断はできないことはないかなと思いました。
・SELECT emp.employee_name, mgr.employee_name FROM employees emp, employees mgr WHERE emp.manager_id = mgr.employee_id;
・SELECT emp.employee_name, mgr.employee_name FROM employees emp JOIN employees mgr ON emp.manager_id = mgr.employee_id;
もし、運営さんに修正してもらうとしたら、「manager_id列に値が入ってるレコードは、その従業員に上司がいることを意味する」のような補足を問題文に追記してもらうぐらいでしょうか。
実際のSilver SQL 2019の試験問題で、どのような出題がされるかはなんとも言えないところですが...。
②は理由が分かりませんでした
(￥を記載したため？,文字として￥を記載するのはエラーにならないと思ったのですが…)
そうですね。第一引数の文字列として￥が含まれていること自体は問題ないので、エラーにもなりませんが、出力結果は期待したものにはなりません。
実際に実行してみると、出力結果は以下のとおり「500000」が出力されます。
TO_NUMBERはNUMBERに変換するので、出力結果として桁区切りのカンマや通貨記号は含まれません。
※第二引数で指定したフォーマットは、第一引数の文字列を数値に変換するにあたり、どう解釈すれば良いかの指定。
SQL> SELECT TO_NUMBER('¥500,000.0', 'L999G999D0') FROM dual;
TO_NUMBER('¥500,000.0','L999G999D0')
------------------------------------
500000
下記問題が×である理由の説明が記載されていないため、ご教授いただきたいです
Ping-tさんの問題集はたいてい不正解の選択肢についても説明が載ってるような気がするのですが、確かにこの問題にはないですね...なんででしょう...。
コミットだけでは飛ばされないと思います。共有プールがクリアされたりすれば、欠番が発生することになると思いますが。
SQL> create sequence seq01 cache 20;
順序が作成されました。
SQL> select seq01.nextval from dual;
NEXTVAL
----------
1
SQL> select sequence_name, last_number from dba_sequences where sequence_name = 'SEQ01';
SEQUENCE_NAME LAST_NUMBER
-------------------- -----------
SEQ01 21
SQL> select seq01.nextval from dual;
NEXTVAL
----------
2
SQL> commit;
コミットが完了しました。
SQL> select seq01.nextval from dual;
NEXTVAL
----------
3
SQL>
''（空文字/長さ0の文字値）はNULLとして扱われるので、
- =での比較はできない (結果がUNKNOWNとなる)
- NULLを検索したければ、IS NULL / IS NOT NULL を使用しなければならない。
ということですね。「WHERE yomi = ''」では、NULLを=で検索することになります。
確かにOracleのNULLの扱いはクセがあると言えるかもしれませんが、参考URLに記載のマニュアルに以下のとおり記載されてますので。
NULLを検査するには、比較条件IS NULLおよびIS NOT NULLのみを使用します。NULLを他の条件で使用して、その結果がNULLの値に依存する場合、結果はUNKNOWNになります。
SELECT文のWHERE句でUNKNOWNと評価される条件が使用された場合、その問合せに対して行は戻されません。
成立しますね。SELECT文のとおり、並び替えられた上で上位15%（この問題の例であれば4行）が返されます。
ping-tさん提供のサンプルデータで、salaryの85%をnullにして試した結果は以下のとおりです。
SQL> SELECT employee_id, employee_name, salary FROM employees ORDER BY salary DESC NULLS LAST;
EMPLOYEE_ID EMPLOYEE_NAME SALARY
----------- ------------------------------ ----------
1003 山口洋子 500000
1002 佐藤昭夫 500000
1001 山田二郎 500000
1007 菊池浩二
1008 中山大輔
1009 星野健一
（中略）
22行が選択されました。
SQL> SELECT employee_id, employee_name, salary FROM employees ORDER BY salary DESC NULLS LAST FETCH FIRST 15 PERCENT ROWS ONLY;
EMPLOYEE_ID EMPLOYEE_NAME SALARY
----------- ------------------------------ ----------
1003 山口洋子 500000
1002 佐藤昭夫 500000
1001 山田二郎 500000
1007 菊池浩二
RPADやLPADの第2引数は「表示される全体の長さ」で、第1引数の文字列の長さが第2引数で指定された長さよりも長い場合には、第2引数で指定された長さまでのみ表示され、残りは切り捨てられます。
SUBSTR(cust_postal_code, INSTR(cust_postal_code, '-'))
→ 「-0063」※長さ 5
LENGTH(cust_postal_code) - INSTR(cust_postal_code, '-')
→ 8 - 4 = 4
第一引数の文字列の長さ「5」、第2引数で指定された長さ「4」で、第一引数の方が長いため、RPADの結果は長さ4まで（「-0063」のうち「-006」まで）が表示されることになります。
参考URLのマニュアルだと、以下の部分ですね。
expr1がnより長い場合、このファンクションはnに収まるexpr1の一部を戻します。
あと、この問題の解説には書いてなかったのですが、他の問題(ID:26812)の解説に以下の記述がありました。
RPAD関数やLPAD関数の引数に指定された文字列が、長さで指定されたサイズよりも長い場合、次のように指定されたサイズ分の文字列が表示されます。
ping-tさん提供の検証用データがあります。スクリプト形式で提供されているので、問題集で実行されているSQLはすぐに試せますよ。
https://ping-t.notion.site/Ping-t-Silver-SQL-6f833fb434994343bcc338233e058bb2
本件も、実際に実行してみれば一発でわかります。
SQL> CREATE SEQUENCE seq_id MAXVALUE 100;
順序が作成されました。
SQL> CREATE TABLE list (id NUMBER(3) DEFAULT seq_id.NEXTVAL PRIMARY KEY, name VARCHAR2(10));
表が作成されました。
SQL> GRANT SELECT, INSERT ON list TO userA;
権限付与が成功しました。
SQL> conn userA
パスワードを入力してください:
接続されました。
SQL> SELECT * FROM pingt.list;
レコードが選択されませんでした。
SQL> INSERT INTO pingt.list (name) VALUES ('Sato');
INSERT INTO pingt.list (name) VALUES ('Sato')
*
行1でエラーが発生しました。:
ORA-01031: 権限が不足しています
SQL> conn pingt
パスワードを入力してください:
接続されました。
SQL> GRANT SELECT ON pingt.SEQ_ID to userA;
権限付与が成功しました。
SQL> conn userA
パスワードを入力してください:
接続されました。
SQL> INSERT INTO pingt.list (name) VALUES ('Sato');
1行が作成されました。
SQL> SELECT * FROM pingt.list;
ID NAME
---------- ----------
1 Sato
SQL>
同じ結果になります。実務的には、時なら1/24、分なら1/1440の表記を使うことが多いような気がします。パッと見て分かりやすいので。
SQL> select to_date('12-01-01') from dual;
TO_DATE('12-01-01
-----------------
12-01-01 00:00:00
SQL> select to_date('12-01-01') +12/24 from dual;
TO_DATE('12-01-01
-----------------
12-01-01 12:00:00
SQL> select to_date('12-01-01') +1/2 from dual;
TO_DATE('12-01-01
-----------------
12-01-01 12:00:00
過去にも同じ質問があったようです。
https://mondai.ping-t.com/g/posts/603
INSERT時は範囲外の値をセットすると「範囲外の値は入力できない（エラー）」となりますが、UPDATE時は更新指示自体がエラーになるのではなく「処理を実行した結果0件でした」となるのだよ、という違いですね。_
ちなみに、ping-tさん提供のテストデータで実際に実行してみた結果は以下のとおりです。
SQL> select * from v_emp;
DEPARTMENT_ID EMPLOYEE_ID EMPLOYEE_NAME SALARY
------------- ----------- ------------------------------ ----------
1 1001 山田二郎 500000
1 1008 中山大輔 400000
1 1013 米村真司 350000
SQL> UPDATE v_emp SET salary = 500000 WHERE department_id = 3;
0行が更新されました。
SQL> select * from v_emp;
DEPARTMENT_ID EMPLOYEE_ID EMPLOYEE_NAME SALARY
------------- ----------- ------------------------------ ----------
1 1001 山田二郎 500000
1 1008 中山大輔 400000
1 1013 米村真司 350000
SQL>
私は新体系の試験にはあまり詳しくないのですが、以下のサイトで試験範囲の比較情報が出ておりました。
[FAQ] 新Silver DBAとSilver SQLのどちらを受験すべきか？
https://cosol.jp/techdb/2022/06/faq_new_oracle_master_silver_dba_silver_sql_2/
何割程度被るかということはわかりませんが、こちらをみる限りでは、Silver SQLの知識をもっていればSilver DBAの「SQL範囲」はカバーできそうですので、もしSilver SQLの学習から日が経ってしまい内容を忘れてしまったという場合には、Silver SQLの復習をすれば良さそうです。
また、同じブログにて以下のような記事もあがっていました。
[FAQ] 新Bronze DBAと新Silver DBAのどちらから受験すべきか？
https://cosol.jp/techdb/2022/06/faq_new_oracle_master_bronze_dba_silver_dba/
Bronze DBA合格している方であれば、Silver DBAの学習にもスムーズに入っていけそうなことが書かれていますので、もし、実務でOracle Databaseまたはその他データベースに日々触れているという状況でない場合には、せっかくなのでBronze DBAの知識を忘れてしまう前に、一気にSilver DBAまでやり切ってしまうのもアリかもしれませんね。
どちらの手順も、結果としてやっていることは同じだと思います。
Ping-tの説明では、最初に ALTER SYSTEM 文で初期化パラメータ「CONTROL_FILE」を編集していますが、解説にも記載のとおり「CONTROL_FILE」は静的パラメータなので、SCOPE=SPFILEを指定して、spfileだけを変更しています。
つまり、この時点で稼働中のインスタンスには何の影響もありません。変更内容が反映されるのは、次回の起動時です。
重要なのは、制御ファイルをコピーするタイミングで、これについてはping-tの手順でも公式ドキュメントの手順でも、インスタンスが停止した状態で、OSコマンドで制御ファイルのコピーを行っています。あとは、起動すれば初期化パラメータ「CONTROL_FILE」の変更内容も反映されます。
Ping-tさん提供の検証用データで試してみましたが、結果は以下の通りエラーとはなりませんでした。
SQL> SELECT employee_id, employee_name, salary FROM employees WHERE department_id IN (SELECT department_id FROM departments WHERE department_name = '開発') OR salary >ANY (SELECT MIN(AVG(salary)) FROM employees GROUP BY department_id);
EMPLOYEE_ID EMPLOYEE_NAME SALARY
----------- ------------------------------ ----------
1001 山田二郎 500000
1002 佐藤昭夫 500000
1003 山口洋子 500000
1004 田中浩介 500000
1005 加藤昭彦 500000
1006 佐々木明子 800000
1007 菊池浩二 800000
1008 中山大輔 400000
1009 星野健一 400000
1010 斎藤京子 400000
1011 吉田亜希 400000
EMPLOYEE_ID EMPLOYEE_NAME SALARY
----------- ------------------------------ ----------
1012 阿部伊吹 400000
1015 橋本淳 300000
13行が選択されました。
SQL>
参考までに、以下は整形したSQL文ですが、特に余計な括弧はなさそうです
SELECT
employee_id,
employee_name,
salary
FROM
employees
WHERE
department_id IN (
SELECT
department_id
FROM
departments
WHERE
department_name = '開発'
)
OR salary > ANY (
SELECT
MIN(AVG(salary))
FROM
employees
GROUP BY
department_id
);
何故ビューの列にデフォルト値を設定できないのかが分かりません。
この問題の解説部分にも記載の構文の通り、そもそも CREATE VIEW で ビュー名の直後に記述できる列名は、あくまでもビューで使用する列名（列の別名）というだけなので、DEFAULT値云々は元のテーブル側での話となります。
したがって、1番目のSQL文は構文エラーになるため、選択肢「1番目はEMP_VIEWビューの列にデフォルト値を設定できないのでエラーとなる」は正になるかなと思います。
私は古いバージョンのOracle Masterしか持っておらず、実際にこのような問題が実際のBronze DBA 2019試験で出題されるかどうかまではわからないのですが、Ping-tさんの合格体験記などをみてみると、合格された方々の感触として実試験の難易度は黒本よりは高いと言えそうですので、余力があれば、今回の問題についても解説や参考に記載の内容は覚えておいて損はないかもしれません。
Oracle Master Bronze DBA 2019 は DBA カテゴリの試験なので、あまり突っ込んだSQL文が出題されることはないのではないかな、とは思いますが、「デフォルト値」については「表」に関する問題の参考部分に以下の記述がありましたので、参考までに。
【表の作成】
*SQL文での表の作成
CREATE TABLE文を使用します。CREATE TABLE [スキーマ名.]表名
(列名 データ型(サイズ) [DEFAULT デフォルト値] [[CONSTRAINT 制約名] 制約タイプ]
[, 列名 データ型(サイズ)...]
) [TABLESPACE 表領域名];・DEFAULT
行の挿入時に値が指定されていない場合のデフォルト値を指定します。
CREATE TABLE で表を作成する際に、カラムに「DEFAULT」句を指定することで、デフォルト値を設定できます。
INSERT文でデータを挿入する際に、そのカラムに対して値を指定しなかった場合に、設定したデフォルト値が割り当てられる、というものです。
解説にも記載されている「マルチアタッチ」を想定した選択肢なのかなと思いました。
（※）一部のボリュームタイプでは複数インスタンスからのアタッチが可能な「マルチアタッチ」機能に対応しています。ただし、利用できるインスタンスタイプやリージョンが限られているなどの制限事項があります。
マルチアタッチは、どのような環境でも使用できるわけではないので、実運用環境としてどのようなユースケースがあるのか微妙なところではありますが、以下のように公式情報でも同時にアタッチできることが述べられているので、「1つのEBSボリュームは1つのEC2インスタンスからしかアタッチできない」と言いきってしまうと嘘になってしまいます。
https://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/ebs-volumes-multi.html
https://aws.amazon.com/jp/about-aws/whats-new/2020/02/ebs-multi-attach-available-provisioned-iops-ssd-volumes/
ですので、設問の選択肢としては妥当かなと思いました。
周回を重ねるごとに正答率が上がってるのはとても良い状況だとおもいます。
３週目以降、間違えた問題のみ集中して解いて復習し、間違える問題がなくなってきたら仕上げに再度全問を通してみると良いかもしれません。
模試は80%程度は取れるようにはしておいた方が当日安心だと思いますので、時間の許す限り周回を繰り返すと良いかなと思います。
最後の仕上げ、頑張ってください。
概ねご認識の通りだと思います。
ただ、物理的か論理的かという話で分けてしまうと、若干誤解があるかもしれません。
領域は物理的なデータを格納する場所で、そこには様々なユーザの実際の表データが格納されている。
一方で、スキーマはユーザごとに論理的にデータを区別するための概念であり実際のデータは領域に格納されている。
表領域は、一つ以上のデータファイルから構成される論理的な領域で、オブジェクトの格納先として指定する場所。（正確には、表や索引の物理的な格納場所はデータファイル）
- データファイルの概念は、OSレベルで物理的
- 表領域の概念は、Oracleレベルで論理的
私はこんな感じで理解しております。
解説に記載されている以下内容の通りかなと思います。
WHERE句に条件が複数指定されている場合は、論理演算子の優先順位に従って条件が評価されます。
AND演算子とOR演算子ではAND演算子のほうが先に評価されますが、()括弧がある場合は、括弧内の演算子を優先して評価します。
設問では「(department_id = 3 OR salary > 400000)」の部分が先に評価され、次にANDですので、「DEPARTMENT_ID列が3かSALARY列が400000より大きく、かつCOMMISSION列が1200000以下である」列（E）、または、「HIREDATE列が2008年4月1日より大きい（新しい）」列（B,C）が検索されます。
実際に実行すると、確かに「C」のレコードは表示されます。
SQL> select department_id, salary, commission, hiredate from employees where (department_id = 3 or salary > 400000) and commission <= 1200000 or hiredate > '2008-04-01';
DEPARTMENT_ID SALARY COMMISSION HIREDATE
------------- ---------- ---------- --------
3 400000 1200000 02-12-01
5 400000 800000 10-04-01
1 350000 800000 11-04-01
2 300000 800000 10-04-01
3 300000 800000 09-12-01
4 200000 800000 10-04-01 <--- C
~~~ 以下略 ~~~
記載いただいた以下の内容がChatGPTの回答でしょうか。
提供された行が条件にマッチしない理由は、条件 (department_id = 3 OR salary > 400000) AND commission <= 1200000 OR hiredate > '2008-04-01' に対して、以下の評価結果です
department_id = 4 は条件 (department_id = 3 OR salary > 400000) にマッチしません。
salary > 400000 もマッチしません。
commission <= 1200000 もマッチしません。
hiredate > '2008-04-01' もマッチしません。
以上の理由から、提供された行は条件式全体を満たさないため、マッチしません。条件内で指定されている条件に対して、department_id が 4 であることや他の列の値が具体的な値を持っていることは影響しません。
どのようなプロンプトを投げたかわからないので何とも言えませんが、「C」の選択肢は「hiredate > '2008-04-01'」の条件にマッチすると思います。
私も試しにChatGTPに質問してみました。最後の説明文がわかりやすいかなと感じました。
まず、SQLのWHERE句の条件式の評価の順序を理解する必要があります。AND、OR、NOTなどの論理演算子の優先順位は以下のようになっています：
1. NOT
2. AND
3. OR
上記のSQL文において、WHERE句の条件式は以下のように括弧を使って明確に示されています：
1. (department_id = 3 OR salary > 400000)
2. AND commission <= 1200000
3. OR hiredate > '2008-04-01'
この条件式の評価の順序を考慮すると、次のようなステップで評価されます：
1. 最初に括弧内の条件が評価される。すなわち、department_idが3のレコード、またはsalaryが400000を超えるレコードが該当します。
2. 次に、上記の結果の中からcommissionが1200000以下のレコードが選ばれます。
3. 最後に、hiredateが'2008-04-01'よりも新しいレコードが上記の条件に関係なく選ばれます。
そのため、結果として返されるレコードは以下の3つの条件のいずれかを満たすものになります：
1. department_idが3で、salaryが任意、commissionが1200000以下のレコード。
2. salaryが400000を超え、commissionが1200000以下のレコード。
3. hiredateが'2008-04-01'よりも新しいレコード。
注意点として、OR条件はAND条件よりも優先順位が低いため、上記のSQL文を実行すると、hiredateの条件は他の条件とは独立して評価される点に注意してください。
環境構築については、Oracle Master Bronze DBA 2019(1Z0-085)のWeb問題集のトップページに、「環境構築手順のご紹介」というリンクがあるので、その内容に従うと良いかもしれません。
あと、VirtualBox上のLinuxにOracle Database 19cを導入する手順について、とても良くまとまったブログ記事がありましたので、参考までに載せておきます。※記事はLinuxにインストールしてますが、インストールイメージのダウンロードからVMの作成、インストーラーのGUI画面も載っていて、ステップバイステップで書かれているので参考になると思います。
VM作成からのOracle 19cインストール手順 前編（Linuxシングル）
https://cosol.jp/techdb/2021/06/oracle19c_setup_1of2/
VM作成からのOracle 19cインストール手順 後編（Linuxシングル）
https://cosol.jp/techdb/2021/06/oracle19c_setup_2of2/
ちなみに、上記のブログでも言及されていますが、学習目的であれば無償版の「Oracle Database Express Edition」を使用する必要はないようです。（OTNライセンス）
私がOracle Masterを取得したのはもう何年も前の話にはなりますが、
- Oracle Master 教科書（黒本と呼ばれるやつ？）の内容は読み込んでおさえておく。
- Ping-tのWeb問題集は何周もする。解説や参考も面倒くさがらずに読む。
- 黒本やWeb問題集の内容については、可能な限り実機でも動きを確認しておく。
あたりが、自分の学習方法でした。
あと、欲を言えば、黒本やWeb問題集でよく理解できなかった部分などは、Oracleのマニュアルも参照してみるのが良いと思います。
※公式マニュアルは、慣れないうちは読みにくいかもしれませんが、もし将来的に実際の業務でOracle Databaseを使用するようになったら、マニュアルとは嫌でも付き合っていくことになると思うので、その準備も兼ねて慣れておくといいかもしれません。
学習頑張ってください。合格されることを願っております。