I am following these instructions.
I have created a docker container like this:
docker run --name oracle \
-p 1521:1521 \
-e ORACLE_SID=ORASID \
-e ORACLE_PDB=ORAPDB \
-e ORACLE_PWD=F1f#f23_ \
-v /mnt_point/oradata:/home/oracle/oradata \
oracle/database:12.2.0.1-ee
The output is:
#########################
DATABASE IS READY TO USE!
#########################
The following output is now a tail of the alert.log:
Completed: alter pluggable database ORAPDB open
2017-08-07T19:16:31.190780+00:00
ORAPDB(3):CREATE SMALLFILE TABLESPACE "USERS" LOGGING DATAFILE '/opt/oracle/oradata/ORASID/ORAPDB/users01.dbf' SIZE 5M REUSE AUTOEXTEND ON NEXT 1280K MAXSIZE UNLIMITED EXTENT MANAGEMENT LOCAL SEGMENT SPACE MANAGEMENT AUTO
ORAPDB(3):Completed: CREATE SMALLFILE TABLESPACE "USERS" LOGGING DATAFILE '/opt/oracle/oradata/ORASID/ORAPDB/users01.dbf' SIZE 5M REUSE AUTOEXTEND ON NEXT 1280K MAXSIZE UNLIMITED EXTENT MANAGEMENT LOCAL SEGMENT SPACE MANAGEMENT AUTO
ORAPDB(3):ALTER DATABASE DEFAULT TABLESPACE "USERS"
ORAPDB(3):Completed: ALTER DATABASE DEFAULT TABLESPACE "USERS"
2017-08-07T19:16:32.867558+00:00
ALTER SYSTEM SET control_files='/opt/oracle/oradata/ORASID/control01.ctl' SCOPE=SPFILE;
ALTER PLUGGABLE DATABASE ORAPDB SAVE STATE
Completed: ALTER PLUGGABLE DATABASE ORAPDB SAVE STATE
I kill it via ctrl+c. I then run:
docker start oracle
docker logs -f oracle
#########################
DATABASE IS READY TO USE!
#########################
The following output is now a tail of the alert.log:
ORAPDB(3):Undo initialization finished serial:0 start:508498668 end:508498772 diff:104 ms (0.1 seconds)
ORAPDB(3):Database Characterset for ORAPDB is AL32UTF8
ORAPDB(3):Opatch validation is skipped for PDB ORAPDB (con_id=0)
2017-08-07T19:25:39.799508+00:00
ORAPDB(3):Opening pdb with no Resource Manager plan active
Pluggable database ORAPDB opened read write
Starting background process CJQ0
Completed: ALTER DATABASE OPEN
2017-08-07T19:25:40.536753+00:00
CJQ0 started with pid=38, OS id=239
2017-08-07T19:25:42.538433+00:00
Shared IO Pool defaulting to 64MB. Trying to get it from Buffer Cache for process 77.
===========================================================
Dumping current patch information
===========================================================
No patches have been applied
===========================================================
I then attempt to connect like this:
docker exec -ti oracle sqlplus pdbadmin#ORAPDB
The result is:
ORA-12154: TNS:could not resolve the connect identifier specified
It then asks me for a username. Regardless of which user SYS, SYSTEM or PDBADMIN, I cannot connect. I have retyped the password (F1f#f23_) a multitude of times to make sure it was not a typo. Any thoughts on this would be appreciated.
I've encountered this with those images, too. You will first have to open the pluggable database before you can connect to it.
I do that with something like this:
docker exec -ti oracle sqlplus / as sysdba
alter pluggable database pdb1 open;
Yes, I got the same error after setting up Oracle database in docker too.
So first check the instance is running (and look for the ORACLE_SID):
The Oracle SID is ORCLCDB.
If you don't have the environment set for ORACLE_SID, you get:
Connection failed.
But after you set your ORACLE_SID:
And now you no longer get the connection failure error, but a different SYSDBA instead.
Just add "/ as sysdba" to your entire sqlplus command and you are good to go.
Once the container has been started and the database created you can connect to it just like to any other database by one of the following methods:
1) sqlplus sys/<your password>#//localhost:1521/<your SID> as sysdba
2) sqlplus system/<your password>#//localhost:1521/<your SID>
3) sqlplus pdbadmin/<your password>#//localhost:1521/<Your PDB name>
Running SQL*Plus in a Docker container
You may use the same Docker image you used to start the database, to run sqlplus to connect to it, for example:
docker run --rm -ti oracle/database:12.2.0.1-ee sqlplus pdbadmin/<yourpassword>#//<db-container-ip>:1521/ORCLPDB1
Another option is to use docker exec and run sqlplus from within the same container already running the database:
docker exec -ti <container name> sqlplus pdbadmin#ORCLPDB1
To run your Oracle Database Docker image use the docker run command as follows:
docker run --name <container name> \
-p <host port>:1521 -p <host port>:5500 \
-e ORACLE_SID=<your SID> \
-e ORACLE_PDB=<your PDB name> \
-e ORACLE_PWD=<your database passwords> \
-e ORACLE_CHARACTERSET=<your character set> \
-v [<host mount point>:]/opt/oracle/oradata \
oracle/database:12.2.0.1-ee
Parameters:
--name: The name of the container (default: auto generated)
-p: The port mapping of the host port to the container port.
Two ports are exposed: 1521 (Oracle Listener), 5500 (OEM Express)
-e ORACLE_SID: The Oracle Database SID that should be used (default: ORCLCDB)
-e ORACLE_PDB: The Oracle Database PDB name that should be used (default: ORCLPDB1)
-e ORACLE_PWD: The Oracle Database SYS, SYSTEM and PDB_ADMIN password (default: auto generated)
-e ORACLE_CHARACTERSET:
The character set to use when creating the database (default: AL32UTF8)
-v /opt/oracle/oradata
The data volume to use for the database.
Has to be owned by the Unix user "oracle" or set appropriately.
If omitted the database will not be persisted over container recreation.
-v /opt/oracle/scripts/startup | /docker-entrypoint-initdb.d/startup
Optional: A volume with custom scripts to be run after database startup.
For further details see the "Running scripts after setup and on startup" section below.
-v /opt/oracle/scripts/setup | /docker-entrypoint-initdb.d/setup
Optional: A volume with custom scripts to be run after database setup.
For further details see the "Running scripts after setup and on startup" section below.
useful: https://github.com/oracle/docker-images/tree/master/OracleDatabase
In my case, the definition of environment variable TNS_ADMIN was causing the issue with ORA-12154.
I could successfully connect to the instance inside of the XE container: sqlplus test/test#//localhost:1521/XEPDB1, but not from outside.
After removing TNS_ADMIN it worked. I think, sqlplus takes TNS_ADMIN setting, and if it exists, it takes the tnsnames.ora data to resolve the connection. But of course, the Oracle XE instance from inside docker is not listed there.
As an alternative, you could use this syntax, which works although there is a tnsnames.ora defined: sqlplus test/test#'(DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=localhost)(PORT=1521))(CONNECT_DATA=(SERVICE_NAME=XEPDB1)))'
This instruction worked for me:
Starting SQL*Plus and Connecting to the Database
https://docs.oracle.com/database/121/ADMQS/GUID-DE8A79BD-FAE4-4364-98FF-D2BD992A06E7.htm#ADMQS0361
Basically get into the oracle container, then enter sqlplus. type SYS AS SYSDBA at the user name prompt, and then password. After that, I create the user and tables.
I think you are looking for this.
datasource:
url: jdbc:oracle:thin:#//localhost:1521/ORCLPDB1.localdomain
username: SYS as SYSDBA
password: Oradoc_db1
Related
When running the following command after pg_ctl initdb and pg_ctl start commands:
C:\Program Files\PostgreSQL\11\bin>psql.exe -U postgres -h localhost
I am getting the following error:
role "postgres" doesn't exist
All similar questions are about Linux or Mac and they don't help me much, so I don't know how to fix it.
Since you didn't specify a username with -U when you ran initdb, the bootstrap superuser has the name of the operating system user with which you ran initdb.
So you can simply connect with
psql
If you would like to change the name of the user to postgres, that is simple:
-- get the name of the current user in a variable
SELECT current_user \gset
CREATE ROLE dummy SUPERUSER;
-- connect as user "dummy"
\c - dummy
-- rename the bootstrap user to "postgres"
ALTER ROLE :"current_user" RENAME TO postgres;
-- remove "dummy"
\c - postgres
DROP ROLE dummy;
-- disconnect
\q
I'm importing a large drupal database to my mac using mamp and I keep finding errors, the phpmyadmin can't import the database. can anyone help me?
Importing a large database through phpmyadmin is not recommended (it will typically hangup forever). It's much more efficient to use the command line through the Terminal.
First, make sure you can connect to your database from the command line with one of the following commands:
1/ If your root password isn't set:
mysql -u root
2/ or if you have a root password:
mysql -u root -p
3/ or if you have a specific username and password:
mysql -u username -p
If one of those commands execute correctly, you're good to go to the next step.
Notice you can exit the mysql interactive session anytime with entering:
exit
List your databases:
SHOW databases;
If you don't have your database listed here, you will need to create it:
CREATE DATABASE database_name CHARACTER SET utf8 COLLATE utf8_general_ci;
Then select your database:
USE database_name;
Finally, import the data from your sql file:
SOURCE "path/to/your/file.sql"
Second method (it suppose your database is already created)
mysql -u username -p database_name < path/to/your/file.sql
I have written a bash script which connects to the db and run query. These query are fetched from a file. This was working till I was using mysql on local desktop using lampp. But now connecting db on other server using sqlplus64 is returning
SQL*Plus: Release 12.2.0.1.0 Production
Copyright (c) 1982, 2016, Oracle. All rights reserved.
Use SQL*Plus to execute SQL, PL/SQL and SQL*Plus statements.
Usage 1: sqlplus -H | -V
-H Displays the SQL*Plus version and the
usage help.
-V Displays the SQL*Plus version.
Usage 2: sqlplus [ [<option>] [{logon | /nolog}] [<start>] ]
<option> is: [-AC] [-C <version>] [-L] [-M "<options>"] [-NOLOGINTIME] [-R <level>]
[-S]
-AC Enable Application Continuity.
-C <version> Sets the compatibility of affected commands to the
version specified by <version>. The version has
the form "x.y[.z]". For example, -C 10.2.0
-L Attempts to log on just once, instead of
reprompting on error.
-M "<options>" Sets automatic HTML or CSV markup of output. The options
have the form:
{HTML html_options|CSV csv_options}
See SQL*Plus User's Guide for detailed HTML and CSV options.
-NOLOGINTIME Don't display Last Successful Login Time.
-R <level> Sets restricted mode to disable SQL*Plus commands
that interact with the file system. The level can
be 1, 2 or 3. The most restrictive is -R 3 which
disables all user commands interacting with the
file system.
-S Sets silent mode which suppresses the display of
the SQL*Plus banner, prompts, and echoing of
commands.
<logon> is: {<username>[/<password>][#<connect_identifier>] | / }
[AS {SYSDBA | SYSOPER | SYSASM | SYSBACKUP | SYSDG | SYSKM | SYSRAC}] [EDITION=value]
Specifies the database account username, password and connect
identifier for the database connection. Without a connect
identifier, SQL*Plus connects to the default database.
The AS SYSDBA, AS SYSOPER, AS SYSASM, AS SYSBACKUP, AS SYSDG,
AS SYSKM and AS SYSRAC options are database administration privileges.
<connect_identifier> can be in the form of Net Service Name
or Easy Connect.
#[<net_service_name> | [//]Host[:Port]/<service_name>]
<net_service_name> is a simple name for a service that resolves
to a connect descriptor.
Example: Connect to database using Net Service Name and the
database net service name is ORCL.
sqlplus myusername/mypassword#ORCL
Host specifies the host name or IP address of the database
server computer.
Port specifies the listening port on the database server.
<service_name> specifies the service name of the database you
want to access.
Example: Connect to database using Easy Connect and the
Service name is ORCL.
sqlplus myusername/mypassword#Host/ORCL
The /NOLOG option starts SQL*Plus without connecting to a
database.
The EDITION specifies the value for Session Edition.
<start> is: #<URL>|<filename>[.<ext>] [<parameter> ...]
Runs the specified SQL*Plus script from a web server (URL) or the
local file system (filename.ext) with specified parameters that
will be assigned to substitution variables in the script.
When SQL*Plus starts, and after CONNECT commands, the site profile
(e.g. $ORACLE_HOME/sqlplus/admin/glogin.sql) and the user profile
(e.g. login.sql in the working directory) are run. The files may
contain SQL*Plus commands.
Refer to the SQL*Plus User's Guide and Reference for more information.
this query is duplicate and is not executed
Why am I not able to see the successful output and the error code ?
This is my bash script
RAW=`cat sqlTemp.sql`
IFS=";"
for var in $RAW
query=$(echo $var | sed '/^$/d')
do
sqlplus64 username/password#hostname:portnumber/servicename $query 2>>errorLog.txt
done
content of my sqlTemp.sql
select name from TEMP_DB_QUERY_AUTOMATIO;
select *from TEMP_DB_QUERY_AUTOMATION;
select *from TEMP_DB_QUERY_AUTOMATION;
select qlid from TEMP_DB_QUERY_AUTOMATION;
select *from TEMP_DB_QUERY_AUTOMATION;
select email TEMP_DB_QUERY_AUTOMATION;
I want to connect to multiple (30) oracle databases which resides in different servers (27) via shell script and fetch details from each database. I have a user (test) created on all databases but the details I want to fetch needs sysdba privileges. In my environment, I cannot provide DBA privs to any other user due to limitations. Hence my idea is to connect to each database using sqlplus -s "$user/$password#$tnsentry" and then connect as sysdba to fetch details.
Though I am able to connect to all databases using test, the "connect as sysdba" is getting executed on current database in current server.
My script:
cat tmp/db.par | while read LINE
do
if [ -n "$LINE" ] ; then
tns_entry=$LINE
export tns_entry
sqlplus -s /nolog >> $tmp/query.log <
exit
sqlconn
fi
done
In the tns_entry loop, I have given ABC,DEF,GHI,JKL,MNO databases to get details from and I am running this query from a server where database XYZ resides. I didn't give XYZ in my loop and didn't connect to database but the query results are from XYZ database. Please help me on this.
Thank you!
You should connect as sysdba
add "as sysdba" in the script and try.
conn sys/password#tnsentry as sysdba
I want to be able to clone the contents of our postgre production database to an ownerless local database efficiently. I've successfully done this, but it was a laborious process with the following steps
$ pg_dump [prod_db] > tempfile
[Go through tempfile manually removing all 60ish references to the owner, named 'postgres']
$ cat tempfile > psql [local_db]
Otherwise when I ran the last step, I got a bunch of SQL error messages saying ERROR: role "postgres" does not exist. I tried recreating the local db with a matching 'postgres' owner, but a) I still got the same type of errors, and b) I don't want to have an owner set for my local database if it means I'll have to log into it.
Is there a best practice/efficient way of doing this if I want to re-clone it in future?
Use the -O switch to not have an owner defined in the dump.
Not having an owner set is not normal Postgres design. To avoid having to login to your postgres database you can setup a .pgpass file. This is a plain text file and should be set with 600 permissions. The contents will look like:
hostname:port:database:username:password
Each connection can be on one line.
Additionally, for local db connections, assuming you have setup the rest of your security properly (ssh certs, etc) you can edit your pg_hba.conf file and set local connection authentication method to "trust." This is obviously not recommended for production or sensitive data. The line would look like this:
local all all trust
The default method is "peer". Unless you set your username in a .pgpass file you will still need to connect with psql -U postgres but you will not need to enter a password.