I saw some presentations about a very promising product "Oracle Instant Client".
Could you tell me what is the status of this product?
Is it really used?
How is the support from Oracle?
It seems to be kind of equivalent to the thin driver for Java. Is it really something as simple as unzip, modify 1 or 2 environment variables and run your client application?
http://www.oracle.com/technetwork/database/features/instant-client/index-100365.html
http://www.dbatoolz.com/t/installing-oracle-instantclient-basic-and-instantclient-sqlplus-on-win32.html
Thanks & regards
Alexandre
Oracle Instant Client is still an Product needed to be installed, it just comes with less features i.e. SQL Plus.
You can add individual components per demand.
The Instant Client is about 60 MB in size, compare to an Full client about 600 MB up to 1 GB depends on features you add there on top.
For simple db connection of an Client App, Instant Client is fully capable to fulfil this. The Idea is / was to add some security, since advanced users could do an connection threat to your DB.
It seems to be kind of equivalent to the thin driver for Java. Is it really something as simple as unzip, modify 1 or 2 environment variables and run your client application?
Pretty much, though it depends what your client application is. And which bits you download. If you install all of the packages then it includes the JDBC drivers (thin and OCI), libraries for OCCI apps, SQL*Plus... well, you can see all that from the downloads list. It's a smaller, simpler version of the full client, and doesn't need to be installed, just unzipped, which makes it easier to distribute too.
If you have the full Server or Client software installed then there's not much benefit in having the instant client as well; unless you need different driver versions, or you want to remove execute permissions from the full Oracle binaries for some reason. But if you have a new box that needs to access a remote DB then it gives you everything you need, simply. (Not quite instantly, but not far off).
It's been around since 10g and is fully supported, but like everything else, only if you have a support contract. It's certinly still supported in the sense that there is a new version to go with Oracle 12c.
In some respects it's very much just for client use though. For example, we develop Pro*C modules that we have to compile with the full version, but then we can happily execute them on a server that only has the instant client, to access a remote DB. That's not an issue for Java though.
Related
I am writing an occi based MFC Win32 application and wanted to deploy it with the oracle instant client in version 11.2.
The whole software works fine with the full client. With the instant client, the same queries work as well - but in some cases I get broken results (wrong data) - with no error message. In these cases, quite large HUGEBLOB entries are selected.
Has somebody experienced something similar? It would make me happy not to need the oracle full client.
I would like to use Meteor (Node.JS) to develop an application that will be used by 3,000+ concurrent users on a large size database.
I have looked at the nice examples and the idea to push changed data to the clients is very nice and very useful, but before I start the development I want to be sure how it works behind the scenes to be sure that when I have the application running with all these users it work fast with standard hardware.
I also require this to use Oracle as a database, but not sure that it is supported and if not, what are the requirements from an Oracle package to enable this facility.
I think that the server is having an active on going non-blocking query on the OPLOG table in mongodb and that is how we get the callback for all the changes in the database. Is that correct ? if so, is there a similar way to do it in Oracle ?
Thanks Roni.
I also require this to use Oracle as a database, but not sure that it is supported and if not, what are the requirements from an Oracle package to enable this facility.
Nope, meteor is currently mongo-only as they have implemented an in-browser library called minimongo. My guess is this project will never support oracle, but who knows. There is no mention of oracle support on the meteor project roadmap
Just happened to come across this question while searching at google.
However, if there are no native solutions. We can always figure out a way for a medium language to issue publishing.
Example Case:
Python will be used for synchronising data between Mongodb and Oracle (24/7 operation using cx_Oracle and MongoDB drivers from python)
Meteor Server will keep watch on what to publish
Meteor clients/browsers that subscribed to the channel that will be updated with oracle data.
I'm using delphi at the moment and have a program that connects to another program (a server) which has the mysql database on it and sends the data back to the client. I have a web server that has the server program and the database but my question is can I just go straight from the client program I have made (windows and future mac) to the mysql database on the web server? Or do I really need the server program? If so, what do I need to do to connect my client program to the MySQL database over the internet?
You should be able to access the mysql database directly as long as you've created a user/pw combo for the database that allows remote access (Security discussion aside). You'll then want to search for a compatible mysql library that would ease the communication between your program and mysql. At the far technical end you might have to read/write directly to the mysql socket but that's possible as well.
Depends on whether your client programs will continue to be native applications or whether you plan to migrate to browser based clients.
If they're native applications you can obtain library components for the languages they're written in which will be able to communicate directly with the MySQL database. There are plenty of options for Delphi; I'm not familiar with what options might be available for native Mac development (but, of course, Embarcadero is in the process of rolling out a Delphi that can generate Mac applications).
If, however, you're planning on making your clients browser-based, ajax solutions want to talk to a web server rather than a database server. In that case, you will need to maintain your middleware. For a discussion of whether it's possible or desirable to have a browser based application communicate directly with a database server see this question.
I would use SOAP/XML for this, and leave the SQL out of the client entirely.
This is a typical use case where REST (for example using JSON encoded database records) can be helpful. It is easy to implement a Delphi client using lkJSON or SuperObject, to put the database records from the HTTP response into a TClientDataSet.
Yes, it's possible, but is it a good idea?
here's a basic discussion of 2 tier v 3 tier architecture
i am looking for an Delphi component to connect to an ORACLE database server in an direct way without install the oracle client.
i knew the Oracle Data Access (ODAC) from DevArt. there are any other component with this capability?
ODAC offers two connection modes to
the Oracle server: connection through
the Oracle Call Interface in Client
mode and direct connection over TCP/IP
in Direct mode. ODAC-based database
applications are easy to deploy, do
not require installation of other data
provider layers.
Thanks in advance.
No, there is no other Delphi Win32 libraries allowing to connect to Oracle without the installed Oracle Client. And, IMHO, that is correct, because:
OCI (Oracle Call Interface) is quite complex piece of software. I will say, it is most complex closed sourced DBMS Call Level Interface in the World. And it is changing from version to version. Oracle has official rule - the Oracle Client v X supports Oracle Server v X-1 ... X+1. Because even such company as Oracle, dont want to spend resources to support and test all the protocol nuances across all possible versions. So, I dont think, that DevArt ever will implement 99.9% stable Oracle SQL*Net protocol implementation. And the INet posts proof that ...
AFAIK, the ODAC Net mode does not support some of the Oracle Client important features and has some important limitations. Although it works well for simple data access scenarious.
If you will purchase Oracle support, then it will decline all your support requests, if they will know, that you are not using official client software. That is just Oracle rule.
If you dislike to install and tune the full scale Oracle Client, then you can just use Oracle Instant Client. Which does not require install or setup procedure. And you will be in safety in case of the different data access scenarious and Oracle Server versions.
PS: Although I may be considered as a biased person :)
There is also Allround Automations Direct Oracle Access, it do require Oracle SQL*Net or Net8. but is a brilliant component suite.
The only solution I found is ODAC, and it's working very nice, I have been using it since years without getting any problem with the direct mode.
there's some limitation with the direct mode, but most of users will not get these limitations with their application.
I have an ASP .NET application that connects to an Oracle or a SQL Server database. An installer has been developed to install a fresh database to an existing SQL Server using sql commands such as "restore database..." which simply restores a ".bak" file which we keep under source control.
I'm very new to Oracle and our application has only recently been ported to be compatible with 10g.
We are currently using the "exp.exe" tool to generate a ".dmp" file and then using the "imp.exe" to import it into a developers box.
How would you go about creating an "Oracle Database Installer"?
Would you create the database using script files and then populate the database with required default data?
Would you run the "imp.exe" tool behind the scenes?
Do we need to provide a clean interface for system administrators so that they can just select the destination server and have done, or should we just provide them with the ".dmp" file? What are the best practices?
Thanks.
The question is -- what do your customers know about Oracle?
Nothing? You should probably rethink this position. Oracle is very large and complex. If you assume your customers know nothing, you'll then start providing tutorials and help that's inappropriate.
Minimally Competent? If they're competent, they know enough to run imp by themselves. Also, they know enough to run a script that executes SQL.
Actual DBA's? Most organizations that can afford Oracle can afford real DBA's. Real DBA's can cope with a lot of things -- they do not need much hand-holding. Some of them like to assign storage parameters according to their shop standards.
You should provide a script with reasonable defaults. You should define your script in a way that someone can easily find all of your storage parameters and tweak them if necessary.
Your initial data can be via export/import or via a script. I prefer a script.
I have done this repeatedly from both sides (consumer and provider) as a DBA, developer, and architect.
As a provider, one of my grand accomplishments (in 1996) was the creation of an installation CD for a commercial insurance claims management software product targeted to the largest insurance carriers (a multi-million dollar item). That installation CD installed the Oracle 7.2 RDBMS engine, the FileNet optical storage system (scans paper documents and creates cataloged binary versions), and our custom claim-processing application (built in VB 4.0), all integrated and ready to run. As part of the installation process, the user could skip the Oracle software installation or customize it, and the user could customize/override the database configuration in all of its major details (database, schemas, tablespaces, sizes, disks, etc.).
I also provided the field service for this product, which included traveling to the client site as necessary. I tested the installation CD literally hundreds of times under every imaginable scenario that I could replicate, and we NEVER had a field failure that required even a phone call, let alone a trip (I did travel on four occasions, but for pre-sales stuff instead).
More recently (2007), I scripted the creation of an Oracle 10g database for an internal system at a megacorp. In production, the database was sized at 8 TB, mostly for a single transaction table with high data volume. In test, the database was sized around 1 TB for a modest server. In development, the database was sized around 100 MB to run on my laptop. The EXACT SAME SCRIPTS created all three environments, and I could extend them to handle a new environment/machine in about five minutes. This database involved extreme performance tuning, so customization of all pertinent characteristics was absolutely crucial.
Back to the insurance claims processing product--let me please add that I was originally hired to lead its conversion from a SQL Server database to an Oracle database. That conversion was identified as a business necessity because most potential clients did not view a SQL-Server-based product as a professional, serious solution. That is not quite as common today, but it still applies in general: a software product has a better chance of market penetration if it can accommodate multiple database options as preferred by the target customers (especially enterprise-class customers).
Likewise, the installation CD was also viewed as an essential element. However, that situation and many more have revealed to me that most "real" DBAs will not accept an import-based database installation. As a DBA and architect, I know that I definitely will not for the same reasons.
Simply put, an import-based database installation gives the customer almost no control over the resulting database. It is opaque to the customer, leaving them questioning what it did. It forces the customer to expend massive efforts to attempt to exercise what little control they can. It is notoriously fragile and error-prone (Oracle imports are well known for ownership and permission problems, constraint problems, etc.). Weighing all those impacts, an import-based database installation is unprofessional--it does not put the customers' needs first.
Scripting the database installation provides the right kind of transparency, configurability, selective repeatability, and overall customer control that professionalism demands. It also encourages you to properly understand the impacts of your database design decisions in a way that an import does not.
Best wishes.
Personally I favour SQL scripts to database creation and data loads where possible. I tend to use PL/SQL Developer. It has some good options to generate scripts from an existing database. Once you have these you can run the scripts using sqlplus or any application code that can execute arbitrary SQL (eg JDBC with Java). Toad is the more common (and more expensive) tool for Oracle development.
The only limitation of a SQL export is it can't export CLOB/BLOB fields. If you have those, you either need to do them separately (as a PL/SQL export) or do the whole thing as a PL/SQL export. Theres no dramas with this except the file is effectively a binary export (extension .pde) and is more limited in how you can execute it.
The other big advantage of SQL source files is they can be version controlled easily. It's really handy to be able to create a database environment by running one or two scripts.
The import and export tools for Oracle I think are more applicable for backup and restore operations.
Now, as for delivering that to a customer, from your comments it seems that you'll be giving this to DBAs. Pretty much any Oracle installation will have DBAs involved. They will be fine with SQL scripts to create the schema and do the data load. They will be doing a lot of site-specific configuration (eg tuning the SGA, temp tablespaces, # of concurrent connections, etc based on expected load).
You, as the vendor, can give guidance on any relevant configuration and you may get involved in support and possibly installation but ultimately it's up to them to figure out what works for them. Oracle runs on a large number of operating systems and hardware variants with infinite variations in network topology and firewall configuraiton. You can't factor in all of these to an installer or even a set of instructions (other than the guidelines mentioned previously).
The last time I was involved in the creation of a (oracle) db (for a reasonably large company with in-house DBAs) the DBAs wanted to know things like:
what we wanted to call the db,
what tablespaces we would need, and an estimate of how much data would be in each one
how many users would be connecting.
(From memory) they set up the db and tablespaces, then we provided a combination of simple scripts that they could run (or clear instructions if a task wasn't easy to automate)
As I say this was for an in-house app, so your mileage may vary, but in my case they wanted all instructions clearly spelt out so that (a) there was no possibily of a misunderstanding leading to the wrong thing being done, and (b) no culpability on their part if something didn't work ("we were just following the instructions")