I don't believe so. The checksum itself is written into the file, so I'm not sure you could test it externally to the import, since by writing the checksum to the file, you've actually altered the checksum. :)
Hello Tim, I am getting the below errors when running vagrant up for node1. any suggestions on the errors. ? default: Installed: default: cvuqdisk-1.0.10-1.x86_64 default: default: Complete! default: ****************************************************************************** default: Do grid software-only installation. Tue May 28 18:41:51 UTC 2024 default: ****************************************************************************** default: Preparing the home to patch... default: Applying the patch /u01/software/35742441/35642822... default: OPatch command failed while applying the patch. For details look at the logs from /u01/app/19.0.0/grid/cfgtoollogs/opatchauto/. default: ****************************************************************************** default: Run grid root scripts. Tue May 28 18:47:39 UTC 2024 default: ****************************************************************************** default: sh: /u01/app/oraInventory/orainstRoot.sh: No such file or directory default: sh: /u01/app/oraInventory/orainstRoot.sh: No such file or directory default: Check /u01/app/19.0.0/grid/install/root_ol8-19-rac1_2024-05-28_18-47-40-822908792.log for the output of root script default: sh: /u01/app/19.0.0/grid/root.sh: No such file or directory default: ****************************************************************************** default: Do grid configuration. Tue May 28 18:47:42 UTC 2024 default: ****************************************************************************** default: default: ERROR: The home is not clean. This home cannot be used since there was a failed OPatch execution in this home. Use a different home to proceed. default: default: ****************************************************************************** default: Create additional diskgroups. Tue May 28 18:47:43 UTC 2024 default: ****************************************************************************** default: /vagrant/scripts/oracle_grid_software_config.sh: line 48: /u01/app/19.0.0/grid/bin/sqlplus: Permission denied default: ****************************************************************************** default: Check cluster configuration. Tue May 28 18:47:44 UTC 2024 default: ****************************************************************************** default: /vagrant/scripts/oracle_grid_software_config.sh: line 63: /u01/app/19.0.0/grid/bin/crsctl: No such file or directory default: ****************************************************************************** default: Unzip database software. Tue May 28 18:47:44 UTC 2024 default: ****************************************************************************** default: unzip: cannot find or open /vagrant_software/p6880880_190000_Linux-x86-64.zip, /vagrant_software/p6880880_190000_Linux-x86-64.zip.zip or /vagrant_software/p6880880_190000_Linux-x86-64.zip.ZIP. default: ****************************************************************************** default: Do database software-only installation. Tue May 28 18:55:59 UTC 2024 default: ****************************************************************************** default: Preparing the home to patch... default: Applying the patch /u01/software/35742441/35642822... default: OPatch command failed while applying the patch. For details look at the logs from /u01/app/oracle/product/19.0.0/dbhome_1/cfgtoollogs/opatchauto/. default: ****************************************************************************** default: Run DB root scripts. Tue May 28 19:03:07 UTC 2024 default: ****************************************************************************** default: Check /u01/app/oracle/product/19.0.0/dbhome_1/install/root_ol8-19-rac1_2024-05-28_19-03-07-933148407.log for the output of root script default: sh: /u01/app/oracle/product/19.0.0/dbhome_1/root.sh: No such file or directory default: ****************************************************************************** default: OJVM Patch for DB Software. Tue May 28 19:03:10 UTC 2024 default: ****************************************************************************** default: ****************************************************************************** default: Patch Oracle Grid Infrastructure Software. Tue May 28 19:03:10 UTC 2024 default: HOSTNAME=localhost.localdomain default: ORACLE_HOME=/u01/app/oracle/product/19.0.0/dbhome_1 default: ****************************************************************************** default: ****************************************************************************** default: Unzip software. Tue May 28 19:03:10 UTC 2024 default: ****************************************************************************** default: Can't call method "uid" on an undefined value at /u01/app/oracle/product/19.0.0/dbhome_1/OPatch/auto/database/bin/module/DBUtilServices.pm line 28. default: ****************************************************************************** default: Patch Oracle Grid Infrastructure Software. Tue May 28 19:03:11 UTC 2024 default: HOSTNAME=ol8-19-rac2 default: ORACLE_HOME=/u01/app/oracle/product/19.0.0/dbhome_1 default: ****************************************************************************** default: ****************************************************************************** default: Unzip software. Tue May 28 19:03:11 UTC 2024 default: ****************************************************************************** default: /vagrant_scripts/oracle_software_patch.sh: line 26: opatchauto: command not found default: ****************************************************************************** default: Create database. Tue May 28 19:07:33 UTC 2024 default: ****************************************************************************** default: [FATAL] java.lang.NullPointerException default: ****************************************************************************** default: Save state of PDB to enable auto-start. Tue May 28 19:07:44 UTC 2024 default: ****************************************************************************** default: /vagrant/scripts/oracle_create_database.sh: line 32: /u01/app/oracle/product/19.0.0/dbhome_1/bin/sqlplus: Permission denied default: ****************************************************************************** default: Check cluster configuration. Tue May 28 19:07:44 UTC 2024 default: ****************************************************************************** default: ****************************************************************************** default: Output from crsctl stat res -t Tue May 28 19:07:44 UTC 2024 default: ****************************************************************************** default: /vagrant/scripts/oracle_create_database.sh: line 44: /u01/app/19.0.0/grid/bin/crsctl: No such file or directory default: ****************************************************************************** default: Output from srvctl config database -d cdbrac Tue May 28 19:07:44 UTC 2024 default: ****************************************************************************** default: /u01/app/oracle/product/19.0.0/dbhome_1/bin/srvctl: line 259: /u01/app/oracle/product/19.0.0/dbhome_1/srvm/admin/getcrshome: No such file or directory default: PRCD-1027 : Failed to retrieve database cdbrac default: PRCR-1070 : Failed to check if resource ora.cdbrac.db is registered default: CRS-0184 : Cannot communicate with the CRS daemon. default: ****************************************************************************** default: Output from srvctl status database -d cdbrac Tue May 28 19:07:46 UTC 2024 default: ****************************************************************************** default: /u01/app/oracle/product/19.0.0/dbhome_1/bin/srvctl: line 259: /u01/app/oracle/product/19.0.0/dbhome_1/srvm/admin/getcrshome: No such file or directory default: PRCD-1027 : Failed to retrieve database cdbrac default: PRCR-1070 : Failed to check if resource ora.cdbrac.db is registered default: CRS-0184 : Cannot communicate with the CRS daemon. default: ****************************************************************************** default: Output from v$active_instances Tue May 28 19:07:48 UTC 2024 default: ****************************************************************************** default: /vagrant/scripts/oracle_create_database.sh: line 59: /u01/app/oracle/product/19.0.0/dbhome_1/bin/sqlplus: Permission denied default: ****************************************************************************** default: Setup End. Tue May 28 19:07:48 UTC 2024 default: ******************************************************************************
Hi Tim, In our database, we are migrating jobs scheduled using DBMS_JOB to DBMS_SCHEDULER. In the current process, we are able to pass the instance ID as an argument in DBMS_JOB, but that option does not seem to be available in DBMS_SCHEDULER. Is there any workaround for this?
ORDS is a PL/SQL gateway. In order to use ORDS you have to install it. You can run it in standalone mode, or under a Java container such as Tomcat. This is how you get access to port 8080, or any other port you define. ORDS then connects to the database, which is where the data and the ORDS package are. Whenever you read anything about ORDS, it assumes you are running ORDS with a connection to an Oracle database. oracle-base.com/articles/misc/oracle-rest-data-services-ords-installation-on-tomcat-22-onward
@@togaramutasa9669 APEX and ORDS are two separate products. You can install APEX without using ORDS and vice versa. ORDS is the preferred gateway for APEX, so if you are using APEX it is probably you also have ORDS installed, but it's not guaranteed. You need to speak to whoever set up APEX in your company.
@@TheTimHall Sorry, I meant that I do not want to expose it in my mobile app code. Trying to find a way of protecting the client secret and not need to hard code it in the app.
@@TheTimHall Well this is a game (Unity3d) and the only resource I really need to protect is the access to the JSON database where I have all game and player data. As of now I have the client secret hard coded in the code and is currently researching and key management system I can use. However, I know very little about this topic.
@@MrZtapp I know nothing about Unity (apart from they have an atrocious pricing model that has lots of bad press). I suggest you ask on a Unity development forum, as this is not an ORDS issue. It's a programming issue.
You can turn on SQL trace for the user and check that. I'm not exactly sure why you would care about execution plans for DDL and procedure creations though.
@@oracle-base thanks for your reply. Thought that could be rather interesting to enhance a log such as "<script_name> ran successfully in 100ms" by adding "Table created" so that the implementer has clear picture of what has ran.
I'm not sure what you mean. Implicit statement results are an option to interact with the ref cursor contents, but it is an alternative to the traditional approach.
As you've discovered, it doesn't. Oracle deprecated LONG columns a very, very long time ago. As a result, most features added since that deprecation do not support LONG columns. You should migrate from LONG to LOB (CLOB or BLOB).
Hello, thanks for the videos! Could you please answer me a question? If I have 2 servers differents (A and B) , and I would like to transfer a PDB1 (Server A) to server B. What kind of migration is better performance? 1- Using RMAN (duplicate) 2- CREATE PLUGGABLE DATABASE PDB1_copy FROM PDB1@clone_link;
In SQL developer ref cursor is not returning the result in grid format, is any way/option to return result in grid/table format? Thank you for the video.
Yes. You pass in a directory name and file. The example does this, so not sure why you would need a separate example. As explained, it need you to have APEX 19.1 or newer installed in the database.
Allow me to be the first one to leave a comment. This is a great video, simple, concise, clearly explained, no waste of time or resources as most video creators do and absolutely nails the topic! Awesome work and thanks for creating this video!! Cheers!
Hi Tim, Could you do a video on how to ingest a regularly delivered XML file (with several nested children and data) to an Oracle table? Thanks so much!
The linked article shows how to deal with nested XML. oracle-base.com/articles/misc/xmltable-convert-xml-data-into-rows-and-columns-using-sql#nested-xml Once you've got the data parsed, just insert it. As for it happening regularly, just use a job. oracle-base.com/articles/10g/scheduler-10g#simple
The documentation says "DBMS_CLOUD.LIST_FILES is only supported for directory objects mapping to Oracle File System (OFS) or Database File System (DBFS) file systems.". What if we don't have such a file system in our db? We currently use Exadata on-prem and it seems we are not able to use that package because of that. Does some workaround exists? Thx in advance for your answer.
This is just a conversion from CentOS to OL of the same version. You can consider using LEAPP to upgrade after that. oracle-base.com/articles/linux/leapp-upgrade-ol7-to-ol8
Hi Tim, this is a really great explanation of how to use vagrant to install Oracle Database. I just discovered this Vagrant thing when i read your article about your opinion on GUI installation and i overall agree with your points there. It inspired me to learn how to automate things which in turn would ease my job as a DBA and saves customers' time. I wanna ask some questions unrelated to the technical aspect of using Vagrant, and more of your personal experience with it. 1. Could you share the story of when and how you first encountered with Vagrant, and how did you feel about it at the time? 2. How long does it usually takes for you to create the builds with its configuration file and scripts that are used to create the database? (I assume that there might be typing errors or other kind of errors in the process of building and creating them 😁) 3. How are you using Vagrant at work? I assume that some companies will require us to install the database with its options in a baremetal server, and not with VMs. Have you ever using Vagrant for a production or testing environment? How does using Vagrant help you in serving the customers? I apologize for the long questions 😁. Thanks for your videos and articles anyway, i learn a lot from you.
@@oracle-base Hi Tim, i've read your blog post. Thank you very much for your answer, it satisfies my curiosity :D. I'm definitely going to use it, and i'm afraid i'm going to become "addicted" to it. You have to be responsible if that happens, Tim 😁. Thank you once again. Best regards, Levi
Hi Tim, can you let me know how to restore a pluggable using a backup from a production database? (They had different DBIDs). I don't know how to catalog them first.
This is a very useful command in case of workflow type tables where data moves or is copied from one table to another very similar table. MERGE where were you all my life ? Thanks for explaining the important use cases of this statement.
According to the docs it only support the following formats. csv, csv with embedded, csv without embedded. docs.oracle.com/en/database/oracle/oracle-database/19/arpls/DBMS_CLOUD.html#GUID-08C44CDA-7C81-481A-BA0A-F7346473B703
It shouldn't affect anything. It's essentially just swapping out repos to the Oracle Linux repo, and installing the Oracle release packages so it is recognized as Oracle Linux.
Hi Tim, 1) While using Online compression/Partition, will it causes more REDO/UNDO data generated. 2) Online usage, will require same/more space than the original table size, and after the online activity is completed, it fragments the datafile because the table is moved ?
1) Don't know. Never tested it. 2) There will be a period where the before and after version of the table exists at the same time, so there will be extra space used during the operation. The original version of the table is only removed after the operation, so there will be a bunch of unused blocks in the middle of the data files if that us a concern. Online operations track transactions, so a busy table will use more room to track changes, but that is cleaned up at the end.
In 19c we can put the refresh in the same cdb with the source pdb but there is many prob in datafile location in the standby site and with the rman deletion policy refresh stop even if every 1 minute
