4 months after the 19.9, here comes the 19.10 version of the Oracle Database Appliance patch. Let’s have a look at what’s new.<\/p>\n
The 19.10 release will be the same for all ODAs, as usual. The oldest ODA compatible with this release is the X5-2. Don’t expect to install this version on older models. X4-2 is stuck to 18.8, X3-2 is stuck to 18.5 and V1 is stuck to 12.2. If you are still using these models, please consider an upgrade to X8-2 and 19c to go back to supported hardware and software.<\/p>\n
As usual, 19.10 includes all the latest patches for all database homes, including for those versions no more supported with Premier Support (provided patches are the very latest from the 19th of January, 2021).<\/p>\n
The most important new feature is dedicated to KVM virtualization. It’s now possible to create a database VM, for example if you need to isolate the systems running your databases. Up to 19.9, virtualization was only dedicated to other purpose than Oracle databases. Now with 19.10, a set of new odacli commands are available like: For sure, you can also have an overview of the existing dbsystems on your ODA with: What’s also new is the internal database dedicated to ODA repository. It has now switched from JavaDB to MySQL, but actually it wouldn’t change anything for you because you’re not supposed to access to this database.<\/p>\n Database Security Assessment Tool is a new item available in the ODA GUI and is dedicated to discover security risks on your databases: it’s probably a nice addition and definitely usefull.<\/p>\n And that’s it regarding new features. And it’s not bad because it’s probably a mature patch, 19c being available on ODA for 1 year now.<\/p>\n 19.10 will let you run all versions of database starting from 11.2.0.4. Yes 11gR2 is still there and a few ODA customers in 2021 are still asking for this version. However, it’s highly recommended to migrate to 19c, as it’s the only version with long term support available now. Deploying 19.10 and planning to migrate your databases in the next months is definitely a good idea. With ODA you can easily migrate your databases with: You will need to already run 19.6 release or later. If your ODA is running on 18.8, you will have to patch to 19.6 prior applying 19.10. If your ODA is running on 18.7 or older 18.x release, an upgrade to 18.8 will be mandatory before patching to 19.6, and then to 19.10. If you are using older versions, I highly recommend to proceed to a complete reimaging of your ODA. It will be easier than applying 3+ patches. And you’ll benefit from a brand new and clean ODA. Patching is still a lot of work, and if you don’t patch regularly, going to the latest version could be challenging. Yes, reimaging is also a lot of work, but it always works.<\/p>\n 19.10 seems to be a mature release for customers using ODAs, so if you’re using previous 19.x versions, don’t hesitate. I will be able to try it next week and I will not miss to give you my feedback.<\/p>\n","protected":false},"excerpt":{"rendered":" Introduction 4 months after the 19.9, here comes the 19.10 version of the Oracle Database Appliance patch. Let’s have a look at what’s new. Will my ODA supports this 19.10 patch? The 19.10 release will be the same for all ODAs, as usual. The oldest ODA compatible with this release is the X5-2. Don’t expect […]<\/p>\n","protected":false},"author":45,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[229,198,199,42,59],"tags":[2279,79,1662,365,572,2280,1531,1532,1533,1534,1535,1330,1331,1332,1697,1698,1699],"type_dbi":[],"class_list":["post-15892","post","type-post","status-publish","format-standard","hentry","category-database-administration-monitoring","category-database-management","category-hardware-storage","category-operating-systems","category-oracle","tag-19-10","tag-oda","tag-odacli-update-server","tag-oracle-database-appliance","tag-patch","tag-patching-oda","tag-x5-2","tag-x6-2ha","tag-x6-2l","tag-x6-2m","tag-x6-2s","tag-x7-2ha","tag-x7-2m","tag-x7-2s","tag-x8-2ha","tag-x8-2m","tag-x8-2s"],"acf":[],"yoast_head":"\nodacli create-dbsystem<\/code>
\nImmediately, it makes me think about a dbsystem in OCI, the Oracle public cloud, and I’m quite sure the implementation is similar. Basically, it will create a new KVM virtual machine, with a dbhome and a database inside. As there is quite a lot of parameters to provide for creating a dbsystem, you feed the create-dbsystem with a json file, which is very similar to the one you used for provisionning the appliance. In the file, you will give host and network information, users and groups settings, database name, database version and database parameters as if it were an ODA deployment file. Brilliant. <\/p>\nodacli list-dbsystems<\/code>
\nYou can have more information on a dbsystem, you can also start, stop and delete a dbsystem with:
\nodacli describe-dbsystem
\nodacli start-dbsystem
\nodacli stop-dbsystem
\nodacli delete-dbsystem<\/code>
\nQuite easy to manage.<\/p>\nodacli restore-archivelog<\/code> This is the only new feature regarding odacli appart from dbsystems: it allows you to restore a range of archivelogs. It’s probably helpfull from time to time if you make use of the odacli backup features. If you’re used to make backups with RMAN directly, you’ll probably never use this feature.<\/p>\nStill able to run older databases with 19.10?<\/h2>\n
odacli upgrade-database<\/code>
\nIt should have been replaced by: odacli move-database<\/code>
\nBut it’s not yet done on this version.<\/p>\nIs is possible to upgrade to 19.10 from my current release?<\/h2>\n
Conclusion<\/h2>\n