I have checked my ORACLE_HOME in 3 different ways in my windows 32-bits PC in this order:
1.- In cmd, if I type echo %ORACLE_HOME% the result is just:%ORACLE_HOME%, so no current path. Why?
2.- In regedit, under Computer\HKEY_LOCAL_MACHINE\SOFTWARE\ORACLE\KEY_OraClient11g_home1, the stored value is C:\oracle\product\11.2.0\client_1
3.- Finally, in the variable Path in Environment variables these are the oracle-related ones values (I disguise the others by using asterisks) in the same order they appear:
C:\ProgramData\Oracle\Java\javapath;C:\oracle_python\instantclient_11_2;C:\oracle\32bit\product\11.2.0\client_1\bin;*;*;C:\oracle\product\11.2.0\client_1\bin;%SystemRoot%\system32;%SystemRoot%;%SystemRoot%\System32\Wbem;%SYSTEMROOT%\System32\WindowsPowerShell\v1.0\;*;*;*;*;*;*;*;*;C:\Program Files\Java\jdk1.7.0_60\bin
In addition, I operate with Oracle only in two ways basically: I use SQL Developer daily but also I do some scripting in Python by using the cx_Oracle library.
My question is whether I have properly optimized the ORACLE_HOME variable or not, I mean would an expert in Oracle agree with this current scenario?
When you do echo %ORACLE_HOME% then you interrogate the Environment variable ORACLE_HOME. In your case it is not set.
Some tools use (only) the Environment variable for ORACLE_HOME, other use the Registry value. I think most programs use both and give precedence over Environment variable.
I assume for your Oracle Client following folders are relvant:
C:\oracle_python\instantclient_11_2
C:\oracle\32bit\product\11.2.0\client_1\bin
C:\oracle\product\11.2.0\client_1\bin
Looks like you installed Oracle client three times (all into different folder). I do not consider this as an optimized setup. My recommendation is to remove all of them and make one single proper installation.
Check also How to uninstall / completely remove Oracle 11g (client)? in case of problems.
Related
I need some assistance in configuring my oracle 11g database with the PL/SQL developer 14. I have installed and configured 11g client for my windows PC but the database is not show in the DBs list on PL/SQL 14 as:
But I got connected when I use PL/SQL Developer 7 as:
Actually, I want to use some advance features and plugins of PL/SQL Developer 14 which are not available in 7.
I don't use PL/SQL Developer.
However, any tool I know looks for available databases in TNSNAMES.ORA file. It looks as if version 7 "knows" its location, while version 14 doesn't.
If it (PL/SQL Developer) behaves like other Oracle-related software, then I'd suggest you to do this:
create a directory (folder), e.g. c:\oralib
put TNSNAMES.ORA file in there
create environment variable named TNS_ADMIN (uppercase!)
what does it do? It tells Oracle software where to search for TNSNAMES.ORA. Probably every Oracle software uses its own "copy" of TNSNAMES.ORA so - every time you have to work with a new database, you have to add its alias into ALL of those files (which is tedious). But, if you keep a single copy in a directory and let TNS_ADMIN point to it, you have only one TNSNAMES.ORA to maintain
set its value to path that leads to that directory: c:\oralib
restart PL/SQL Developer
hopefully, you'll see your databases
The problem has been solved. Actually, the issue was that the PL/SQL was 64 bit and the client was 32 bit that's why I had to download and install a 64 bit client which I installed and set the path to it's oci.dll file and that's solved my problem. One more thing I need to mention is that I have also created an environment variable for TNS_ADMIN and set the path to the folder which contains tnsnames.ora file.
Other answers are also appreciated.
I came into an environment were when users log into our system, they log in with the csh by default. We also have an automation login (let's call it "autologin") that also invokes the csh by default.
This login in used to execute (via its crontab) all of our scripts (50+) used to send and receive files with our vendors. The results of these individual file transmissions are used to feed a dashboard for each transmission.
The dashboard simply has a light for each file transmission (green light if the last file transmission was successful and red if it failed). This success/fail status is set (in a SQL Server database) from the scripts, using a tsql -H connection.
We are currently using SQL Server 2008, but are upgrading to 2016. So I need to change are 50+ scripts' tsql connection from sql_2008 to sql_2016. I had the idea to use an environment variable (let's say AUTOSQL) that could use.
I could then change all of the 50+ scripts to reference AUTOSQL, instead of sql_2008, and then set the environment variable to sql_2008/sql_2016/and whatever we upgrade to in the future. As I previously mentioned, all users log in with csh as the default shell. The problem I've encountered is all of the shell scripts are written in bash.
How can I set up an environment variable for the bash (our automation) scripts to use, so when we upgrade in the future, I simply have to change the value of one environment variable, instead of changes to 50+ scripts? Thank you
Environment-variables are an operating system feature that is "application agnostic". In Unix-like environments, any kind of program can pass environment variables to any other, that is its child.
The real issue here is that the fifty scripts are run by cron from a crontab file. This means that they will not inherit the AUTOSQL variable, even if it is exported by the csh login script.
See:
Where can I set environment variables that crontab will use?
Also, on the ServerFault StackExchange:
https://serverfault.com/questions/337631/crontab-execution-doesnt-have-the-same-environment-variables-as-executing-user
It's great to see someone simplifying and consolidating their scripts.
If all these scripts are executed in cron (by root), /root is the first place I'd look.
Step 1:
Choice A.) Set and export AUTOSQL in root's .profile
Choice B.) Set and export AUTOSQL in root's .bashrc
Choice C.) Set and export AUTOSQL in root's (whatever you wanna call the file)
export AUTOSQL='sql_{year}'
Step 2:
Make sure you source this file at the top of your scripts. From now on, you can add environment switches at will to this file, since all of your scripts will source it.
. /root/.{bashrc || profile || whatever you decide to name the file}
Hope this helped! Again, the decision is yours.
I have Oracle 11g installed on my system and want to install 12c now. Read articles ( Oracle docs and general) which suggest that i can do so in different homes.
But when I try to install 12c (12.2.0.1 release 2) , it does not allow me to do so as it says "oracle _home (in environment variables) already defined and does not match the path specified (during installation)".
Am I supposed to specify the paths manually (or change it in the env variables) and if so then how do i accommodate different paths for two Oracle_homes for both versions in the environment variables.
A search on this portal gives results that does not answer my query.
How do I get around the installation?
You should not install more than one (i.e. one each for 32bit and 64bit) Oracle Client on one machine, I could also not imagine any reason for it.
Anyway, if you like to install more than one Oracle Client delete Environment Variable ORACLE_HOME and ORACLE_BASE from your computer, if existing. Then modify PATH Environment Variable and remove all directories of your first Oracle installation from PATH.
After that it should be no problem to install another Oracle Client. You must install it into a different directory, otherwise you mess up the installation and I assume afterwards none of them will work properly.
In order to use one or the other you have to set ORACLE_HOME and PATH Environment Variable accordingly, you cannot use them together! According Managing Oracle Home Directories you should have a "Home Selector" tool but I never used this.
Note, some components (e.g. "Oracle Provider for OLE DB") you can install only once (i.e. one each for 32bit and 64bit). This limitation is caused by Windows COM. Other drivers for example "Oracle Data Provider for .NET" may also fail due to version mismatch and/or policy settings in GAC.
I'm using vs2013 data tools and trying to do comparisons of my database project and databases in different environments.
But my tsql code uses synonyms to access different databases
I can set this up with publish files as I can set each SQLCMD Variable to the correct environmental setting, and when the script is generated the correct db/server/whatever is inserted.
for example
DEV $(Contoso) = "Contoso_dev"
TEST $(Contoso) = "Contoso_Test"
PROD $(Contoso) = "Contoso_Prod"
However, when I'm doing a database comparison (using .scmp), i have no such option to set CMDvars, so I cant successfully compare with TEST environment because the synonyms are set by project properties which are pointing to the dev environment.
Is there anyway to set CMDVars in SCMP file
Revisited this issue with VS2015 and SSDT 14.0.51215.0 (Dec 2015). (not sure if this will work with original configuration listed above)
By setting the LOCAL value of the cmd Variable, it replaces the cmd variable correctly (regardless of what DB Server you're looking at)
(this did not work, just having the default set)
In the current SSDT version there is no way to use SQLCMD variables in a schema comparison.
But there is a workaround: just debug your database (F5) using the right SQLCMD variables and compare the resulting staging database with the target one.
Hope this helps.
I'm trying to install Oracle 11g Release 2 (client). But it gives an error like that :
Environment variable: "PATH" - This test checks whether the length of the
environment variable "PATH" does not exceed the recommended length.
Expected Value: 1023
Actual Value : 1028
List of errors: - PRVF-3929 : Adding the Oracle binary location to the PATH
environment variable will exceed the OS length limit of [ "1023" ] for the
variable on the node "KamalNuriyev-PC" -
Cause: The installer needs to update the PATH environment variable to
include the value "%ORACLE_HOME%/bin;". However, doing so will
cause PATH to exceed the maximum allowable length that this
operating system allows. - Action: Ensure that the sum of the
lengths of your current PATH environment variable and that of
"%ORACLE_HOME%/bin;" does not exceed the operating system limit.
Restart the installer after correcting the setting for
environment variable.
This limitation is based on older Windows restrictions, where length of environmental variables was important. This limitation is still there in the Oracle installation.
Work around this:
Step 1: Copy the value of your 'path' variable to a text-editor (Ex.: notepad) and save this value as backup.
Step 2: Reduce the size of this path to less that 1023 characters. Remove path variables at the end. You will mostly not need any of them during the oracle installation. Keep those removed values in a separate text-file, because you need to add them again later!
Step 3: Start the oracle installation again.
Step 4: After Oracle installation: Add those removed path values again at the end of the path.
Good luck!
For those who are facing this issue, solution would be to look into your Environment Variable "PATH" and bring it to shorter in length by removing unnecessary paths / repeating paths as suggested by Bob Javis in his comment. Thanks to him.
I had the similar issues and got it resolved by doing so.
To Edit ENV Variable on Windows 7:
Start -> Computer -> Properties -> Advanced System Settings -> On "System properties" window, select "Advanced" tab - > Click on "Environment Variable" -> Scroll down to see the PATH variable and click on "Edit" to edit accordingly and Click "OK" to save
Hope someone might get helped :)
You could check on the ignore all check box on top right and that should enable the next button to continue further.
One way of fixing this is to go to stage\cvu in the installer directory and edit cvu_prereq.xml, replace all values (there are multiple ones) containing 1023 with a larger number and then try to install it again.
Might need to do this after running the installer but before the installer does the check on the different requirements like the PATH length.
After trying with all I found this in the Oracle wiki:
What it says is that you should reduced your string's path changing the "C:\Program Files (x86)" to "C:\PROGRA~2"
Be sure to make a backup of the original path.
Simple,
Check path size, if unnecessary things are there removing that, if not, save it as it is.
And restart oracle installation process.
http://hashtutorial.com/plsql-tutorial/plsql-environment-setup/
Simple solution:
Rename your current PATH variable to PATH2
Then add a new PATH = %PATH2%
Continue with the installation
But, if you don't have unnecessary paths / repeating paths and you can't shorten it(beware! if you delete some necessary paths it can affect corresponding services!), go by removing some paths before oracle installation and return them after the installation.
Or, you can manually ADD the oracle path string in the system PATH variable(add it at the start of the string, not at the end) for your oracle installation.
As example, if you're installing Oracle 11g R2 in the path "c:\ora" then typically the path string for this will be,
C:\ora\product\11.2.0\dbhome\BIN -for server and
C:\ora\product\11.2.0\client_1\BIN -for client. :)
I used two approaches to shorten my PATH environmental variable:
1) Use other environment variables, e.g.:
%CommonProgramFiles(x86)% for "C:\Program Files (x86)\Common Files"
%ProgramFiles(x86)% for "C:\Program Files (x86)"
2) Use 8 character DOS path names, e.g.:
MICROS~4 for "Microsoft SQL Server"
* Your system may have a different number, in a CMD window, browse to the parent folder and type "dir /ad /x"
"%ProgramFiles(x86)%\Micros~4\140\DTS\Binn" is 15 characters shorter than "C:\Program Files (x86)\Microsoft SQL Server\140\DTS\Binn"
I shrank the total length of the PATH from 1120 to 890. Then I could install the Oracle client without a problem.
I had this issue and the only way we could get the PATH test to pass was to remove the computer from the domain and re-add it. Can't explain why, but that worked for us. Best of luck.
In my case, I couldn't install an 11.2.0.4 32 bit client or the 12.2.0.1 64 bit client also, due to this error. After much investigation, I discovered there appears to be a bug when installing it on Windows 10 Enterprise 1703 as hinted at by this issue:
https://dba.stackexchange.com/questions/176774/environment-variable-path-exceeding-recommended-length
In my case, as I was using automation to install this, I ended up recreating my virtual machine as Windows 10 Enterprise LTSC and no longer have this error. In my case, it had nothing to do with the actual path as I had shortened to the point where barely anything was left and it was not enough to resolve the issue.
You can try to run install as administrator.
Hope it helps