Just to expand on Jesper's good advice:
Commercial applications almost always end up using a relational database somewhere to store data, and it is often the data that is the most valuable asset in the system. Application code changes all the time, technologies change every few years, but the data will often still be valuable years from now as people find new ways to use it. So it is worth understanding how databases work, and that goes beyond just learning SQL and doing an introductory SQL certificate of some kind. SQL is an excellent tool for accessing data in a relational database, but it is just as easy to write bad SQL as it is to write bad Java, and when you are working with large volumes of data your SQL mistakes can have a truly catastrophic impact on how the system performs. In my experience, Java developers are especially prone to this problem, because often they have the misguided idea that as Java EE development is complex (oh boy, is it complex...!), it is the only important aspect of a system they need to worry about, so they fail to recognise the need to use the right tool for the job when it comes to database applications. That tool might be Hibernate rather than pure SQL, but it still helps to understand what Hibernate is doing underneath.
So you need to understand something about relational databases and relational data modelling in order to use SQL properly, just as you need to understand object oriented programming in order to use Java properly. And you may also need to understand a bit about how your particular relational database works, because different RDBMS vendors may implement particular features (indexing, partitioning, query optimisation etc) in different ways, and even if somebody is responsible for managing these things, you may well need to know how to make good use of them with your SQL. It's just like the
JEE platform: you can pretend it's all vanilla and you don't need to know how it works underneath, but you will usually find you produce better code if you understand what your platform (JEE or RDBMS) is really doing.
Finally, as you know, PL/SQL is Oracle's proprietary extension to SQL which is used almost everywhere in the Oracle world (PL/SQL has also been ported to PostgreSQL, although there may be some inconsistencies in the implementation and of course you will not have access to the Oracle-specific libraries etc). It's been around for about 20 years and these days is a very powerful tool for implementing complex logic simply, robustly and efficiently on the Oracle RDBMS server. As with any other language, it is worth understanding how it works so you can write good idiomatic PL/SQL code, rather than simply pretending it's Java without the brackets.
So if you're working on an Oracle-based application, learning PL/SQL would be very useful, but if you're not on Oracle, or if you are not permitted to use vendor-specific DB tools, then it will be less helpful to you.
My advice FWIW: Learn SQL and how to use it properly, then learn PL/SQL if you're on Oracle.