I am trying to load the data into the tables but i get this error: "COPY INTO: insufficient privileges: COPY INTO from .. LOCKED requires tables without indices"
The code I use to create the table:
CREATE TABLE region (
r_regionkey INT NOT NULL,
r_name CHAR(25) NOT NULL,
r_comment VARCHAR(152));
The code I use to load the table:
COPY 5 RECORDS INTO region FROM 'C:\Users\gewrg\Desktop\ADM 1\tpch_2_17_1\dbgen\SF-1\data\region.tbl' USING DELIMITERS '|', '|\n', '"' LOCKED;
Is there a problem with the absolute path I use?
To use COPY INTO and COPY FROM, users need to be explicitly granted the permissions. Please see https://www.monetdb.org/Documentation/SQLReference/DataDefinition/Privileges/GrantAndRevoke.
If LOCKED is the cause of your trouble as mentioned above by Pedro, you can just remove it. LOCKED was introduced for higher data loading speed when there is no contention but in my experiences, there's barely any performance gain.
Are you sure you didn't create any key (primary or foreign) before the COPY INTO statement? That's because MonetDB creates an index for every primary/foreign key created, then you get this error message on COPY INTO LOCKED.
(This looks more like a comment, because I don't have enough reputation to give comments yet)
Related
I've been trying to setup an Oracle database for certification/study purposes. I have been utilizing the docker image building script in my project to help create an easily recyclable database and I'm having some trouble creating my initial schemas.
The README documentation I found states that I should be able to create a number of setup scripts that are kicked off automatically when the database is ready, all I need to do is place them in the /opt/oracle/scripts/setup/ directory.
I tried doing that in my Dockerfile, and while they do execute they don't succeed with even the most trivial example I came up with.
For example, I tried creating a user named student and immediately came across an error specific to Oracle 12's multi-tennancy. Not really wanting to care about it, since it's not something covered by the 1Z0-071 certification, I took the black-magic answer and moved on.
But I was immediately blocked again by an even stranger error in my code.
CREATE SEQUENCE simpledata.simpledata_pk_sequence;
INSERT INTO simpledata.simpledata (id, text)
VALUES (simpledata.simpledata_pk_sequence.nextval, 'Hi, I''m Paul')
*
ERROR at line 2:
ORA-01950: no privileges on tablespace 'USERS'
Which seems to point to the fact that I'm doing something out-right wrong. I should be able to initialize the database with whatever arbitrary users and data. This leads me to believe I'm either missing configuration steps, I'm using the wrong user, or something else entirely that I'm not aware of.
What is the correct way to run an arbitrary setup script in Oracle 12?
I don't know if this will cover what you ask, because it looks like a question with different answers as alternatives to do it.
Anyway, your scripts look ok, except for the fact that you are missing something in the second one respect to the first one.
Script
{{ with .SimpleData }}
CREATE USER simpledata IDENTIFIED BY {{ RandomPassword }} DEFAULT TABLESPACE USERS TEMPORARY TABLESPACE TEMP PROFILE DEFAULT QUOTA UNLIMITED ON USERS ;
CREATE TABLE simpledata.simpledata (
id NUMBER(9) PRIMARY KEY,
text VARCHAR2(20)
);
CREATE SEQUENCE simpledata.simpledata_pk_sequence;
{{ range .Items }}
INSERT INTO simpledata.simpledata (id, text)
VALUES (simpledata.simpledata_pk_sequence.nextval, '{{ . }}');
{{ end }}
If you ask me how is the way to create schemas and data, I would go for creating the things separately and in the right order:
Schemas
Sequences
Tables
DML scripts ( Insert, Update, etc..)
Functions , Procedures and Packages.
Example user creation in your case
SQL> create user simpledata identified by "Passw_1" default tablespace users temporary tablespace temp account unlock profile default quota unlimited on users;
User created.
Elapsed: 00:00:00.09
SQL>
I recently encountered a Strange issue on Merge statement. It failed with ORA 30926 error.
I have already checked for the below pitfalls,
Duplicate records check in Source and Target table – Came out clean
Source and Target tables Analyze structure – Came out clean
Source and Target tables Indexes Analyze structure – Came out clean
Same Merge SQL when DBA tried in SYS user – Worked. Still Puzzling
Same Merge SQL runs successfully in Copy table of Target – Worked. Still Puzzling
DBA Bounced the TEST server. Though not convincing wanted to give a try as the issue appears to be strange – Didn’t Workout
Gathered the statistics
Truncate the Original target table and reload from Copy table and try the Merge again - Didn't Workout. Failed with same error
Nutshell Script:
MERGE INTO TGT_SCHEMA.EMP T
USING SRC_SCHEMA.S_EMP S
ON
(
T.EMPLOYEE_NO = S.EMPLOYEE_NO AND
T.START_DATE = S.START_DATE
)
Unique Index (EMPLOYEE_NO, START_DATE) exists on Target table and a normal Index of same combination exists on Source table. Target table is a partitioned table and there are some VPD policies applied to other columns.
My Database version : Oracle 11.2.0.3.0
If you really checked everything you said correctly, then this is a bit of a puzzler. I think #4 in your diagnostic checklist may be telling: that the same statement worked when executed as SYS.
For fun, check to see where there are any VPD policies on either table (DBMS_RLS package). If there are, try to disable them and retry the merge.
This error happens on MERGE when the USING clause returns more than one row for one or more target rows according to your matching criteria. Since it can't know which of two updates to do first, it gives up.
Run:
SELECT matching_column1, ..matching_ColumnN, count(*)
FROM (
<your USING query>
)
group by matching_column1, ..matching_ColumnN
having count(*) > 1
To find the offending source data. At that point either modify your USING query to resolve it, change your matching criteria, or clean up bad data - whichever is appropriate.
EDIT - Add another item:
One other possibility - you will get this error if you try to update a column in your target that is referenced in your ON clause.
So make sure that you are not trying to UPDATE the EMPLOYEE_NO or START_DATE fields.
I'm using a Win XP box with BDE Administrator and Access 2007 installed. I'm able to open and perform select queries on existing Paradox tables without problem but have some very strange behavior when attempting INSERT/UPDATE. I can even create a new Paradox table and it has the same behavior. Here is sample code:
' create new table
conObj.Execute "CREATE TABLE test (id INT, comment VARCHAR(30))"
' first insert works fine
conObj.Execute "INSERT INTO test VALUES (1, 'something')"
' second insert fails for unknown reason
conObj.Execute "INSERT INTO test VALUES (2, 'something else')"
I've tried using Jet 4.0, MS Access Paradox driver, and native Paradox driver connection strings but all yield the same result. On the second insert statement it throws an error:
Operation must be an updateable query
I've read numerous posts in forums and pages on help sites that tell me this error is caused by a file permissions issue. The account running this script is part of the Administrator group and I've changed file permissions to allow the Everyone group Full Control of the db file but this changes nothing.
This page put out by Micrsoft Support did not fix the problem: http://support.microsoft.com/kb/175168
Additionally, I can create a new table but any time I try to create a PRIMARY KEY or UNIQUE field I get an error message that says:
"Index_[random characters] is not a valid name."
try
"CREATE TABLE test (id INT, comment VARCHAR(30), primary key(id))"
I don't know much about Paradox databases but this has indeed been a learning experience. Even though I have a table file called table.db that's not enough to store more than a single row of data. I also need several other files to insert or update a paradox database:
table.DB
table.PX
table.VAL
table.XG0
table.XG1
table.YG0
table.YG1
I was nosing around in another program that generates paradox databases and found when I copied a blank database from it along with these other files it generated I was able to insert and update without problems. I have no idea what these files are for or why they need to be present to insert or update but having them present fixed my issue.
I have a - for me unknown - issue and I don't know what's the logic/cause behind it. When I try to insert a record in a table I get a DB2 error saying:
[SQL0803] Duplicate key value specified: A unique index or unique constraint *N in *N
exists over one or more columns of table TABLEXXX in SCHEMAYYY. The operation cannot
be performed because one or more values would have produced a duplicate key in
the unique index or constraint.
Which is a quite clear message to me. But actually there would be no duplicate key if I inserted my new record seeing what records are already in there. When I do a SELECT COUNT(*) from SCHEMAYYY.TABLEXXX and then try to insert the record it works flawlessly.
How can it be that when performing the SELECT COUNT(*) I can suddenly insert the records? Is there some sort of index associated with it which might give issues because it is out of sync? I didn't design the data model, so I don't have deep knowledge of the system yet.
The original DB2 SQL is:
-- Generate SQL
-- Version: V6R1M0 080215
-- Generated on: 19/12/12 10:28:39
-- Relational Database: S656C89D
-- Standards Option: DB2 for i
CREATE TABLE TZVDB.PRODUCTCOSTS (
ID INTEGER GENERATED BY DEFAULT AS IDENTITY (
START WITH 1 INCREMENT BY 1
MINVALUE 1 MAXVALUE 2147483647
NO CYCLE NO ORDER
CACHE 20 )
,
PRODUCT_ID INTEGER DEFAULT NULL ,
STARTPRICE DECIMAL(7, 2) DEFAULT NULL ,
FROMDATE TIMESTAMP DEFAULT NULL ,
TILLDATE TIMESTAMP DEFAULT NULL ,
CONSTRAINT TZVDB.PRODUCTCOSTS_PK PRIMARY KEY( ID ) ) ;
ALTER TABLE TZVDB.PRODUCTCOSTS
ADD CONSTRAINT TZVDB.PRODCSTS_PRDCT_FK
FOREIGN KEY( PRODUCT_ID )
REFERENCES TZVDB.PRODUCT ( ID )
ON DELETE RESTRICT
ON UPDATE NO ACTION;
I'd like to see the statements...but since this question is a year old...I won't old my breath.
I'm thinking the problem may be the
GENERATED BY DEFAULT
And instead of passing NULL for the identity column, you're accidentally passing zero or some other duplicate value the first time around.
Either always pass NULL, pass a non-duplicate value or switch to GENERATED ALWAYS
Look at preceding messages in the joblog for specifics as to what caused this. I don't understand how the INSERT can suddenly work after the COUNT(*). Please let us know what you find.
Since it shows *N (ie n/a) as the name of the index or constraing, this suggests to me that is is not a standard DB2 object, and therefore may be a "logical file" [LF] defined with DDS rather than SQL, with a key structure different than what you were doing your COUNT(*) on.
Your shop may have better tools do view keys on dependent files, but the method below will work anywhere.
If your table might not be the actual "physical file", check this using Display File Description, DSPFD TZVDB.PRODUCTCOSTS, in a 5250 ("green screen") session.
Use the Display Database Relations command, DSPDBR TZVDB.PRODUCTCOSTS, to find what files are defined over your table. You can then DSPFD on each of these files to see the definition of the index key. Also check there that each of these indexes is maintained *IMMED, rather than *REBUILD or *DELAY. (A wild longshot guess as to a remotely possible cause of your strange anomaly.)
You will find the DB2 for i message finder here in the IBM i 7.1 Information Center or other releases
Is it a paging issue? we seem to get -0803 on inserts occasionally when a row is being held for update and it locks a page that probably contains the index that is needed for the insert? This is only a guess but it appears to me that is what is happening.
I know it is an old topic, but this is what Google shown me on the first place.
I had the same issue yesterday, causing me a lot of headache. I did the same as above, checked the table definitions, keys, existing items...
Then I found out the problem was with my INSERT statement. It was trying to insert to identical records at once, but as the constraint prevented the commit, I could not find anything in the database.
Advice: review your INSERT statement carefully! :)
I apologize for posting a question that seems to have been asked numerous times on the internet, but I can't quite fix it for some reason.
I was trying to populate some tables using Oracle's magical sqldr utility, but it throws an ORA-01775 error for some reason.
Everywhere I go on Google, people say something along the lines of: "Amateur, get your synonyms sorted out" (that was paraphrased) and that's nice and all, but I did not make any synonyms.
Here, the following does not work on my system:
SQLPLUS user/password
SQL>CREATE TABLE test (name varchar(10), id number);
SQL>exit
Then, I have a .ctl file with the following contents:
load data
characterset utf16
infile *
append
into table test
(name,
id
)
begindata
"GURRR" 4567
Then I run this command:
sqlldr user#localhost/password control=/tmp/controlfiles/test.ctl
The result:
SQL*Loader-702: Internal error - ulndotvcol: OCIStmtExecute()
ORA-01775: looping chain of synonyms
Part of test.log:
Table TEST, loaded from every logical record.
Insert option in effect for this table: APPEND
Column Name Position Len Term Encl Datatype
------------------------------ ---------- ----- ---- ---- ---------------------
NAME FIRST 2 CHARACTER
ID NEXT 2 CHARACTER
SQL*Loader-702: Internal error - ulndotvcol: OCIStmtExecute()
ORA-01775: looping chain of synonyms
And, if I try to do a manual insert:
SQL> insert into test values ('aa', 56);
1 row created.
There is no problem.
So, yeah, I am stuck!
If it helps, I am using Oracle 11g XE on CentOS.
Thanks for the help guys, I appreciate it.
EDIT:
I kind of, sort of figured out part of the problem. The problem was that somewhere along the line, maybe during a failed load or something, Oracle had given itself corrupt views and synonyms.
The affected views were: GV_$LOADISTAT, GV_$LOADPSTAT, V_$LOADISTAT and V_$LOADPSTAT. I am not quite sure why the views got corrupt, but recompiling them resulted in compiled with errorserrors. The synonyms used in the queries themselves were corrupt, namely the gv$loadistat, gv$loadpstat, v$loadistat and v$loadpstat synonyms.
I wasn't sure about why this was happening and I didn't quite understand anything. So, I decided to drop the synonyms and recreate them. Unfortunately, I couldn't recreate them, as the view they pointed to (there is a bit of weird recursion going on here...) was corrupt. These views were the aforementioned GV_$LOADISTAT and other views. In other words, the synonyms pointed to the views that used those synonyms. Talk about a looping chain.
So...I recreated the public synonyms but instead of specifying the view as GV_$LOADISTAT, I specified them as sys.GV_$LOADISTAT. e.g.
DROP PUBLIC synonym GV$LOADISTAT;
CREATE PUBLIC synonym GV$LOADISTAT for sys.GV_$LOADISTAT;
Then, I recreated the user views to point to those public synonyms.
CREATE OR REPLACE FORCE VIEW "USER"."GV_$LOADISTAT" ("INST_ID", "OWNER", "TABNAME", "INDEXNAME", "SUBNAME", "MESSAGE_NUM", "MESSAGE")
AS
SELECT "INST_ID",
"OWNER",
"TABNAME",
"INDEXNAME",
"SUBNAME",
"MESSAGE_NUM",
"MESSAGE"
FROM gv$loadistat;
That seemed to fix the views/synonyms. Yeah, it is a bit of a hack, but it somehow worked. Unfortunately, this was not enough to run SQL Loader. I got a table or view does not exist error.
I tried granting more permissions to my regular user, but it didn't work. So, I gave up and ran SQL Loader as sysdba. It worked! It is not a good thing to do, but it is a development only system made for testing purposes, so, I didn't care.
I could not repeat your looping synonym chain error, but it appears the control file needed a bit of work, at least for my environment.
I was able to get your example to work by modifying it thusly:
load data
infile *
append
into table test
fields terminated by "," optionally enclosed by '"'
(name,
id
)
begindata
"GURRR",4567