I use sql-developer to connect to several different oracle databases with several different users. The connection info is kept in a tnsnames.ora file so that when a database changes servers, I don't have to manually update all my connections to it. I recently updated my tnsnames file, and now there are 2 entries in the network alias list for each one that should be there. The 2nd entry appears to work (IE passes the test when I test the connection). However, by default, it seems to choose the first entry, which doesn't work.
I suspect this is due to the answer here: Oracle TNS names not showing when adding new connection to SQL Developer however, that answer doesn't address how to fix that problem.
So, how do I completely clear the network alias list and force it to re-load from the file?
It was grabbing an old copy of tnsnames.ora_OLD that I had in the same folder. According to:
http://forums.oracle.com/forums/thread.jspa?threadID=1017751
"There is a longstanding feature with SQL Developer's TNS Names functionality where SQL Developer will find all of the matching tnsnames.ora* files in the TNS Admin directory and list the contents of all of them. For example, all of the TNS aliases defined in TNSNAMES.ORA, TNSNAMES.ORA~ and TNSNAMES.ORA.201001210957 will be included in the Network Alias list."
Deleting that old file removed the extra entries.
I found that duplicated TNS names came from following two files;
tnsnames.ora AND tnsnames.~ora
Two options;
option 1. delete file " tnsnames.~ora"
option 2. if you have to keep this " tnsnames.~ora" in the folder, then rename it to like "tnsnames~ora.txt"
** Please note, if you rename it "tnsnames.~ora.txt", it will still shows duplicated.
My understanding is that if filename start with "tnsnames" and ends with "ora",
it will gives you duplicated TNS names.
Related
What does it means if the TNS_Names directory is empty in Preferences GUI of SQL Developer?
It just means that there is no tnsnames.ora file for SQL Developer to use, so you can't use TNS entries when defining connections.
It won't stop you defining other connection types - 'Basic', 'Custom JDBC' etc. - you just won't be able to use 'TNS' as there won't be any options to pick from in the 'Network alias' drop-down; and if you're previously picked one and then removed the tnsnames.ora then it won't be recognised any more.
I'm quite new to android and I am currently working on a app which should utilize a Room database. Following the documentation a room database can be created through the following lines:
myDatabase = Room.databaseBuilder(appContext, MyDatabase.class, "MyDB")
.build();
Now where did room create the database file?
It can't be found in my project folder.
The documentation doesn't mention anything about it and -generally speaking- barely gives any information about how this thing works.
Where is the database?
Does DatabaseBuilder.build() manage, to open the existing database created from previous app launches?
The list of questions is long.
Any information about the .build() thing aswell as further information about Room (misconceptions etc.) are very appreciated, for the documentation doesn't really make things clear for me.
Thank you!
Now where did room create the database file?
The database (a file) will be placed at the default location on the actual device which is data/data/<the_package_name>/database/MyDB.
In your case, as you have coded :-
myDatabase = Room.databaseBuilder(appContext, MyDatabase.class, "MyDB")
.build();
Then the database files will be: -
data/data/<your_package_name>/databases/MyDB
data/data/<your_package_name>/databases/MyDB-wal
data/data/<your_package_name>/databases/MyDB-shm
It can't be found in my project folder.
The database file is not part of the project, it is a file that is created and maintained on the actual device on which the App has been installed.
However, you can use Database Inspector (now App Inspection) on Android Studio to view the database e.g. :-
You can also view the files, if whatever device you test on allows access, by using Device File Explorer. e.g.
Does DatabaseBuilder.build() manage, to open the existing database created from previous app launches?
Yes, if the file exists then it is opened otherwise the file is created. If you uninstall the App this effectively delete's the file. The whole idea of a database is that it persists.
The build() undertakes various tasks, primarily seeing if the underlying file exists and then opening the file. In doing so it
extracts the version number that is stored in the file and compares the number against the number coded within the App (via the #Database).
If the version number from the App is greater then an attempt is tried to find a Migration (recently AutoMigration's have been added to Room).
compares the expected schema (according to the entities defined as part of the #Database), against what is found in the file.
A mismatch will result in the app crashing, so fixes would have to be made.
Note references to file is a simplification, by default Room uses a loggin mode called WAL (Write-Ahead Logging). In WAL mode there will be an additional 2 files that the SQLite routines maintain (you don't need to do anything):-
the database file name suffixed with -wal is the primary wal file into which changes are written (they are applied to the main database automatically).
the database file name suffixed with -shm (this is a WAL file for the WAL file).
I'm using the check_logfiles nagios plugin to monitor Oracle alert logs. It works wonderfully for that purpose.
However I also need to monitor and entire directory of oracle trace logs for errors. This is because the oracle database is always creating new log files with different names.
What I need to know is the best way to scan an entire directory of oracle trace logs to find out which ones match patterns that specify oracle alerts.
Using check logfiles I tried specifying these options -
--criticalpattern='ORA-00600|ORA-00060|ORA-07445|ORA-04031|Shutting
down instance'
and to specify the directory of logs -
--logfile='/global/cms/u01/app/orahb/admin/opbhb/udump/'
and
--logfile="/global/cms/u01/app/orahb/admin/opbhb/udump/*"
Neither of which have any effect. The check runs but returns ok. Does anyone know if this nagios plugin called check_logfiles can monitor a directory of files rather than just a single file? Or perhaps there is another, better way to achieve the same goal of monitoring a bunch of files that can't be specified ahead of time?
Use a script which:
Opens each file
Copies entries which match the pattern
Outputs the matches to a file
In my attempt to extract data (dumps and selective reading of columns) from a diverse collection of edb databases I got faced with a fundamental problem. I have an edb database coming with a couple of log files. I know what information there is within the database, but I just get half of it extracted. I fear that the remaining half sleeps somewhere in the log files. I assumed the EDB engine knows where the log files are and automagically loads them when attaching the database (JET_paramSystemPath, JET_paramLogFilePath and JET_paramBaseName are properly set). Is that a wrong assumption? If so, what should I do to have the logs loaded as well?
Alternatively, would it be possible to simply commit the transactions to the EDB file and get rid of the logs?
If there are uncommitted transactions then the database will be marked as 'inconsistent'. You can check this using ESENTUTL /MH against the database. Calling JetAttachDatabase against an inconsistent database will always fail.
So, if your program is able to attach and open the database then it is consistent. There are two ways a database can be made consistent:
A clean shutdown of ESENT.
Running recovery using the logfiles at JetInit time.
The first thing that JetInit does is to look for the logfiles specified by JET_paramLogFilePath and JET_paramBaseName. Logfiles contain the full paths of the database(s) they reference and the transactions in the logfiles are then committed to the database(s). So, if you set the system parameters properly then ESENT will load the logs when attaching the database.
On the other hand, if you don't set the parameters properly then your program will actually work on databases that don't require recovery. JetInit won't find any logfiles so it won't do anything and the attach will succeed because the database is consistent.
One further twist is that the logfiles contain the full path to the database. This means that if you have copied/moved the database then recovery will not work. Starting with Windows Server 2003 you can deal with this by setting JET_paramAlternateDatabaseRecoveryPath to the directory containing the database.
Important: to be safe you should always attach and open the database using the read-only flags. This will avoid any problems caused by bad logfile settings. A common problem is that read-only applications end up creating a set of logfiles in a different directory which prevent the database from being recovered properly.
I've been wondering this for a while but since it hasn't come up much I've left it in the 'mysterious wizardy' column.
It seems to me that there is some sort of relationship between a connection identifier like ABC and ABC.DEFG and I don't quite get what it is.
For example, a machine I was setting up just now I was having problems with using the identfier ED2 even though in my tnsnames file I clearly had
EDC2 = (....)
This was copied and pasted from another computer which worked just fine. However, doing tnsping EDC2 would fail to resolve until I changed it to say
EDC2.WORLD = (...)
at which point resolving to EDC2 started working. What is going on here?
The TNS alias in the tnsnames.ora file interacts with the parameter
NAMES.DEFAULT_DOMAIN
in the sqlnet.ora file. If NAMES.DEFAULT_DOMAIN is set to WORLD, for example, then when you try to connect to an alias without a domain, the sqlnet.ora file tells Oracle to automatically append the domain before doing the lookup in the tnsnames.ora file. If you try to connect to an alias with a domain, NAMES.DEFAULT_DOMAIN is ignored.
My general preference/ suggestion is to set NAMES.DEFAULT_DOMAIN to WORLD in the sqlnet.ora and specify EDC2.WORLD in the tnsnames.ora file. That way, both the connect identifier EDC2 and EDC2.WORLD will work-- the former gets changed to the latter because of the DEFAULT_DOMAIN parameter.