Monday, October 20, 2014

Svn client error svn: E160006: Invalid revision number '-1'

Topic : svn: E160006: Invalid revision number '-1' 

I have recently come across this error when I installed the svn client on my machine. I have the latest version of tortoise svn client on my local machine. After install I used to get this weird error when ever I used to do check out.

 


Unexpected HTTP status 500 'Server Error' on
 '/scm/svn/database/releases/!svn/vcc/default'
Additional errors:
svn: E160006: Invalid revision number '-1'


 I goggled a lot but nothing seems to work. Finally I figured out. The client and server versions are not same then I downloaded the same version of the tortoise client as of server. Then it seemed to work fine.


Conclusion :

Try to download the tortoise svn of same version as of server and it seems to work fine without any problem.

Wednesday, September 24, 2014

Duplicate values in a table


Create table sql :

 CREATE TABLE ABC (  ID NUMBER , NAME VARCHAR2(20 BYTE) ) ;

Lets insert duplicate values into it:

INSERT INTO ABC (ID, NAME) VALUES ('15', 'f');
INSERT INTO ABC (ID, NAME) VALUES ('15', 'f');
INSERT INTO ABC (ID, NAME) VALUES ('15', 'f');
INSERT INTO ABC (ID, NAME) VALUES ('11', 'B');
INSERT INTO ABC (ID, NAME) VALUES ('11', 'B');
INSERT INTO ABC (ID, NAME) VALUES ('13', 'G');
INSERT INTO ABC (ID, NAME) VALUES ('13', 'G');

Now table looks like this:

                  

 Now we have a duplicate combination of 2 columns.
sql to find duplicate values combination in two columns:
 
 select ID,NAME, count(ID) from ABC group by ID,NAME having count(ID) > 1;

sample output:


 


Find the duplicate ID's in a column :

 select ID, count(ID) from ABC group by ID having count(ID) > 1;


Sample output:



 Retrieving duplicate values in database :


SELECT a.*
FROM   tablename a
 INNER
  JOIN 
  (
  SELECT column1
       , column2
  FROM   table1 
  GROUP
      BY column1
       , column2
  HAVING Count(*) >1
  ) b
    ON a.column1 = b.column1
   AND a.column2 = b.column2



If you have combination of multiple columns that you want to check duplicates. 

For example : Check duplicates for combination of multiple columns check this link.

http://arvindasdba.blogspot.com/2016/02/check-duplicates-for-combination-of.html



Thursday, September 18, 2014

grant permissions on all tables to a user

Grant select  permission on all tables in logged in schema to a user/role:



declare
cursor c1 is select table_name from user_tables;
cmd varchar2(200);
begin
for c in c1 loop
cmd := 'GRANT SELECT ON '||c.table_name||' TO &&YOURUSERNAME';
execute immediate cmd;
end loop;
end;



Note :
you change the select to what ever permissions you want to grant. This will be very helpful in case of huge number of tables.

Friday, September 12, 2014

adding a primary/unique key to existing table and updating values

lets take a simple example here. create a table and leave id column empty and add values to other column name.

Sample create table :

create table abc (id number, name varchar2(20));


add values to name column and leave the id column empty

INSERT INTO ABC (NAME) VALUES ('a');
INSERT INTO ABC (NAME) VALUES ('b');
INSERT INTO ABC (NAME) VALUES ('c');
INSERT INTO ABC (NAME) VALUES ('d');
INSERT INTO ABC (NAME) VALUES ('e');
INSERT INTO ABC (NAME) VALUES ('f');
INSERT INTO ABC (NAME) VALUES ('g');
INSERT INTO ABC (NAME) VALUES ('h');


Now we have a situation where we have a table with only values in the name column and id column is empty (in case if u want to add id's to already existing table  just add a column for the new unique ID's ). 

Now we will create a sequence to get the sequential values to update with.

create a sequence :

CREATE SEQUENCE SEQ_abc
START WITH 1
MAXVALUE 99999
MINVALUE 1
NOCYCLE
NOCACHE
NOORDER;

This cursor will update the ID's columns with the new unique ID's from above sequence sequentially. execute below block and all set.

Update cursor:

DECLARE

Cursor store_id
IS
SELECT id FROM abc FOR UPDATE;

BEGIN

FOR c_store_id IN store_id LOOP
UPDATE abc
SET id = SEQ_abc.nextval
WHERE CURRENT OF store_id;

END LOOP;
commit;
END;

/

Note: This is a one time update, use a trigger  to keep column updated everytime.

Thursday, August 21, 2014

Oracle Shrink Table - regain your space back

I believe this is better explained with an example.

Sql code:

lets first check if your database table spaces that re in manual and auto segment space management.

 SELECT tablespace_name, extent_management, segment_space_management
    FROM dba_tablespaces;

  
    TABLESPACE_NAME                EXTENT_MANAGEMENT SEGMENT_SPACE_MANAGEMENT
------------------------------ ----------------- ------------------------
SYSTEM                         LOCAL             MANUAL                 
SYSAUX                         LOCAL             AUTO                   
UNDOTBS1                       LOCAL             MANUAL                 
TEMP                           LOCAL             MANUAL                 
USERS                          LOCAL             AUTO                   
 


SQL> create table test ( x number )
  2  tablespace users
  3  storage ( initial 10M next 10M )
  4  /

Table created.

SQL> analyze table t compute statistics;

Table analyzed.

SQL> select blocks, extents from user_segments where segment_name = 'TEST';

    BLOCKS    EXTENTS
---------- ----------
      1280         10

SQL> select blocks, empty_blocks from user_tables where table_name = 'TEST';

    BLOCKS EMPTY_BLOCKS
---------- ------------
         0         1280

So, I started creating a table named TEST and requested initially 10mb allocated, which turned out to be 1280 blocks and 10 extents. From there you can see:
- table TEST has 1280 blocks allocated (blocks in user_segment)
- none of which are *formatted* to receive data (blocks in user_tables)

Then, I insert some data
sql code:

SQL> insert into TEST
    select rownum
     from dual
   connect by level <= 100000;

100000 rows created.

SQL> analyze table TEST compute statistics;

Table analyzed.

SQL> select blocks, extents from user_segments where segment_name = 'TEST';

    BLOCKS    EXTENTS
---------- ----------
      1280         10

SQL> select blocks, empty_blocks from user_tables where table_name = 'TEST';

    BLOCKS EMPTY_BLOCKS
---------- ------------
       186         1094

I inserted 100,000 rows, from there you can see:
- allocated blocks/extents for the table did not change
- however, blocks formated to receive data were raised by 186 and the remaining blocks are empty

186 blocks are the HWM now, because those are the blocks that sometime were formatted to receive data. Blocks above 186 are allocated blocks which have never been formatted to receive data.

I will delete some data now to show you it will not raise empty_blocks nor it will lower the blocks that are formatted to receive data (that is, the HWM).
sql code:

SQL> delete from TEST where rownum <= 90000;

90000 rows deleted.

SQL> analyze table TEST compute statistics;

Table analyzed.

SQL> select blocks, empty_blocks from user_tables where table_name = 'TEST';

    BLOCKS EMPTY_BLOCKS
---------- ------------
       186         1094

See, the delete did nothing to change the HWM, but.. that is because HWM is never reset back when you delete the rows (in oracle)
sql code:

SQL> select count(distinct dbms_rowid.rowid_block_number(rowid)) used_blocks from TEST;

USED_BLOCKS
-----------
         16

tells me only 16 of those 186 contains data. The rest blocks belong to the segment's freelist to be used for inserts/updates.

Now, I will *move* the table to show you how it will re-adjust the HWM.
sql code:

SQL> alter table TEST move tablespace users;

Table altered.

SQL> analyze table TEST compute statistics;

Table analyzed.

SQL> select blocks, empty_blocks from user_tables where table_name = 'TEST';

    BLOCKS EMPTY_BLOCKS
---------- ------------
        20         1260

See, it shrinked down the HWM to just 20 from 186 and raised the empty_blocks, but..
sql code:

SQL> select blocks, extents from user_segments where segment_name = 'TEST';

    BLOCKS    EXTENTS
---------- ----------
      1280         10

tells you it did nothing to *shrink* the allocated space asigned to the segment, meaning that at this stage the segment will still be using,
at the operating system level space, the same kind of storage. Now, to *reclaim* that space we will use shrink.
sql code:


SQL> alter table TEST enable row movement;

Table altered.

sql > alter table TEST shrink space compact;

Table altered.

SQL> alter table TEST shrink space;

Table altered.

SQL> analyze table TEST compute statistics;

Table analyzed.

SQL> select blocks, extents from user_segments where segment_name = 'TEST';

    BLOCKS    EXTENTS
---------- ----------
       128          1

SQL> select blocks, empty_blocks from user_tables where table_name = 'TEST';

    BLOCKS EMPTY_BLOCKS
---------- ------------
        20          108